25、系统架构变更管理：基础设施与微服务的全面解析

系统架构变更管理：基础设施与微服务的全面解析

1. 多版本模式概述

多版本模式能让系统的变更对用户和客户端更加透明。在这种部署模式下，我们会明确对组件或接口进行版本管理，允许客户端选择他们想要使用的组件版本，从而实现多个版本的同时支持。

采用这种技术的主要原因在于，当我们进行的变更需要依赖系统也做出相应改变时，尤其是在无法与相关人员充分协调的情况下。例如，当我们想要以一种会破坏客户端代码的方式更改 API 时，使用多版本模式可以避免等待所有客户端进行更改，只需让旧版本继续运行即可。

然而，使用这种方法也存在一些显著挑战。引入的每个组件版本都会增加系统的维护成本和复杂性。不同版本需要能够安全共存，并且并行版本需要持续维护、支持、记录和保障安全。随着时间的推移，这些开销可能会成为操作上的难题，并降低系统的可变更性。最终，我们还需要迁移旧版本的用户并减少版本数量。不过，也有一些系统几乎从不减少版本，如 Salesforce SaaS API 目前已到 49 版，还同时支持 19 个旧版本。

2. 架构变更评估框架

我们已经有了一个评估变更影响的良好框架和一系列典型的部署模式，接下来将从基础设施、微服务和数据三个方面，从变更的角度对架构进行评估。

2.1 基础设施变更

基础设施平台会随着用户和团队需求的演变、需求模式和业务目标的变化而不断改变。我们可以将基础设施的变更分为两类：
- 扩展平台的新资源变更 ：对运行系统影响较小，例如：
- 为正在开发的新微服务使用 AWS SNS 实现新的事件流基础设施。
- 为安装第三方应用程序配置弹