25、系统架构变更管理全解析

系统架构变更管理全解析

在系统开发与运维过程中，变更管理是一项至关重要的工作。它涉及到系统的各个层面，包括基础设施、微服务等。本文将深入探讨系统架构变更管理的相关内容，从不同角度分析变更带来的影响，并提供相应的解决方案。

1. 多版本模式

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

采用这种技术的主要原因是，当我们进行的变更需要依赖系统也做出相应改变时，尤其是在与我们无法直接协调的人员需要为变更完成工作的情况下。例如，当你想要以一种会破坏客户端代码的方式更改 API 时，管理各方的迁移将需要大量的协调工作。而通过保留旧版本运行，我们就无需等待每个客户端都进行更改。

然而，使用这种方法也存在一些重大挑战。引入的每个组件版本都会给系统带来额外的维护和复杂性成本。版本需要能够安全地一起运行，并行版本需要持续维护、支持、记录和确保安全。随着时间的推移，这些开销可能会成为操作上的难题，并降低系统的可变更性。最终，你需要迁移旧版本的用户并进行版本收缩。有些系统几乎从不收缩版本，例如，目前 Salesforce SaaS API 已经到了第 49 版，并且还在并行支持 19 个以前的版本。

2. 基础设施变更

基础设施平台会随着用户和团队需求的演变、需求模式和业务目标的变化而持续改变。基础设施的变更可分为两类：用新资源扩展平台的变更和改变现有平台资源的变更。

创建新资源对运行中的系统影响较小，而更改现有资源则需要更谨慎地管理。以下是一些具体示例：
| 变更类型 | 示例 |
| ---- | ---- |
| 添加新资源 | 1. 为正在开发的新微服务使用 AWS SNS 实现新的事件流基础设施
2. 为安装第三方应用程序配置弹性容器服务（ECS）实例和 VPC
3. 向 IAM 系统添加新的操作员账户 |
| 更改现有资源 | 1. 更改我们的 EKS 服务部署所在的 VPC 的网络设计
2. 升级我们的 RDS 实例的 MySQL 版本
3. 修改 Kubernetes 集群的配置 |

接下来，我们将从实现成本、协调成本、停机时间和消费者影响四个方面来评估基础设施的可变更性。

2.1 实现成本

进行基础设施变更的实现成本取决于变更的理解和执行难度。我们在基础设施设计中所做的决策，如采用不可变基础设施原则、构建 CI/CD 管道和编写基础设施即代码（IaC），大大降低了变更成本。

当需要进行基础设施变更时，可以遵循以下流程：
1. 决定要进行的基础设施变更。
2. 确定需要更改的基础设施代码（例如，是否需要创建新的 Terraform 模块，还是只是更新环境定义）。
3. 在基础设施开发环境中测试基础设施变更。
4. 尝试将应用程序和微服务部署到更新后的基础设施。
5. 运行测试并发布（例如，集成测试、性能测试和端到端测试）。

通过采用 IaC 原则，我们的基础设施设计的可变更性得到了显著改善。我们只通过基础设施管道进行变更，确保代码和基础设施的一致性。使用相同的代码模块在每个环境中，保证了开发环境的变更在生产环境中也能正常工作。自动化管道确保了基础设施代码和测试的一致性和重复性。虽然编写 IaC 需要一些前期工作，但从长远来看，这是一项值得的投资。

2.2 协调成本

在开发运营模式时，我们决定由一个名为平台团队的单一团队负责设计、维护和运行基于云的基础设施。这种集中式的设计使得决策的协调成本相对较低，因为平台团队对基础设施变更拥有独立的权力和自主权。

然而，在实践中，以纯粹的 x-as-a-service 方式提供基础设施平台是困难的。微服务团队使用平台进行交付时，必然需要平台团队的支持和协调。平台团队的集中化性质也可能带来问题，例如当团队需要冲突性的变更时，以及如何在所有团队中测试新变更。

平台模型只有在有适当的工具和流程来支持自助服务、低协调的交互模式时才有效。这需要大量的前期和持续工作，例如为微服务团队提供基于 Terraform 的环境时，需要提供适当的文档、问题跟踪和合理的支持水平。在一个成熟的微服务系统中，基础设施变更几乎总是会因审批流程而产生额外的协调成本。为了降低协调成本，可以将相关团队视为平台的消费者，并相应地设计解决方案。

2.3 停机时间

由于基础设施是软件系统的基础部分，进行基础设施变更时很难避免引入一些停机时间。我们构建的基础设施系统能够轻松处理扩展和添加新资源，只需要一些 Terraform 代码通过管道运行即可。但在处理现有部分的变更时，即使是小的变更，由于基础设施的不可变性质，可能需要先销毁组件，这在处理工作负载和流量时可能会成为问题。

为了进行这类原位基础设施变更，可以采用蓝绿部署模式，甚至更进一步使用凤凰部署模式。凤凰部署模式类似于蓝绿部署，但会根据需要使用 IaC 管道创建新环境。具体操作如下：
1. 使用变更创建一个新环境。
2. 进行一些测试后，将所有微服务部署到新环境。
3. 如果一切正常，将实时流量切换到新环境。例如，API 网关或负载均衡器可以提供我们所需的流量路由功能。

然而，我们面临的一个大问题是数据。我们的数据实例和应用程序实例没有清晰的分离，这意味着在创建新环境时需要进行大量的数据复制工作，增加了变更过程的复杂性。如果零停机是重要原则，就需要从数据角度重新考虑基础设施设计。

2.4 消费者影响

应用程序的消费者不会直接与基础设施交互，但由于我们在运营模式中决定以“服务”形式提供基础设施，因此需要考虑变更对微服务团队的影响。

当更改基础设施的任何部分时，需要考虑该变更可能对所有使用平台作为服务的微服务团队产生的影响。随着系统中微服务数量的增加，这可能会成为一项重大的协调活动。我们构建的架构在解决这个问题上做得不够，使用该架构时，需要进行一些工作以确保基础设施变更不会破坏现有微服务，每次进行变更时都需要进行一些测试。

为了降低协调成本，平台和微服务团队需要建立一种沟通变更、保持自动化测试更新以及共同承担系统整体可靠性和质量责任的方法。这需要团队拓扑结构、架构以及良好的工具和技术的结合。

3. 微服务变更

系统中的大部分变更将针对微服务本身。当你想要提供新产品、改变用户体验方式或微调系统时，很可能需要对微服务子系统进行更改，这可能包括创建新的微服务、更新现有服务的逻辑，甚至退役、拆分或合并服务。

在我们的架构中，添加新功能相对容易，例如为旅行系统添加火车预订功能，我们可以创建新的微服务集群并更新网关中的 API 以支持这些扩展功能。但更改正在运行的服务会更复杂，例如：
- 将航班信息微服务拆分为国内和国际航班服务。
- 为航班预订服务添加新的“暂定”预订状态。
- 将航班信息和航班预订微服务合并在一起。

接下来，我们将从实现成本、协调成本、停机时间和消费者影响四个方面来评估微服务的可变更性。

3.1 实现成本

更改微服务的主要实现成本来自于代码的理解、维护和测试。我们在架构中做出的一些重要决策降低了实现成本：
- 使用事件风暴来调整微服务大小 ：事件风暴帮助我们定义了内部一致且针对特定领域部分的微服务边界，提高了代码的可理解性，使变更能够以更小的批次快速实现。
- 所有微服务使用微服务引导框架 ：微服务引导框架为团队提供了一种一致的方式来记录和测试他们开发的微服务。通过将该框架设为强制使用，我们减少了组织内进行和测试变更的负担。开发人员可以快速熟悉该工具，测试和构建服务的工作可以成为团队间的共同能力。
- 为微服务使用 CI/CD ：使用 CI/CD 管道意味着所有代码变更都经过测试、检查和验证，增加了代码在进行新变更时处于可用和可维护状态的可能性。

总体而言，服务的合理大小和我们所采用的 DevOps 工具应该能够大大降低对微服务进行代码变更的成本。

3.2 协调成本

协调成本是进行软件变更时的一个大问题。随着时间的推移，简单的应用程序代码可能会与其他库、组件和系统产生大量的依赖关系，这使得快速进行变更变得困难。

在我们的架构中，以下决策有助于降低协调成本：
- 每个微服务仅由一个团队拥有。
- 每个微服务都有自己的存储库和 CI/CD 管道。

这些决策增加了进行微服务代码变更的团队的自主性。此外，我们对服务边界的合理调整和对团队规模的限制，确保了团队内部的协调成本也相对较低。可以说，降低微服务代码变更的协调成本是我们构建架构的主要驱动力之一。

然而，在我们的架构中，有两个领域的协调成本难以避免：生命周期事件和接口变更。系统团队负责系统整体的健康和价值，他们发起的变更可能需要高度的协调。例如，当系统团队决定将两个微服务合并为一个，尤其是当这些微服务由不同团队拥有时，与单个微服务的代码变更相比，这类变更需要更多的协商、规划和沟通。

我们认为这是一种可以接受的成本权衡。根据经验，与为反映新的业务或技术需求而更改代码相比，生命周期和系统清理变更相对较少。因此，优化变更模型以适应更频繁发生的变更类型是有意义的。

更改微服务的接口也可能需要额外的协调工作，因为 API 在消费者和提供者之间具有契约性质。我们将在消费者影响部分详细讨论这个变更因素。

最后，我们决定由一个单一的发布团队负责更新生产环境。虽然这一决策旨在关注变更和协调成本，但如果发布团队成为变更的瓶颈，就需要重新审视系统设计，重新评估拓扑结构和支持发布周期的工具。

总体而言，由于我们在整个架构中所采用的运营模式、工具和设计决策，微服务变更的协调成本较低。

3.3 停机时间

我们在最小化单个微服务变更所需的停机时间方面进行了优化，这得益于我们在平台层面引入的工具和基础设施。关键在于能够对微服务发布使用金丝雀部署模式，具体操作步骤如下：
1. 将微服务的新版本作为金丝雀与现有版本一起部署。
2. 实施流量路由规则，将小部分流量发送到新版本。
3. 观察新版本的健康状况并验证结果是否符合预期。
4. 通过将所有流量路由到新版本来推广金丝雀微服务。
5. 排空并删除旧版本的微服务。

这种模式适用于大多数变更，并且可以使用 Argo CD 来编排金丝雀活动。但在新版本的微服务可能会影响旧版本的情况下，例如新版本更改了共享数据库中的数据，需要确保该变更与以前运行的版本兼容。

3.4 消费者影响

到目前为止，我们主要关注了微服务代码的变更。服务的逻辑、验证和行为反映在代码中，因此大部分变更都集中在这方面。但有时你需要更改微服务的接口（或 API），这可能会导致一些大问题。

更改微服务的接口几乎是不可避免的，例如更改操作的参数或调用返回的数据。问题在于，随着其他服务和组件开始依赖该接口，即使是小的变更也可能会给所有相关方带来大量工作。

我们的架构在降低变更的消费者影响方面做得不够。减少 API 变更的消费者影响的最佳方法是遵循一些良好的设计实践：
- 不更改已经发布的内容。
- 编写能够容忍新数据的客户端代码。
- 不将新的输入参数设为必需。

一些微服务从业者采用契约测试来最小化团队在更改接口时的协调成本。在契约测试中，消费者和提供者共享一个描述接口使用方式的契约，这允许提供者运行测试以确保变更不会破坏消费者。

综上所述，在系统架构变更管理中，我们需要综合考虑基础设施和微服务的各个方面，从实现成本、协调成本、停机时间和消费者影响等角度进行评估和优化，以确保系统能够灵活、高效地应对各种变更。

系统架构变更管理全解析（续）

4. 数据变更

在系统架构中，数据是核心要素之一，数据变更的管理同样至关重要。数据变更可以分为数据结构变更和数据内容变更。数据结构变更包括表结构的修改、字段的添加或删除等；数据内容变更则涉及数据的更新、插入和删除操作。

以下是数据变更可能面临的场景及相关挑战：
| 变更类型 | 示例 | 挑战 |
| ---- | ---- | ---- |
| 数据结构变更 | 为用户表添加新的字段，如用户积分字段 | 可能影响到依赖该表结构的所有应用程序和服务，需要对相关代码进行修改和测试 |
| 数据内容变更 | 更新用户的联系方式 | 可能导致数据不一致问题，尤其是在分布式系统中，需要确保数据的一致性和完整性 |

接下来，我们从实现成本、协调成本、停机时间和消费者影响四个方面来评估数据变更的可变更性。

4.1 实现成本

数据变更的实现成本主要来自于对数据结构和数据内容的理解、修改以及测试。为了降低实现成本，我们可以采取以下措施：
- 数据建模工具 ：使用专业的数据建模工具，如 ER/Studio、PowerDesigner 等，帮助我们清晰地定义数据结构，提高数据模型的可维护性。
- 版本控制 ：对数据脚本进行版本控制，如使用 Git 管理 SQL 脚本，方便追溯和回滚数据变更。
- 自动化测试 ：编写自动化测试用例，对数据变更进行全面的测试，确保数据的一致性和完整性。

通过这些措施，我们可以减少手动操作的错误，提高数据变更的效率和质量。

4.2 协调成本

数据变更往往涉及到多个团队和系统，因此协调成本较高。在进行数据变更时，需要与开发团队、测试团队、运维团队等进行沟通和协调。为了降低协调成本，我们可以建立以下机制：
- 数据变更审批流程 ：制定严格的数据变更审批流程，确保所有的数据变更都经过相关人员的审核和批准。
- 数据变更通知机制 ：建立数据变更通知机制，及时将数据变更的信息通知到相关团队和人员，以便他们做好相应的准备。
- 跨团队协作平台 ：使用跨团队协作平台，如 Jira、Confluence 等，方便团队之间的沟通和协作，提高工作效率。

通过这些机制，我们可以减少沟通成本，提高团队之间的协作效率。

4.3 停机时间

数据变更可能会导致系统停机，尤其是在进行大规模的数据迁移或数据结构变更时。为了减少停机时间，我们可以采取以下策略：
- 数据迁移工具 ：使用专业的数据迁移工具，如 SQL Server Integration Services (SSIS)、Talend 等，实现数据的快速迁移。
- 增量更新 ：采用增量更新的方式，只更新发生变化的数据，减少数据迁移的时间和工作量。
- 双写机制 ：在数据变更期间，采用双写机制，同时将数据写入新旧系统，确保数据的一致性。

通过这些策略，我们可以在保证数据一致性的前提下，尽可能地减少系统停机时间。

4.4 消费者影响

数据变更可能会对消费者产生影响，尤其是当数据变更导致数据格式或数据内容发生变化时。为了减少消费者影响，我们可以采取以下措施：
- 数据兼容性设计 ：在进行数据变更时，考虑数据的兼容性，尽量保持数据格式和数据内容的稳定性。
- 数据迁移过渡方案 ：为消费者提供数据迁移过渡方案，如提供数据转换工具或接口，帮助他们顺利过渡到新的数据结构和数据内容。
- 用户培训和支持 ：为消费者提供用户培训和支持，帮助他们了解数据变更的内容和影响，以及如何应对这些变化。

通过这些措施，我们可以减少数据变更对消费者的影响，提高用户满意度。

5. 架构变更的综合评估

在评估系统架构变更时，我们需要综合考虑基础设施、微服务和数据三个方面的变更情况。以下是一个综合评估的流程图：

graph LR
    A[确定变更需求] --> B[评估基础设施变更]
    B --> C[评估微服务变更]
    C --> D[评估数据变更]
    D --> E[综合评估变更影响]
    E --> F[制定变更方案]
    F --> G[实施变更]
    G --> H[验证变更效果]
    H --> I{是否满足需求}
    I -- 是 --> J[结束]
    I -- 否 --> A

综合评估变更影响时，我们可以从以下几个方面进行考虑：
- 实现成本 ：综合考虑基础设施、微服务和数据变更的实现成本，确保变更方案在预算范围内。
- 协调成本 ：评估变更过程中涉及的团队和人员之间的协调成本，尽量减少沟通和协作的难度。
- 停机时间 ：考虑变更对系统停机时间的影响，采取措施尽量减少停机时间，确保系统的可用性。
- 消费者影响 ：评估变更对消费者的影响，采取措施减少消费者的不便，提高用户满意度。

6. 变更管理的最佳实践

为了确保系统架构变更的顺利进行，我们可以遵循以下最佳实践：
- 制定变更管理计划 ：在进行变更之前，制定详细的变更管理计划，明确变更的目标、范围、时间节点和责任人。
- 进行充分的测试 ：在变更实施之前，进行充分的测试，包括单元测试、集成测试、系统测试和用户验收测试，确保变更不会引入新的问题。
- 建立回滚机制 ：在变更实施过程中，建立回滚机制，以便在出现问题时能够及时回滚到变更前的状态。
- 进行变更后评估 ：在变更实施完成后，进行变更后评估，总结经验教训，为后续的变更管理提供参考。

通过遵循这些最佳实践，我们可以提高变更管理的效率和质量，确保系统架构能够灵活、稳定地应对各种变更。

7. 总结

系统架构变更管理是一个复杂的过程，涉及到基础设施、微服务和数据等多个方面。在进行变更管理时，我们需要综合考虑实现成本、协调成本、停机时间和消费者影响等因素，采取相应的措施进行评估和优化。通过遵循最佳实践，建立完善的变更管理机制，我们可以确保系统能够高效、稳定地运行，为业务的发展提供有力的支持。同时，我们也要不断关注技术的发展和业务的变化，及时调整系统架构，以适应不断变化的市场需求。