26、微服务架构：变革管理与转型度量

微服务架构：变革管理与转型度量

1. API变更与契约测试

在软件开发中，API的变更需要谨慎处理。我们可以独立进行契约测试，以验证变更不会影响API的现有客户端。为了让系统尽快上线运行，我们的架构中未包含契约测试组件，但很多从业者使用Pact进行消费者驱动的契约测试取得了成功。像Pact这样的工具能让消费者和提供者持续共享并测试接口的变更。

不过，即便有契约测试，最终仍可能需要进行会破坏某些代码的变更。这种情况下，就需要实现某种多版本模式，并维护旧的微服务，直到客户端团队完成所需的更改。总体而言，我们的架构在降低消费者影响变更成本方面作用有限。API变更难度大，需要良好的设计思维和规划，才能让变更变得可行。

2. 数据变更的挑战与应对

数据变更在微服务架构维护中是一大难题。数据模型难以更改，持久层是软件系统的必要部分，但更改数据结构时情况会变得复杂。软件组件依赖于所使用的数据系统，更改它们会带来高昂成本和对系统的重大影响。下面从四个方面分析数据架构的变更情况。

2.1 数据：实现成本

更改数据模型的成本取决于结构、格式、关系的复杂程度，以及进行更改所需的工具或语言。当存在复杂值、多种数据类型、唯一键或复杂关系时，模型的复杂性会增加。成本主要源于需要理解模型本身，以便安全地进行更改。

我们的架构虽未明确防止数据模型变得过于复杂，但决定让微服务拥有自己的数据。这一决策有助于限制模型的范围和规模，就像有助于降低代码变更成本一样。与代码变更类似，优先考虑独立性能带来显著的实现成本效益，但也需持续衡量实现成本，确保服务及其数据模型不会发展到削弱强边界优势的规模。

2.2 数据：协