本文档介绍了一种架构，该架构使用 Istio 服务网格将功能逐个从旧版环境（例如在虚拟机中运行应用的本地数据中心）迁移到 Google Kubernetes Engine (GKE)。服务网格将网络功能与服务功能分离开来，因此可以降低迁移和重构的复杂性。
本文档说明了迁移的基本原理，并概述了迁移的简要阶段。您可以使用此架构在一次操作中执行迁移（有时称为“大爆炸迁移”）或逐渐执行功能迁移。随附的部署文档将引导您完成一次示例迁移。
此架构及其部署指南面向负责管理复杂基础架构，且希望在尽可能减少以下问题的前提下对其执行逐步迁移及现代化改造的 IT 专业人员：
- 停机时间
- 重构工作量
- 网络运营复杂度
本文档中介绍的概念适用于任何云环境，因此假设您熟悉云技术、容器和微服务。
如迁移到 Google Cloud：使用入门中所述，迁移到云端有几种模式。本文档中的架构使用重构模式（有时称为“移动并改进”模式），采用这种模式时，该模式会运用于应用的各个特性，而非运用于整个应用。
在迁移过程中，应用采用混合架构，其中一些特性位于 Google Cloud 上，而一些特性仍留在旧版环境中。迁移完成后，整个应用会托管在 Google Cloud 上。
架构
下图展示了如何使用服务网格将流量路由到来源环境中运行的微服务或路由到 Google Cloud：
该架构包括以下组件：
来源环境，在本例中，是托管要迁移的示例工作负载的 Compute Engine 实例。来源环境也可以是本地环境，也可以托管在其他云平台中。
服务网格（在本例中为 Istio 网关），用于将不同的服务关联在一起。服务网格提供高价值的网络功能，例如服务发现、安全通信、负载均衡、流量管理和可观测性。
服务网格的典型实现是将每项服务与提供这些特性的代理配对。服务代理通常被称为“辅助资源”。辅助资源的作用是增强和改进其附加到的应用，而应用往往不知道辅助资源的存在。在随附的部署指南中，您可以将 Envoy 用作 Sidecar 代理。
包含由微服务组成的应用的工作负载。微服务是一种独立组件，旨在容纳应用的一项特性。在此架构中，应用由用户无法区分的多个不同微服务组成。例如，处理图书评论的组件就属于一个微服务。
在微服务模式中，应用是多个微服务的集合，每个微服务具有一个特定目标。例如，您可能具有一个处理图书评分的微服务，另外还有一个处理图书评论的微服务。这些微服务应该松散耦合，且应通过明确定义的 API 相互连接。它们可以使用不同语言和框架进行编写（就像在 Polyglot 应用中一样），可以具有不同的生命周期。
一个容器，用于进一步定义每个微服务的边界。由于此架构中的目标环境是使用 Kubernetes 进行编排的，因此我们建议您使用以下工具将微服务容器化：
- Docker 是一种用于在操作系统级隔离用户空间级程序的工具。它运行称为容器容器的软件包。
- Kubernetes 是领先的容器化工作负载编排解决方案。它提供服务发现、负载平衡、自我修复 pod 和节点以及 Secret 和配置管理等功能。
- GKE 是一个可正式投入使用的托管式 Kubernetes 环境，属于 Google Cloud。
如需使用服务网格执行迁移，您需要完成以下阶段：
- 评估旧版环境：收集信息，并为目标环境确定一组需求以及一项测试和验证基准。
- 在目标环境中构建基础：预配目标环境并应用基础架构即代码方法，让您的基础架构可审核、可重复且可自动预配。
- 部署服务并开始将流量路由到目标环境：完成单个操作以同时部署所有微服务实例，或完成逐步部署以逐个部署一个微服务。
- 停止将流量路由到旧版环境：设置路由规则，以将流量路由到仅在目标环境中运行的服务。
- 停用旧版环境：更新 DNS 记录以指向您在目标环境预配阶段设置的负载均衡器。
本文档介绍了此类迁移的一些设计注意事项，随附的部署指南提供了完成迁移的详细步骤。
设计考虑事项
本部分提供的指导可帮助您开发满足特定的可靠性、运营效率、费用和性能优化要求的架构。
可靠性
以下部分介绍了迁移可靠性的注意事项。
采用逐步迁移策略
虽然此架构可用于单操作迁移，但我们建议您采用渐进式迁移策略。由于一次性迁移一个或多个应用存在较大的挑战和风险，因此一次操作完成迁移很难实现。如果您的时间和预算有限，专注于一次性迁移只会导致您没有足够的时间和预算去开发新的应用特性。
相比之下，采用逐个特性的逐步迁移方法时，由于每个特性的覆盖面要小于整个应用，因此迁移工作负载的规模较小，整体复杂度也较低。逐步迁移方法让您可以通过多个较小规模的迁移实践来分散风险，避免采用一次性、高风险的迁移方案。此外，在采用逐步迁移方法时，迁移团队还能规划、设计和制定多项迁移策略，适应不同类型的特性。
如需了解有关如何选择要优先迁移的特性、如何迁移有状态特性的指南，请参阅“迁移到 Google Cloud：评估和发现您的工作负载”中的选择要先迁移的应用。
使用合规性测试套件
为了帮助您顺利完成迁移，我们建议您使用合规性测试套件。合规测试套件是一组可针对某个环境运行的测试，用于检查此环境是否满足给定的一组要求。如果环境有效，则表示其符合要求。例如，您可以验证对测试请求的响应，还可以检查是否已安装应用的依赖项。
如需执行手动验证，您可以从监视、跟踪和服务网格可视化工具入手。然后，您可以通过以下方式实现测试套件，并不断对其加以完善改进：
- 负载测试。您可以测试流量自动发送到环境并评估结果，以便改进测试套件。
- 合规性测试工具：您可以使用专用工具设计和开发测试套件。
针对旧版环境运行合规测试套件，将其结果作为基准，随后在迁移期间和迁移之后针对目标环境运行合规测试套件。
您的测试套件应侧重于在迁移期间执行以下几个方面的验证：
- 预配：首先在环境中预配必要的资源，以便后续执行资源配置。
- 配置：在环境中预配资源后，根据应用需求对其进行配置。采用一个配置测试套件，确保环境准备好托管您的应用。
- 业务逻辑：验证环境的预配与配置之后，对应用的业务逻辑执行验证。例如，您可以验证对请求的响应情况。
Chef InSpec、RSpec 和 Serverspec 工具均可用于开发自动化合规测试套件。它们适用于任何平台，并且具有可扩展的特点，让您可以基于内置控件实现自己的控件。
在预配目标环境时，您可以使用合规性测试套件对其进行验证。您可能需要在考虑到旧版环境与目标环境间根本差异（例如硬件和网络拓扑）的前提下更新测试套件。切记，您正在从由您全权掌控的本地环境迁移到公有云环境，而在公有云环境中，您通常不具备对整个堆栈的完整访问权限。
在将流量从旧版环境的负载均衡层路由到目标环境之前，我们建议您针对目标环境公开的微服务运行业务逻辑合规性测试套件。测试套件有助于确保微服务按预期运行。例如，您可以验证服务网格公开的服务所返回的响应。您可以将原始路由保留为备用选项，以防需要回滚更改并还原到旧版环境。通过将一小部分生产流量路由到目标环境中运行的微服务实例，您可以树立对目标环境的信心，并逐渐增加路由到目标环境中微服务实例的流量占总体流量的比例。
禁止跨环境请求
在合规性测试阶段，我们建议您优化路由规则，禁止跨环境请求，这样无论在客户端请求传送到旧版环境还是目标环境，都会保留在相应的环境中。禁止跨环境请求有助于确保测试正确验证目标环境。如果您不禁止这些请求，测试可能会在来源环境（而不是目标环境）中报告成功，而您却一无所知。
停用旧版环境
在停用旧环境之前，请验证以下所有条件是否均成立：
- 目前没有任何流量路由到在旧版环境中运行的微服务实例。
- 没有任何流量通过旧版环境的接口传输。
- 目标环境已全面经过验证。
满足这些条件后，您就可以更新 DNS 记录，将其指向您在目标环境预配阶段设置的负载平衡器。 除非您确定目标环境已通过验证，否则请勿停用旧版环境。您不要仅验证业务逻辑，还要考虑其他非功能性需求，例如性能和可扩缩性。
运营效率
以下部分介绍了迁移的运营效率注意事项。
评估旧版环境
在设计或实施迁移计划之前，您应评估旧版环境以收集信息，并为目标环境确定一组需求以及一项测试和验证基准。首先，您需要构建一个包含要迁移的所有应用特性的目录。对于每项特性，您都应该能够回答这组问题（并非详尽无遗）：
- 运行时环境是什么？有哪些性能要求？
- 与其他特性是否存在依赖关系？
- 是否属于业务关键型特性？
- 属于无状态特性还是有状态特性？
- 为了迁移此特性，预计需要执行多少重构工作？
- 此特性能否承受切换期？
如需了解详情，请参阅迁移到 Google Cloud：评估和发现您的工作负载。
无状态资源与有状态资源
该架构使用服务网格，因为它将服务功能（业务逻辑的实现方式）与网络功能（如何以及何时将流量路由到服务功能）分离开来。随附的部署中使用 Istio 作为服务网格。
在旧版环境中，大多数服务调用不会涉及到网络，因为这些服务调用是在同一个单体式平台中发生的。在微服务架构中，服务之间的通信要通过网络进行，服务必须妥善应对这种不同的模型。服务网格单独抽象出处理网络通信的功能，因此您不需要在每个应用中实现这类功能。 服务网格还能降低网络的操作复杂性，因为它提供了安全通信通道、负载均衡、流量管理和可观测性功能，无需任何配置。
通过部署和配置服务网格，您可以将流量动态路由到旧版环境或目标环境。流量管理对于网格中的服务是透明的，因此您无需修改应用配置即可支持迁移。
这种方法能够很好地处理无状态特性，但如果要迁移有状态、对延迟较为敏感或与其他功能高度耦合的特性，您需要进行额外的规划和重构：
- 有状态：迁移有状态特性时，您必须同时迁移数据，以最大限度地减少停机时间，并缓解迁移期间的同步和完整性问题。如需详细了解数据迁移策略，请参阅“迁移到 Google Cloud：转移大型数据集”中的评估数据迁移方法部分。
- 延迟敏感型特性：如果某项特性在与其他特性通信时对于延迟较为敏感，那么在迁移过程中，您可能需要部署额外的组件。通常会使用能够预取数据或缓存层的代理来缓解这种敏感性。
- 与其他特性高度耦合的特性：如果有两项或多项特性高度耦合，那么您可能必须同时迁移这些特性。虽然这种方法仍要比迁移整个应用简单一些，但与迁移单个特性相比，可能较为困难。
向服务网格注册服务
由于您的旧版环境并非直接与服务网格集成，因此在配置迁移时，您必须手动向服务网格注册在旧版环境中运行的所有服务。如果您的环境已在 Kubernetes 中运行，那么您可以使用与服务网格 API 的内置集成来实现注册自动化。
注册旧版环境后，您可以使用服务网格公开在旧版环境中运行的微服务。然后，您可以逐步将通过旧版环境接口传送到微服务的流量路由到目标环境的接口。
客户端不会注意到任何服务中断，因为它们会通过一个负载平衡层访问两个环境的接口。服务网格内的流量路由对客户端来说是透明的，因此客户端不会知道路由配置已更改。
费用优化
此架构使用 Google Cloud 的以下收费组件：
在部署架构时，您可以使用价格计算器根据预计使用量来估算费用。
性能优化
在此架构中，在 Compute Engine 中运行的服务与在 GKE 中运行的服务之间，流量几乎是相等的。该服务网格会在所选服务的实例之间均衡流量，无论它们是在 GKE 集群还是在 Compute Engine 实例中运行。如果您希望所有流量都经过服务网格，则需要重新配置在 Compute Engine 中运行的工作负载以指向服务网格中的服务，而不是直接连接到它们。您可以使用 DestinationRule 资源为每项服务的修订版本配置负载均衡政策。
部署
如需部署此架构，请参阅使用 Istio 网格扩展功能部署迁移。