22、利用 API 实现系统演进与云迁移

利用 API 实现系统演进与云迁移

1. 测试与代码重构

在不运行整个系统的情况下进行测试是一种有效的方法，例如使用模拟对象（mocks）或测试替身（test doubles）。但如果应用程序设计不佳，定义代码中的“接缝”（seams）可能会很复杂，这会增加理解代码整体行为的难度。在处理遗留代码时，将代码拆分成更模块化的形式并进行重构也会变得困难。

对于没有测试的遗留代码，Nicolas Carlo 提出了一个有用的拆分“接缝”的方法：
1. 识别变更点（接缝） ：找出代码中可能发生变化的部分。
2. 打破依赖 ：减少代码之间的耦合，使各部分能够独立演进。
3. 编写测试 ：为代码添加测试，确保修改不会引入新的问题。
4. 进行更改 ：根据需求对代码进行修改。
5. 重构 ：优化代码结构，提高代码的可读性和可维护性。

在设计变更时，可以考虑为两个或多个协作组件创建 API 设计。如果“接缝”的定义可能在其他地方使用，跨服务 API 是一个不错的选择。例如，当代码库中多个部分有相似的执行逻辑，并且目标是将一个服务拆分成更小的基于服务的架构时，就有机会定义跨服务的复用。

2. 识别系统中的变更杠杆点

有时，架构师或开发人员很容易识别出“变更杠杆点”，即那些明显需要重构和更改以提升系统性能、可扩展性或安全性的代码和服务。但在继承一个代码库或系统时，这些杠杆点并不总是显而易见的。这时，可以借助一些工具和书籍来帮助理解代码和应用程序，如 Adam Tornhill 的相关书籍，以及版本控制系统的变更检测工具和软件复杂度测量工具。

3. 持续交付与验证

持续验证系统对于实现演进式架构至关重要。自动化部署和发布松散耦合的系统能提高效率和可靠性。

4. 使用 API 演进系统的架构模式

APIs 为系统向现代架构演进以及引入新功能和变更提供了强大的抽象。以下是一些有助于向 API 迁移的架构模式：
- Strangler Fig 模式 ：
- 该模式类似于热带榕树围绕现有树木生长，目标是在旧机制仍存在的情况下引入新组件，逐步迁移到新的基于 API 的方法。
- 可以使用功能标志（feature flag）来查询遗留服务或调用新的基于 API 的服务，也可以使用代理或网关来路由 API 请求到旧实现或新实现。
- 但管理该模式可能很棘手，新组件可能成为单点故障或瓶颈，代理不应承担业务逻辑，并且要确保新旧服务之间的数据一致性。
- Facade 和 Adapter 模式 ：
- Facade 和 Adapter 模式有助于向现代服务迁移。Strangler Fig 模式是一种 Facade，它拦截 API 调用并隐藏背后的复杂性。
- Adapter 可以将旧协议（如 SOAP - RCP）的请求转换为新的 RESTful API 调用，但协议重写实现起来可能有挑战，要注意避免降低内聚性或引入耦合。
- Facade 通常比 Adapter 简单，传统 API 网关只是路由 API 请求，而 Adapter 负责将请求转换为目标应用程序能理解的表示形式。需要注意的是，如果 API 网关从 Facade 模式转变为 Adapter 模式，耦合度会立即增加。
- API Layer Cake 模式 ：
- 该模式基于传统企业单体应用中的“关注点分离”分层模式。在 2000 年代，Java 或 .NET 企业应用中常将应用功能实现为一系列分层架构，如表示层、应用层、领域层和数据存储层。
- 现代基于 API 的方法在 Gartner 的 Pace - Layered Application Strategy 中有所体现，但该模式随着时间推移声誉不佳，因为它鼓励开发人员走捷径，导致代码耦合度高，难以演进，一般建议避免使用。

5. 识别痛点与机会

在分布式基于 API 的系统中，识别系统中的痛点和问题可以为改进提供机会。
- 升级和维护问题 ：
- 识别系统中升级和报告的错误发生的位置，关注以下问题：
- 特定子系统的高变更失败率。
- 系统的大量支持问题。
- 代码库特定部分的频繁变更。
- 高复杂度（通过静态分析和圈复杂度识别）。
- 开发团队对所需变更的难易程度缺乏信心。
- 可以添加代码质量指标来大致了解潜在的问题。维护问题或子系统问题可能是引入 API 抽象以提取功能并使用 Strangler Fig 模式进行改进的机会，也可能是代码未遵循良好编码原则的信号。
- 性能问题 ：
- 服务级别协议（SLAs）是跟踪和监控性能的重要上限。许多应用程序缺乏对性能问题的主动保护机制。
- 当出现性能问题时，测量现有系统、提出性能改进假设并进行测试验证至关重要。要将系统作为一个整体考虑，而不是孤立地优化某个组件。可以将性能测量自动化，作为构建过程的一部分。
- 打破高度耦合的 API 依赖 ：
- 向分布式架构迁移时，架构的各部分能够独立演进才能带来好处。要注意避免系统不同部分之间的同步发布协调，这可能是 API 高度耦合的信号，打破这种耦合可以促进复用并减少发布摩擦。
- 处理遗留代码时，可以使用两种技术来打破依赖：
- Sprout 技术 ：在其他地方创建新功能，进行测试后添加到遗留方法的插入点。
- 包装现有功能 ：创建一个与旧方法同名同签名的新方法，重命名旧方法并在新方法中调用，同时可以在调用旧方法之前添加额外的逻辑。

以下是一个简单的 mermaid 流程图，展示了处理遗留代码的流程：

graph TD;
    A[识别变更点（接缝）] --> B[打破依赖];
    B --> C[编写测试];
    C --> D[进行更改];
    D --> E[重构];

6. 选择云迁移策略

在系统演进过程中，底层基础设施、平台和硬件的变化同样重要。API 程序有时会推动基础设施的变革，特别是向更类似云的（软件定义）基础设施迁移。

在将系统和相应的 API 基础设施迁移到云环境时，有多种方法可供选择。以将会议系统中的 Attendee 服务迁移到云供应商的基础设施为例，选择迁移策略前需要考虑多种选项。

Amazon Web Services 提出的“六个 R”云迁移策略提供了从“什么都不做”到完全重建或淘汰系统的一系列选择：
| 策略 | 说明 |
| ---- | ---- |
| Retain or Revisit | 保留或重新审视，即暂时不进行迁移，观察一段时间后再做决定。 |
| Rehost | 重新托管，将应用程序直接迁移到云环境，不做重大更改。 |
| Replatform | 重新平台化，对应用程序进行一些调整以适应云平台，但不进行大规模重构。 |
| Repurchase | 重新购买，替换现有的应用程序为云原生的解决方案。 |
| Refactor/Re - architect | 重构/重新架构，对应用程序进行全面重构，以充分利用云平台的特性。 |
| Retire | 淘汰，停止使用该系统。 |

通过深入了解这些策略，可以根据具体情况选择最适合的方法来演进 API 基础设施。

以下是一个 mermaid 流程图，展示了选择云迁移策略的简单流程：

graph TD;
    A[评估系统现状] --> B{选择迁移策略};
    B --> C[Retain or Revisit];
    B --> D[Rehost];
    B --> E[Replatform];
    B --> F[Repurchase];
    B --> G[Refactor/Re - architect];
    B --> H[Retire];

总之，使用 API 驱动的方法可以将传统单体应用演进为基于服务的架构。理解耦合和内聚等关键概念，明确系统演进的目标和约束，利用成熟的模式（如 Strangler Fig），能够使系统的演进、测试和部署更加容易和安全。同时，在进行云迁移时，合理选择迁移策略对于成功实现系统的现代化至关重要。

利用 API 实现系统演进与云迁移

7. 利用 API 基础设施向云平台演进

在前面讨论了系统演进的多种架构模式以及云迁移策略后，接下来深入探讨如何利用 API 基础设施，如 API 网关、服务网格和开发者门户，将系统迁移到云环境。

7.1 API 网关在云迁移中的作用

API 网关在云迁移中扮演着关键角色，它可以为服务和 API 提供位置透明性。这意味着在将服务部署到云环境时，可以逐步将流量从现有服务转移到新服务，而对消费者的影响最小甚至没有影响。

例如，在将会议系统的 Attendee 服务迁移到云时，API 网关可以根据预设的规则，将部分流量导向云环境中的新服务进行测试，随着新服务的稳定性提升，再逐渐增加导向新服务的流量比例，直至完全切换。

以下是使用 API 网关进行云迁移的步骤：
1. 部署云服务 ：将 Attendee 服务部署到云供应商的基础设施上。
2. 配置 API 网关 ：在 API 网关中配置新服务的地址和路由规则。
3. 流量切换 ：开始时，将少量流量导向新服务进行测试，收集反馈并确保新服务正常运行。
4. 逐步增加流量 ：随着新服务的稳定性得到验证，逐步增加导向新服务的流量比例。
5. 完全迁移 ：当新服务能够稳定处理所有流量时，将所有流量切换到云环境中的新服务。

7.2 服务网格的多位置/集群功能助力云迁移

服务网格的多位置/集群功能为服务迁移到云提供了新的选择。通过服务网格，可以在不同的位置或集群之间灵活地管理和路由流量。

例如，在迁移 Attendee 服务时，可以利用服务网格的功能，将部分流量路由到云环境中的新集群，同时保持现有集群的运行。这样可以在不影响现有服务的情况下，对新集群进行测试和优化。

以下是使用服务网格进行云迁移的步骤：
1. 部署服务网格 ：在现有环境和云环境中部署服务网格。
2. 配置服务网格 ：在服务网格中配置新服务的地址和路由规则。
3. 流量分流 ：将部分流量导向云环境中的新集群进行测试。
4. 优化和调整 ：根据测试结果，对新集群进行优化和调整。
5. 完全迁移 ：当新集群能够稳定处理所有流量时，将所有流量切换到云环境中的新集群。

8. 案例研究：将 Attendee 服务迁移到云

以会议系统的 Attendee 服务迁移到云为例，进一步说明云迁移的实际操作。

8.1 迁移背景和动机

会议系统的所有者希望最终摆脱运行自己数据中心的负担，因此决定将所有新服务、单体应用、中间件（如 API 网关）和数据存储迁移到云环境。选择先迁移 Attendee 服务，是因为它是最新的组件，并且是流量较大的服务之一。

8.2 迁移前的准备工作

在迁移之前，需要对 Attendee 服务进行全面评估，包括功能、性能、依赖关系等。同时，需要选择合适的云供应商和迁移策略。

以下是迁移前的准备工作列表：
1. 评估服务 ：对 Attendee 服务进行功能和性能评估，确定迁移的范围和目标。
2. 选择云供应商 ：根据服务的需求和预算，选择合适的云供应商。
3. 选择迁移策略 ：根据服务的特点和云供应商的支持情况，选择合适的云迁移策略，如 Rehost、Replatform 或 Refactor/Re - architect。
4. 备份数据 ：对 Attendee 服务的数据进行备份，以防止数据丢失。

8.3 迁移过程

根据选择的迁移策略，执行具体的迁移操作。以 Rehost 策略为例，迁移过程如下：
1. 创建云资源 ：在云供应商的基础设施上创建虚拟机、存储等资源。
2. 部署服务 ：将 Attendee 服务部署到云资源上。
3. 配置网络 ：配置云资源的网络，确保服务可以正常访问。
4. 迁移数据 ：将备份的数据迁移到云存储中。
5. 测试和验证 ：对迁移后的服务进行测试和验证，确保服务正常运行。

8.4 迁移后的优化和监控

迁移完成后，需要对服务进行优化和监控，以确保服务的性能和稳定性。

以下是迁移后的优化和监控措施：
1. 性能优化 ：根据监控数据，对服务进行性能优化，如调整配置参数、优化代码等。
2. 安全加固 ：加强服务的安全防护，如设置防火墙、加密数据等。
3. 监控和报警 ：设置监控系统，实时监控服务的性能和状态，及时发现并处理问题。

9. 总结

通过以上的讨论和案例分析，可以看出利用 API 实现系统演进和云迁移是一个复杂但可行的过程。在这个过程中，需要综合考虑多种因素，如架构模式、云迁移策略、API 基础设施的使用等。

以下是一些关键要点总结：
1. API 是系统演进的关键 ：API 为系统向现代架构演进提供了强大的抽象，通过合理设计和使用 API，可以实现系统的模块化和可扩展性。
2. 选择合适的架构模式 ：根据系统的特点和需求，选择合适的架构模式，如 Strangler Fig、Facade 和 Adapter、API Layer Cake 等，以促进系统的演进。
3. 关注痛点和机会 ：识别系统中的痛点和问题，如升级和维护问题、性能问题、高度耦合的 API 依赖等，并及时采取措施进行改进。
4. 合理选择云迁移策略 ：根据服务的特点和云供应商的支持情况，选择合适的云迁移策略，如 Retain or Revisit、Rehost、Replatform、Repurchase、Refactor/Re - architect 或 Retire。
5. 利用 API 基础设施 ：充分利用 API 网关、服务网格和开发者门户等 API 基础设施，实现系统的平滑迁移和演进。

总之，通过合理利用 API 和相关技术，可以实现系统的高效演进和云迁移，提升系统的性能、可维护性和竞争力。

以下是一个简单的 mermaid 流程图，展示了系统演进和云迁移的整体流程：

graph TD;
    A[识别系统痛点] --> B[选择架构模式];
    B --> C[选择云迁移策略];
    C --> D[利用 API 基础设施迁移];
    D --> E[优化和监控];

通过以上的介绍，希望能为你在系统演进和云迁移方面提供一些有益的参考和指导。