三招实现高效的企业级微服务治理

【51CTO.com快译】众所周知，在一些中大型应用中，企业通常会拥有数千个微服务。同时，每个团队在选择自己的技术堆栈时也拥有着一定的自主权。那么，企业不可避免地需要通过微服务的治理机制，来避免构建出那些难以管理且不稳定的架构。而如果缺乏强有力的微服务治理策略，企业将会面临如下的挑战：

• 缺乏适当的机制来监控与衡量现有的产品性能，进而失去新产品的创新力。
• 由于缺少合适的平台，企业将无法从整体上获得洞见，也无法与IT团队进行规划与整体设计。
• 各种过期的文档将会严重影响产品交付的敏捷性。
• 自治团队与系统无法通过平台进行相互操作与协作，企业会因为丧失敏捷性而无法遵循联合开发(federated development)的原则。

虽然每个团队都应当具有标准化的策略可供遵循，但是任何集中式的治理方式都可能会违背微服务架构的核心原则，即：“为团队提供自治性和敏捷性”。因此，在面对具有多个系统和复杂操作的企业级集成环境时，我们需要解决的问题是：如何才能有效地提供分散式的治理方案?

在实施微服务治理策略时，我们往往需要在思维上进行范式的转变。也就是说，各种治理策略应当符合微服务的核心原则，即：各种独立且自包含的服务、单一的职责、以及跨职能的团队，需要与业务、策略、以及优秀实践保持一致。在此，我们提出三个实现高效的企业级微服务治理的方法，它们分别是：基于域(domain-based)，以产品为中心(product-centric)、平台思想(platform thinking)。根据这三种方法，我们将能够为企业提供一个与微服务原则相一致的治理平台，以便企业能够自动化地整合各项全局策略、标准和指南。下面，我们将逐一展开讨论。

基于域

微服务体系架构的关键原理之一是：遵循域驱动设计(domain-driven design，DDD)。也就是说，我们的治理策略应当将“域”视为重点，其中各项业务或域专家应当根据DDD来定义信息模型。同时，企业还应该能够根据信息模型，为每个域定义相应的业务能力。

以产品为中心

企业应该能够根据现有的信息模型和业务功能，来轻松定义各种产品，并且能够为产品定义相应的业务KPI。在治理方面，我们还应当注意为企业提供有关现有产品、API、服务和实际KPI的整体视图。这些将能够帮助企业保持业务能力与最终客户在预期上的一致性，快速识别和评估创新产品的有效性。

平台思想

借助平台思想，企业应该能够为业务和IT提供自助化的服务治理平台，以便两者进行相互协调和协作。企业应该能够通过模板定义全局策略、标准和准则。团队可以根据他们为自己的领域所确定的 工具 、以及技术，来构建开发人员的模板。各种技术工件(artifact)应当通过模板来自动生成，并通过CI/CD管道被部署到相应的运行时(run-time)环境中，从而使得策略、标准和指南能够得到自动化的实现。

下图描述了一种业务体系架构。在整个开发生命周期中，它属于一种嵌入式的自助治理服务平台。

如上图所示，企业可以通过定义或上传现有的信息模型，来建立各种业务能力，并快速定义新产品、及其预期的KPI。而团队通过设计和创建API的定义，为微服务和业务事件定义那些消费者(consumer-driven)驱动的合约，以及各种非功能性的需求，以实现业务所定义的产品。同时，他们应该能够定义各种策略、优秀实践、访问规则、数据质量规则，上载相关的旧资产、数据源和集成点的各种元数据(meta-data)信息。这些实务都有助于团队在设计时定义好从消费者到API与微服务的业务能力，SOAP服务之类的旧资产，甚至是数据源的端到端线性关系。

我曾经有个客户，它的企业拥有4,000至5,000个微服务，甚至有10至20个相同的微服务版本映射到不同的消费者处。他们所面临的挑战是：必须依靠运行时的各种指标，来识别消费者正在使用的版本，并通过开展影响分析，以改善当前的敏捷性问题。在实践中，他们发现上述三种自助服务平台，就可以帮助他们建立端到端的线性关系。

此类平台具有的另一项重要功能是：使团队能够定义各种开发者模板，以便映射诸如：API定义、消费者驱动合约、集成点、策略、访问规则、数据质量规则等受控的元数据值。这些模板应当通过源代码管理(source control management，SCM)来进行版本控制，并与CI/CD的管道相集成，进而自动生成技术工件(如下图所示)。此处的技术工件包括：API代理、微服务和业务事件的框架、各层之间的映射、单元测试用例、集成测试用例、来自消费者驱动的合约stub，以及API文档等。这些将有助于企业根据各种受控制的元数据值产生一致性的输出，允许自己的团队更专注于业务逻辑，以及促进IT部门不断交付业务价值。此外，通过各种数据质量规则、以及自动化管理策略，我们还应当将测试、基本安全性、以及认证等方面内置到CI/CD的流程中。

那些带有CI/CD管道的模板、以及线性集成点上的元数据，会使得我们能够将集成的逻辑汇总到可以独立控制与更新的管道中。此举不但能够支持联合开发，还可以进一步提高产品“面市的速度”。

通过模板自动生成的技术工件

就像管理大师彼得·德鲁克(Peter Drucker)所说：“我们无法改善和管理那些无法衡量的内容。”可见，衡量性能是另一个值得关注的要点。如上图所示，我们应该将运行时环境中的各项指标及时反馈到平台上，以计算实际的KPI和NFR(非功能性需求)，进而帮助企业和团队比较实际状态与计划上的差异，以便团队尽早获悉变化，并根据实际情况做出正确的决策。

总结

可见，为了拥有一套有效的机制来实施微服务的治理，企业的主要推进方向应当是：通过具有基于域和以产品为中心的模型，来搭建自助服务的治理平台。通过平台提供的治理方法和一致性的微服务原则，企业将能够快速地交付出具有创新特质的新产品。

与此同时，自助服务平台为业务和IT部门提供了协作和协调的桥梁，它可以促进各个团队更加专注于交付出真正的业务价值。而那些经过治理的策略、标准和指南模板，也会在实施过程中产生可重复性的技术输出。

通过采用上述三种微服务的治理方法，您的企业将能够实现设计时间和运行时的独立性，先进的联合开发模式，以及在不影响治理的情况下，加快体系架构的不断迭代。

原文标题：3 Keys to Efficient Enterprise Microservices Governance，作者：Asok Jacob Payyapilly

【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】

【责任编辑：庞桂玉 TEL：（010）68476606】