转载

高效企业微服务治理的3个关键

企业通常拥有数千个微服务，每个团队在选择自己的技术堆栈时拥有自主权。因此，企业不可避免地应具有微服务治理机制，以避免构建难以管理且不稳定的架构。

任何集中式治理都违背微服务架构的核心原则，即“为团队提供自治和敏捷性”。但这也不意味着我们不应该拥有每个团队都应遵循的集中式政策，标准和优秀实践。在具有多个系统和复杂操作的企业级集成的情况下，问题是：“我们如何有效地提供分散的治理?”

高效企业微服务治理的3个关键

在实施微服务治理策略时，我们需要在思维上进行范式转变。治理策略应符合微服务的核心原则，即与业务，政策和最佳实践保持一致的独立和独立的服务，单一职责以及跨职能的团队。我们应该从3个关键原则着眼于治理：基于领域，以产品为中心和平台思考。有了这三个原则，我们将能够为企业提供一个与微服务的原则保持一致的治理平台，并使企业能够自动化全球策略，标准和准则的整合。

微服务治理的三个关键

现在让我们考虑3个关键原则-基于域，以产品为中心和平台思考

基于域

微服务体系结构的关键原理之一是遵循域驱动设计(DDD)。话虽如此，我们的治理策略应将域视为一等公民，其中业务或域专家应根据DDD定义信息模型。企业还应该能够根据信息模型为每个域定义业务能力。

以产品为中心

企业应该能够根据现有信息模型和业务功能轻松定义产品，并且能够为产品定义业务KPI。治理还应注意为企业提供现有产品，API，服务和实际KPI的整体视图。这将帮助企业使业务能力与最终客户保持一致，快速识别新产品和创新产品并评估其有效性。

平台思考

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

下图描述了在生命周期中嵌入治理的自助服务平台的业务体系结构。

企业可以定义或上传现有的信息模型，建立企业功能，并快速定义新产品和预期的企业KPI。团队设计和创建API定义，为微服务和业务事件定义消费者驱动的合同，以及非功能性需求以实现业务所定义的产品。他们应该能够定义策略，最佳做法，访问规则和数据质量规则，并上载有关旧资产，数据源和集成点的元数据信息。这有助于团队在设计时定义端到端沿袭，从消费者到业务功能再到API，微服务，诸如SOAP服务之类的旧资产，甚至数据源。

我的一个企业客户拥有4,000至5,000个微服务，甚至有10至20个相同的微服务版本映射到不同的使用者。他们面临的挑战是，他们必须依靠运行时指标来识别消费者正在使用的版本，并在进行影响分析以进行更改方面做出了很多努力，从而极大地影响了敏捷性。像上面那样的自助服务平台可以帮助他们提供端到端的血统。

该平台具有的另一项重要功能是使团队能够定义可以映射到受控制的元数据值(例如API定义，消费者驱动的合同，集成点，策略，访问规则，数据质量规则，等等。)。模板应通过源代码管理管理(SCM)进行版本控制，并与CI / CD管道集成，以自动生成技术工件。技术工件包括API代理，微服务和业务事件的框架，层之间的映射，单元测试用例和集成测试用例以及来自消费者驱动的合同的存根，API文档等。这有助于企业根据受控制的元数据值产生一致的输出，并允许团队专注于业务逻辑并授权IT部门不断提供业务价值。正如我们所解释的，我们还应该识别并“使我们的痛苦前进”并自动消除痛苦。尼尔·福特(Neal Ford)关于进化架构的论文。例如，数据质量规则，安全性和自动管理的策略。测试，安全性和认证应该内置在CI / CD流程中，而不是让流程感到痛苦。

带有CI / CD管道和跨集成点沿袭的元数据的模板使我们能够将集成逻辑集中在可以独立控制和更新的管道中。这支持联合开发，并进一步提高了我们的“上市速度”。

就像管理思想家彼得·德鲁克(Peter Drucker)所说的那样，“我们无法改善和管理我们无法衡量的内容。” 衡量性能是另一个关键要素。我们还应该将运行时环境中的指标反馈到平台，以计算实际的KPI和NFR，从而帮助企业和团队比较计划的计划与实际的计划，并使他们能够针对以下情况做出正确的决策：最早的变化。