数据治理十年架构师告诉你，元数据为什么适用于微服务
企业IT架构已经发展了多个阶段，在SOA阶段主要解决应用间集成问题，但随着企业业务的发展，单个应用逐渐成为“巨石型”应用，既难以扩展又难以维护。微服务架构将“巨石”应用拆分成为多个服务，以微服务为单独单元进行开发运营，专注于单个应用。
传统模型驱动架构，即MDA，因为希望模型能够跨平台，故不能直接应用模型本身，需要为平台特定代码。为了能够最大限度的自动化：能够自动生成代码是MDA的建模目标，从而自动化地形成应用。这个自动化生成代码过程的定义很复杂。微服务架构中微服务粒度小、数量多，需要使得各个服务之间统一地规范化互换信息。普元的资深大型企业信息化架构专家王轩建议，各个微服务之间使用一套可以对话的统一“语言”——元数据。本文，作者分析了元数据适用于微服务的原因，讨论了如何设计微服务的元数据，并且总结了元数据的四大应用价值。
为什么元数据适用于微服务？
首先要清楚元数据（Metadata）表示的是什么内容：元数据就是计算机的认知维度。可以说，掌握了元数据就掌握了所有已知信息的维度。只有充分利用好元数据（也就是信息的维度），通过合理的元数据建模（维度整合），对元数据进行科学管理（维度完善），才能让计算机更好地认知企业系统。
在微服务架构中微服务的粒度小，数量多，微服务的设计与微服务之间的连接需要一套规范，同时需要一套可以对话的统一“语言”。传统的模型方式的核心目标是能够自动生成代码，故定义过于复杂。而微服务间的“语言”的目标与传统不同，用元数据作为“语言”驱动整个微服务架构是不错的选择。
我认为元数据管理的核心内容有两点：业务信息的概念集合和集合内部信息的连接。概念集合表示对某个业务所有维度抽象之后的集合，连接是对集合内部的业务维度之间关系的描述。通过这样的描述，能够使元数据成为微服务直接对话的“语言”，还能够通过“语言”规范微服务体系的设计。
怎样设计微服务需要的元数据？
元数据与元模型——从MOF说起
MOF（元对象机制，又称元对象设施 MetaObject Facility），它是OMG（国际标准化组织）元模型和元数据的存储标准，提供在异构环境下对元数据知识库的访问接口。MOF被设计为4层次的结构。
从图中可以看到，每一层都是下一层的抽象模型，而上一层则提供了本层的描述语言。在该图中，M1层为元数据，也就是通常说的“数据模型层”。M1层（元数据）对应在日常我们项目开发过程中进行的ER模型图模型设计，而所有的数据层设计其实都是元数据的建模过程。
如何进行元模型设计
如何进行模型设计，也就是进行元数据的设计，数据的描述。我们一般建模过程会将其分解成更小的、更简单的元素，通过多个模型之间的关系描述复杂的事物逻辑。一般从需求开始，无论是用户的需求还是技术需求，能力是实现需求的桥梁与纽带，借助现有的技术手段进行实现的支撑。随着建模过程逐渐深入，建模可以分为概念模型-逻辑模型-物理模型，层层递进最终物理模型会确定数据库实现方式，将数据表固化到数据库中。建模最有效的简化方式是图形建模，也就是我们通常所说的ER图建模。多数建模方法都建立在可视化语言的基础上。比如UML实体-关系图建模，这就是最常见的语义模型建模方法。
基于语义分析模型的元数据模型，主要是建立模型的实体与实体之间的关系，包括元数据模型之间关系的建立，元数据之间的输入输出接口等。
不同数据模型之间统一标准相互访问的机制是其中的关键点，可以使用XMI规范来做模型互相访问。XMI 是OMG在元数据交换方面的最重要标准之一，同时也是W3C认可的标准。XMI允许 MOF元数据（即遵从MOF、 或基于MOF的元模型的元数据）以流或文件的形式按照XML的标准格式进行交换。
与企业级的传统数据建模过程不同，每个微服务中需要建立自己的数据模型。各微服务的接口API需要定义元数据，元数据模型要有明确的对象、属性。每个微服务都有各自的元数据库，因此需要建一套完整的元数据模型机制。
微服务中元数据的四大应用价值
那么微服务中的元数据中具体如何应用，又有哪些应用场景？我们接下来探讨一下元数据在微服务中的四大价值。
元数据驱动的微服务价值体现为：一、提供微服务边界交互模型；二、规范微服务开发和使用；三、分析微服务的脉络；四、管理微服务的全生命周期。
价值一：提供微服务边界交互模型
每个微服务代表一个业务可交付的应用，不同微服务在进行数据互通的时候需要一个业务实体作为信息承载。这个信息载体通常称为微服务的交互信息，这些信息是通过元数据进行的，它代表在微服务间游走的数据载体信息。不同功能的微服务所使用的载体根据业务不同是不太一样的，在微服务架构下建议最好进行事前定义。微服务之间的边界，也就是元数据，这个元数据就像网络传输的数据包的概念，有它的协议和格式。微服务下的元数据主要解决：模型复杂性和模型变更、涉众沟通和设计沟通、提炼并捕获领域知识等相关问题。
上图服务数流程是企业申请贷款审核流程中便指定贷款款项相应划款对象（收款人），贷款发放后，银行按照合同约定将贷款款项直接划转至指定收款人的操作。本场景中涉及到5个服务的串联整合，服务间的连接就是通过元数据驱动完成的。微服务的设计和实现需要遵照组织级的元数据知识库进行开发实例化，组织也有职责对微服务的合规性进行审查，而这一切是通过元数据来驱动的。
微服务包含两种元数据驱动规范：
微服务本体的元数据驱动规范 。微服务本体元数据信息一般包含：业务信息、功能信息、数据信息、管理信息、逻辑信息。这些信息是基于元数据知识库中定义的元数据规范实例化得到的。
微服务间数据载体的元数据驱动规范 。微服务间的元数据信息包含：依赖信息、参数信息、过程信息。同前者一样，这些信息也是来源于元数据知识库，用来解决微服务间连接的关系、映射、依赖、整合约束。
价值二：元数据标准规范微服务开发和使用
上图所呈现的是实际使用时的服务整合情景，不同微服务在不同业务场景下被依赖和引用的程度不同，每个微服务提供的能力数据由业务复杂程度决定。如果希望实现成千上万个微服务在运营环境下高效地运转，那么微服务就必须有标准规范。标准规范分为两个方面，一方面是微服务的数据标准，另一方面是微服务的服务标准。这两种标准都需要通过元数据来定义。
价值三：分析微服务脉络
因为微服务架构模式的改变将会波及多个服务，所以要考虑相关改变对不同服务的影响。比如上图的一个场景示例，当希望改变服务A时，你可能需要首先更新服务C，然后是B，最后才是A。一般微服务的改变会影响多个服务联动调整，不同区域、不同团队在进行微服务的开发势必会带来协调上的不便。元数据驱动的微服务实现会带来天生的脉络分析优势，因此从任何一个微服务可以分析出整个调用关系图谱，我们称之为“微服务地图”。
价值四：微服务的全生命周期管理
微服务的生命周期有多个阶段，在前期需要与多个微服务协同考虑，上架后也一个微服务会有多个使用者。因此状况复杂，需要管理微服务的全生命周期。
在规划阶段，提供标准元数据规范微服务。在设计阶段，提供连接其他微服务的元数据信息。在开发阶段，使用元数据协助开发测试。在运营阶段，上线后分析微服务的使用情况，并协助维护微服务的变更。最后微服务下架时将微服务的元数据存档，并确保对目前体系不产生影响。
结语
最后，简单对本文做一个总结。
1、元数据可以成为微服务间直接对话的“语言”。
2、使用语义模型建模的方法，以MOF为基础，配合不同数据模型之间统一标准的相互访问机制，建立一套完整的元数据模型，从而驱动微服务架构的设计。
3、元数据驱动的微服务架构，能帮助企业提供微服务边界的交互模型，规范微服务的开发和使用，分析微服务的脉络，管理微服务的全生命周期。
我认为，未来元数据将是微服务的中枢神经。元数据驱动的微服务架构值得进一步思考和研究。
作者介绍：王轩，普元信息软件产品部副总、大数据产品线总经理，2010年加入普元，全面主持普元大数据产品的研发、拓展及团队管理工作。十年大型企业信息化架构设计与建设经验，曾任中国人民银行核心平台架构师。主持参与了国家开发银行大数据项目、中国人民银行软件开发平台、国家电网云计算平台等大型项目建设。
欢迎加入本站公开兴趣群
软件开发技术群
兴趣范围包括：Java，C/C++，Python，PHP，Ruby，shell等各种语言开发经验交流，各种框架使用，外包项目机会，学习、培训、跳槽等交流
QQ群：26931708
Hadoop源代码研究群
兴趣范围包括：Hadoop源代码解读，改进，优化，分布式系统场景定制，与Hadoop有关的各种开源项目，总之就是玩转Hadoop
QQ群：288410967
