元数据驱动为服务架构

EAII企业架构创新研究院（微信号：eaworld），如需加入云计算架构设计群或联系作者交流请添加微信号：elaineyuan928。

在微服务架构中微服务的粒度小，数量多，微服务的设计与微服务之间的连接需要一套规范，同时需要一套可以对话的统一“语言”。传统的模型方式的核心目标是能够自动生成代码，故定义过于复杂。而微服务间的“语言”的目标与传统不同，用元数据作为“语言”驱动整个微服务架构是不错的选择。

企业IT架构已经发展了多个阶段，一方面是服务化架构的发展，在SOA阶段主要解决应用间集成问题，但随着企业业务的发展，单个应用逐渐成为“巨石型”应用，难以扩展也难以维护。微服务架构应运而生，微服务架构专注于单个应用的内部，将“巨石”应用拆分成为多个微服务，以微服务为单独单元开发运营。

另一方面是模型化架构式MDA（模型驱动架构）的发展，模型驱动工程也在不断发展，从全面的完全模型自动化，到DSM（特定领域建模）针对特定领域的建模，再发展到DDD（领域模型驱动设计），模型的作用变得更加特定化和轻量化。

服务化架构和模型化架构其实是统一的。在微服务架构中微服务的粒度小，数量多，微服务的设计与微服务之间的连接需要一套规范，同时需要一套可以对话的统一“语言”。传统的模型方式的核心目标是能够自动生成代码，故定义过于复杂。而微服务间的“语言”的目标与传统不同，用元数据作为“语言”驱动整个微服务架构是不错的选择。 

我们看看元数据表示了什么内容，元数据就是计算机的认知维度，可以说，掌握了元数据就掌握了信息的维度，只有充分利用好元数据（也就是信息的维度），通过合理的元数据建模（维度整合），对元数据进行科学管理（维度完善），才能让让计算机更好地认知企业系统。元数据管理的核心内容是，信息的概念和信息之间的连接。概念表示对某个业务所有维度的集合，连接是对业务维度之间关系的描述。通过这样的描述，能够使元数据成为微服务直接对话的“语言”，还能够通过“语言”规范微服务体系的设计。

从模型到微服务——

元数据与微服务的关系

定位模型与元数据的概念之前，我们不得不提到MOF（元对象设施或者元对象机制 MetaObject Facility），它是OMG（国际标准化组织）元模型和元数据的存储标准，提供在异构环境下对元数据知识库的访问接口。我们可以看到每个层次的上一层是下一层的模型，本层次的描述语言在它的上一层模型中。M1层元数据，也就是通常说的“数据模型层”。M1层（元数据）对应在日常我们项目开发过程中进行的ER模型图模型设计。也就是说我们进行所有的数据层设计其实都是元数据的建模过程。

再看如何进行模型设计，也就是进行元数据的设计，数据的描述。我们一般建模过程会将其分解成更小的、更简单的元素，通过多个模型之间的关系描述复杂的事物逻辑。一般从需求开始，无论是用户的需求还是技术需求，能力是实现需求的桥梁与纽带，借助现有的技术手段进行实现的支撑。随着建模过程逐渐深入，建模可以分为概念模型-逻辑模型-物理模型，层层递进最终物理模型会确定数据库实现方式，将数据表固化到数据库中。建模最有效的简化方式是图形建模，也就是我们通常所说的ER图建模。多数建模方法都建立在可视化语言的基础上。比如UML实体-关系图建模，这就是最常见的语义模型建模方法。 基于语义分析模型的元数据模型，主要是建立模型的实体与实体之间的关系，包括元数据模型之间关系的建立，元数据之间的输入输出接口等。

不同数据模型之间统一标准相互访问的机制是其中的关键点，可以使用XMI规范来做模型互相访问，这里XMI 是 OMG在元数据交换方面的最重要标准之一，同时也是 W3C 认可的标准。允许 MOF元数据（即遵从 MOF 或基于 MOF 的元模型的元数据）以流或文件的形式按照 XML 的标准格式进行交换。

在微服务中每个服务都有自己的数据库。这种思路与企业级的传统数据建模过程不同，每个微服务中需要建立自己的数据模型。各微服务的接口API需要定义元数据，接口需要清晰的元数据模型，对象、属性。也就是我们需要元数据的原因，我们需要建一套完整的元数据模型机制，这也就是元数据与微服务之间的关系所在。

微服务架构需要元数据，即微服务与元数据的关系，那么微服务中的元数据中具体如何应用，有哪些应用场景？我们接下来看一下——微服务中元数据的价值，了解元数据在微服务中具体的应用价值点。

微服务中元数据的四大价值

元数据驱动的微服务价值体现为：一、提供微服务边界交互模型；二、规范微服务开发和使用；三、分析微服务的脉络；四、管理微服务的全生命周期。

价值一，提供微服务边界交互模型

每个微服务代表一个业务可交付的应用，不同微服务在进行数据互通的时候需要一个业务实体作为信息承载。而这个信息载体通常称为微服务的交互信息，这些信息是通过元数据进行的，它代表在微服务间游走的数据载体信息，不同功能的微服务所使用的载体根据业务不同是不太一样的，在微服务架构下最好进行事前定义。边界，也就是元数据，这个元数据就像网络传输的数据包的概念，有它的协议和格式。微服务下的元数据主要解决：模型复杂性和模型变更 、涉众沟通、设计沟通、提炼并捕获领域知识等相关问题。

上图服务数流程是企业申请贷款审核流程中便指定贷款款项相应划款对象（收款人），贷款发放后，银行按照合同约定将贷款款项直接划转至指定收款人的操作。本场景中涉及到5个服务的串联整合，服务间的连接就是通过元数据驱动完成的。微服务的设计和实现需要遵照组织级的元数据知识库进行开发实例化，组织也有职责对微服务的合规性进行审查，而这一切是通过元数据来驱动的。

微服务包含两种元数据：一、微服务本体的元数据驱动规范模型；二、微服务间数据载体的元数据驱动规范。微服务本体元数据信息一般包含：业务信息，功能信息，数据信息，管理信息，逻辑信息。这些信息是基于元数据知识库中定义的元数据规范实例化得到的。微服务间的元数据信息包含，依赖信息，参数信息，过程信息，同样，这些信息也是来源于元数据知识库，用来解决微服务间连接的关系、映射、依赖、整合约束。

价值二，元数据标准规范微服务开发和使用

上面两幅图所呈现的是实际使用服务时的服务整合情景，不同微服务在不同的业务场景下被依赖和引用的程度不同，每个微服务提供的能力数据由业务复杂程度决定。成千上万个微服务在运营环境下高效地运转，这就要求微服务必须有标准规范。标准规范分为两个方面，一方面是微服务的数据标准，另一方面是微服务的服务标准。而这两种标准都需要元数据定义。

价值三，分析微服务脉络

微服务架构模式应用的改变将会波及多个服务。微服务架构模式就要考虑相关改变对不同服务的影响。比如，你需要更新服务C，然后是B，最后才是A，上图是一个场景示例。一般微服务的改变会影响多个服务联动调整，不同区域、不同团队在进行微服务的开发势必会带来协调上的不便。基于元数据驱动的微服务实现会带来天生的脉络分析优势，从任何一个微服务可以分析出整个调用关系图谱，我们称之为“微服务地图”。

价值四，微服务的全生命周期管理

微服务的生命周期有多个阶段，在前期需要与多个微服务协同考虑，上架后也会有多个使用者，在这种复杂的状况下需要管理微服务的全生命周期。

在规划阶段，提供标准元数据规范微服务。在设计阶段，提供连接其他微服务的元数据信息。在开发阶段，使用元数据协助开发测试。在运营阶段，上线后分析微服务的使用情况，并协助维护微服务的变更。最后微服务下架时将微服务的元数据存档，并确保对目前体系不产生影响。

最后，未来元数据将是微服务的中枢神经。元数据驱动的微服务架构还需要进一步思考和研究。