本架构指南提供了有关使用 Google Cloud 规划和设计混合云和多云环境的实用指导。本文档是该套件中三个文档中的第一个。该报告从业务和技术角度审视了与这些架构相关的机遇和注意事项。还分析和讨论了许多久经考验的混合云和多云架构模式。
混合云和多云架构模式文档集包含以下部分：
- 构建混合云和多云架构：讨论如何规划使用 Google Cloud 设计混合云和多云设置架构的策略（本文）。
- 混合云和多云架构模式：讨论在混合云和多云策略中采用的常见架构模式。
- 混合云和多云安全网络架构模式：从网络角度讨论混合云和多云网络架构模式。
您可以单独阅读这些架构文章，但为了充分发挥其作用，我们建议您在做出架构决策之前，先依次阅读这些文章。
市场需求的快速变化提高了对企业 IT 的要求和期望，例如动态扩缩、提升性能以优化用户体验以及安全性。许多企业级公司发现，仅使用传统的基础架构和流程很难满足这些需求和期望。IT 部门还面临着提高成本效益的压力，因此很难证明在数据中心和设备上进行额外的资本投资是合理的。
利用公有云计算功能的混合云策略提供了一种实用的解决方案。通过使用公有云，您可以扩展计算平台的容量和功能，而无需进行前期的资本投资。
通过向现有基础架构添加一个或多个基于公有云的解决方案（例如 Google Cloud），您不仅可以保留现有投资，还可以避免仅使用单个云供应商。此外，通过使用混合云策略，您可以在资源允许的情况下逐步实现应用和流程的现代化。
为了帮助您规划架构决策和混合云或多云策略，您应考虑以下几个潜在挑战和设计注意事项。这本由多部分组成的架构指南重点介绍了各种架构的潜在优势和潜在挑战。
混合云和多云概览
由于工作负载、基础架构和流程对每个企业都是唯一的，因此每个混合云策略都必须适应特定需求。其结果是，混合云和多云这两个术语有时的含义是不一致的。
在本 Google Cloud 架构指南的上下文中，混合云一词描述了一种架构，在该架构中工作负载部署在多个计算环境（一个基于公有云，至少有一个基于私有云，例如本地数据中心或对接网点）。
术语多云端描述了至少包含两个公共 CSP 的架构。如下图所示，有时此架构包含私有计算环境（可能包括使用私有云组件）。这种安排称为混合云和多云架构。
贡献者
作者：Marwan Al Shawi | 合作伙伴客户工程师
其他贡献者：
- Saud Albazei | 应用现代化改造客户工程师
- Anna Berenberg | 工程研究员
- Marco Ferrari | 云解决方案架构师
- Victor Morno | Cloud 网络产品经理
- ohannes Passing | 云解决方案架构师
- Mark Schlagenhauf | 网络技术文档工程师
- Daniel Strebel | 欧洲、中东和非洲地区应用现代化解决方案负责人
- Ammett Williams | 开发者关系工程师
推动因素、注意事项、策略和方法
本文档定义并讨论了业务目标、驱动因素和要求，以及这些因素在构建混合架构和多云架构时如何影响您的设计决策。
目标
组织可以将混合云或多云架构作为永久解决方案来实现特定业务目标，也可以作为临时状态来满足特定要求（例如迁移到云端）。
回答以下与您的业务相关的问题，有助于您确定业务要求，并就如何实现部分或全部业务目标建立具体预期。这些问题侧重于您的业务需要什么，而不是如何在技术层面实现这些需求。
- 哪些业务目标促使您决定采用混合云或多云架构？
- 混合云或多云架构将帮助实现哪些业务和技术目标？
- 哪些业务驱动因素影响了这些目标？
- 具体业务要求是什么？
在混合云和多云架构的背景下，企业客户的一个业务目标可能是从单个区域扩大线上销售业务或市场，成为其细分市场中的全球领军企业之一。其中一个业务目标可能是在 6 个月内开始接受来自全球（或特定区域）用户的采购订单。
为了支持上述业务要求和目标，一个潜在的主要技术目标是利用公有云的全球功能和服务，将公司 IT 基础架构和应用架构从仅限本地的模型扩展为混合架构。此目标应具体明确且可衡量，从目标区域和时间范围方面明确定义扩展范围。
一般来说，混合云或多云架构本身可能并不是一种目标，而是一种满足特定业务需求所驱动的技术目标的手段。因此，选择正确的混合云或多云架构之前要先明确这些需求。
请务必区分 IT 项目的业务目标和技术目标。您的业务目标应以贵组织的目标和使命为重点。您的技术目标应侧重于构建技术基础，使贵组织能够满足其业务要求和目标。
业务驱动因素会影响业务目标和目标的实现。因此，明确确定业务驱动因素有助于制定更贴合市场需求和趋势的业务目标。
下图展示了业务驱动因素、目标、任务和要求，以及技术目标和要求，以及所有这些因素之间的相互关系：
业务和技术驱动因素
考虑业务驱动因素对技术目标的影响。选择混合架构时，一些常见的业务驱动因素包括：
- 遵从有关数据主权的法律法规。
- 借助云财务管理和FinOps 等成本优化学科的支持，降低资本支出 (CAPEX) 或一般 IT 支出。
- 云采用可以由有助于降低资本支出 (CAPEX) 的场景驱动，例如在混合架构或多云架构中构建灾难恢复解决方案。
- 改善用户体验。
- 提高灵活性和敏捷性，以应对不断变化的市场需求。
- 提高成本和资源使用的透明度。
考虑采用混合云或多云架构的业务驱动因素列表。不要孤立地考虑这些因素。您的最终决定应取决于您的业务重点。
在贵组织认识到云端优势后，如果没有任何限制（例如费用或特定合规性要求要求将高度安全的数据托管在本地），可能会决定全面迁移。
虽然采用单一云服务提供商可以带来诸多好处，例如降低复杂性、服务之间内置集成，以及预定用量折扣等成本优化选项，但在某些情况下，采用多云架构对企业而言仍然有益。以下是采用多云架构的常见业务驱动因素，以及每个驱动因素的相关注意事项：
- 遵从有关数据主权的法律法规：最常见的情况是，某个组织将业务扩展到新区域或新国家/地区，并且必须遵守新的托管数据法规。
- 如果您当前使用的云服务提供商 (CSP) 在该国家/地区没有本地云区域，那么出于合规性考虑，常见的解决方案是使用在该国家/地区拥有本地云区域的其他 CSP。
- 降低成本：降低成本通常是采用某项技术或架构的最常见业务驱动因素。不过，在决定是否采用多云架构时，请务必考虑的不仅仅是服务费用和潜在的价格折扣。考虑在多个云端构建和运营解决方案的费用，以及现有系统可能引发的任何架构限制。
有时，与多云策略相关的潜在挑战可能大于优势。多云策略日后可能会产生额外费用。
与制定多云策略相关的常见挑战包括：
- 增加管理复杂性。
- 保持一致的安全性。
- 集成软件环境。
- 实现一致的跨云性能和可靠性。
- 构建拥有多云技术技能的技术团队可能需要花费大量资金，并且可能需要扩大团队规模，除非由第三方公司管理。
- 管理各个 CSP 提供的产品定价和管理工具。
- 如果没有能够提供统一费用可见度和信息中心的解决方案，就很难高效地管理多个环境中的费用。在这种情况下，您可以使用 Looker 云费用管理解决方案（如果适用）。如需了解详情，请参阅有效优化 Cloud Billing 费用管理的策略。
- 使用每个 CSP 提供的独特功能：借助多云架构，组织可以使用更多新技术来改进自己的业务能力产品，而不局限于单个云服务提供商提供的选项。
- 为避免任何意外风险或复杂性，请通过可行性和有效性评估来评估潜在挑战，包括前面提到的常见挑战。
- 避免供应商锁定：有时，企业希望避免受制于单一云提供商。多云方法可让他们根据业务需求选择最佳解决方案。不过，此决定的可行性取决于多种因素，例如：
- 技术依赖项
- 应用间互操作性注意事项
- 重建或重构应用的费用
- 技术技能集
- 安全性和可管理性保持一致
- 提高业务关键型应用的可靠性和可用性水平：在某些情况下，多云架构可以提供对服务中断的弹性。例如，如果某个 CSP 的一个区域发生故障，流量可以路由到同一区域中的另一个 CSP。此场景假定这两家云服务提供商都支持该区域所需的功能或服务。
如果特定国家/区域的数据驻留法规要求将敏感数据（例如个人身份信息 [PII]）存储在该位置，多云方法可以提供合规的解决方案。通过在一个区域使用两家 CSP 来实现服务中断弹性，您可以更轻松地遵守监管限制，同时满足可用性要求。
在采用多云架构之前，请先评估以下一些弹性注意事项：
- 数据移动：数据在多云环境中的移动频率如何？
- 数据迁移是否会产生大量的数据传输费用？
- 安全性和可管理性：是否存在任何潜在的安全性或可管理性复杂性？
- 功能等同：所选区域中的两个 CSP 是否都提供所需的功能和服务？
- 技术技能集：技术团队是否具备管理多云架构所需的技能？
在评估使用多云架构来提高弹性可行性时，请考虑所有这些因素。
在评估多云架构的可行性时，请务必考虑长期优势。例如，虽然在多个云上部署应用来实现灾难恢复或提高可靠性可能会在短期内增加费用，但这样可以防止服务中断或故障。此类失败可能会造成长期的财务和声誉损害。因此，权衡采用多云的短期费用与长期潜在价值也很重要。此外，长期潜在价值可能会因组织规模、技术规模、技术解决方案的关键性和行业而异。
计划成功打造混合云或多云环境的组织应考虑打造云技术卓越中心 (COE) (COE)。在您向云端迁移期间，COE 团队可以成为转变贵组织内部团队为企业提供服务方式的中介。COE 是组织更快地采用云技术、推动标准化并确保业务战略与云投资保持更紧密一致的途径之一。
如果混合云或多云架构的目标是创建临时状态，常见的业务驱动因素包括：
- 需要为短期项目降低资本支出或一般 IT 支出。
- 能够快速预配此类基础架构来支持业务用例。例如：
- 此架构可能适用于限时项目。它可用于支持在有限时间内需要大规模分布式基础架构的项目，同时仍使用本地数据。
- 需要开展为期数年的数字化转型项目，这些项目需要大型企业建立并使用混合架构一段时间，以帮助他们将基础架构和应用现代化与业务重点保持一致。
- 在企业合并后，需要创建临时的混合云、多云或混合架构。这样一来，新组织便可以为其新云架构的最终状态定义策略。两家合并的公司使用不同的云服务提供商，或者一家公司使用本地私有数据中心，另一家公司使用云，这种情况很常见。无论是哪种情况，合并和收购的第一步几乎都是集成 IT 系统。
技术推动因素
上一节介绍了业务驱动因素。为了获得批准，重大架构决策几乎总是需要这些驱动因素的支持。不过，技术驱动因素（可基于技术增益或限制）也可能会影响业务驱动因素。在某些情况下，需要将技术驱动因素转化为业务驱动因素，并说明它们可能会对业务产生哪些积极或负面影响。
以下列表并非详尽无遗，其中列出了采用混合云或多云架构的一些常见技术驱动因素：
- 构建可能很难在现有环境中实现的技术能力，例如高级分析服务和 AI。
- 提高服务质量和性能。
- 自动化和加速应用发布，以加快上市时间并缩短周期。
- 使用高级 API 和服务来加速开发。
- 加速计算和存储资源的预配。
- 使用无服务器服务更快地大规模构建弹性服务和功能。
- 使用全球基础架构功能构建全球或多区域架构，以满足特定的技术要求。
临时混合架构和临时多云架构最常见的技术驱动因素是，为从本地迁移到云或迁移到其他云提供便利。一般来说，云迁移几乎总是会自然而然地导致混合云设置。企业通常必须根据其优先事项，系统地转换应用和数据。同样，短期设置可能是为了在一定期限内使用云端提供的高级技术来验证概念。
技术设计决策
确定的技术目标及其驱动因素对于做出以业务为导向的架构决策以及选择本指南中讨论的架构模式之一至关重要。例如，为了支持特定的业务目标，公司可能会设定一个业务目标，以便在 3 到 6 个月内建立一项研究和开发实践。为支持此目标，主要的业务要求可能是：以尽可能低的资本支出构建研究和设计所需的技术环境。
在本例中，技术目标是建立临时的混合云设置。实现此技术目标的驱动因素是利用云端按需定价模式来满足前面提到的业务要求。另一个驱动因素受到特定技术要求的影响，这些要求需要具有高计算容量且快速设置的云端解决方案。
将 Google Cloud 用于混合云和多云架构
使用开源解决方案可以更轻松地采用混合云和多云方法，并最大限度地减少供应商锁定。不过，在规划架构时，您应考虑以下潜在复杂性：
- 互操作性
- 易管理性
- 费用
- 安全
在贡献于开源并支持开源的云平台上构建应用，可能会有助于简化您采用混合云和多云架构的路径。开放云是一种方法，可为您提供最多的选择并抽象复杂性。此外，Google Cloud 可让您灵活选择跨混合云环境和多云端环境迁移、构建和优化应用，同时最大限度减少供应商锁定，利用最佳解决方案并满足监管要求。
Google 也是开源生态系统的最大贡献者之一，与开源社区合作开发了 Kubernetes 等知名开源技术。作为代管式服务推出时，Kubernetes 可以帮助简化混合云和多云环境的可管理性和安全性方面的复杂性。
规划混合云和多云策略
本文档重点介绍了如何在规划混合云和多云策略时应用预定义的业务注意事项。该文档是对推动因素、注意事项、策略和模式中的指南的补充。该文章定义并分析了企业在规划此类策略时应考虑的业务注意事项。
明确并达成一致的愿景和目标
最终，混合云或多云策略的主要目的是为每个业务应用场景实现确定的业务需求和相关的技术目标，使其与特定业务目标保持一致。为实现这一目标，请创建一个结构合理的计划，其中包含以下注意事项：
请注意，定义一个可以考虑到所有工作负载和需求的计划是最困难的，特别是在复杂的 IT 环境中。此外，规划需要时间并可能导致利益相关者的愿景之争。
为避免这种情况，请先制定一份愿景陈述，至少要解决以下问题：
- 为了实现特定的业务目标，要实现哪种目标业务用例？
- 为什么当前的方法和计算环境不足以实现业务目标？
- 使用公有云时，需要优化哪些主要技术方面？
- 新方法为何以及如何优化广告系列并实现您的业务目标？
- 您计划使用混合云或多云端设置多久？
就关键业务和技术目标和驱动因素达成一致，然后获得相关利益相关方的签字，可以为规划流程的后续步骤奠定基础。为了有效地使您提议的解决方案与贵组织的总体架构愿景保持一致，请与负责领导和赞助此计划的团队和利益相关方保持一致。
确定并阐明其他注意事项
在规划混合云或多云架构时，请务必确定并达成一致意见，以便了解项目的架构和运营限制。
在运营方面，以下并非详尽无遗的列表提供了一些要求，这些要求可能会在规划架构时造成一些限制，需要加以考虑：
- 分别管理和配置多个云，而不是构建一个整体模型来管理和保护不同的云环境。
- 确保跨环境的身份验证、授权、审核和政策的一致性。
- 在各种环境中使用一致的工具和流程，以便全面了解安全性、费用和优化机会。
- 使用一致的合规性和安全标准来应用统一的治理。
在架构规划方面，最大的约束通常源于现有系统，可能包括以下内容：
- 应用之间的依赖项
- 系统间通信的性能和延迟要求
- 依赖公共云中可能不可用的硬件或操作系统
- 许可限制
- 取决于多云架构的选定区域中是否提供所需功能
如需详细了解与工作负载可移植性、数据迁移和安全方面相关的其他注意事项，请参阅其他注意事项。
设计混合云和多云架构策略
在阐明了业务目标和技术目标的具体情况以及相关的业务需求后（在理想情况下，已明确并就愿景陈述达成一致），您可以构建策略来创建混合或多云架构。
下图总结了构建此类策略的逻辑步骤。
为帮助您确定混合云或多云架构的技术目标和需求，上图中的步骤从业务要求和目标开始。具体实施方式可能会因每个业务用例的目标、驱动因素和技术迁移路径而异。
请务必记住迁移是一段旅程。下图展示了迁移到 Google Cloud 中所述的迁移历程的各个阶段。
本部分将就上图中的“评估”“规划”“部署”和“优化”阶段提供指导。它会在混合云或多云迁移的背景下显示这些信息。您应根据“迁移到 Google Cloud”指南的“迁移路径”部分中所述的指南和最佳实践来进行迁移。这些阶段可能会单独应用于每个工作负载，而不是同时应用于所有工作负载。在任何给定时间点，多个工作负载都可能处于不同的阶段：
评估阶段
在评估阶段，您需要进行初步工作负载评估。在此阶段，请考虑愿景和策略规划文档中列出的目标。首先确定可以从部署或迁移到公有云中受益的工作负载的候选列表，然后确定迁移计划。
首先，选择一个不是业务关键型或不难迁移的工作负载（对其他环境中的任何工作负载的依赖项很少或没有），但足以作为即将进行的部署或迁移的蓝图。
理想情况下，您选择的工作负载或应用应属于某个目标业务用例或功能，并且在完成后对业务有可衡量的影响。
为评估和降低任何潜在的迁移风险，请进行迁移风险评估。请务必评估候选工作负载，以确定其是否适合迁移到多云环境。此评估涉及评估应用和基础架构的各个方面，包括：
- 与所选云服务提供商的应用兼容性要求
- 价格模式
- 您选择的云服务商提供的安全功能
- 应用互操作性要求
运行评估还有助于您确定多个云环境中的数据隐私权要求、合规性要求、一致性要求和解决方案。您发现的风险可能会影响您选择迁移或运行的工作负载。
有几种类型的工具（例如 Google Cloud 迁移中心）可帮助您评估现有工作负载。如需了解详情，请参阅“迁移到 Google Cloud：选择评估工具”。
从工作负载现代化改造的角度来看，适合度评估工具有助于评估虚拟机工作负载，以确定工作负载是否适合对容器进行现代化改造或迁移到 Compute Engine。
规划阶段
在规划阶段，从确定的应用和所需的云工作负载着手，执行以下任务：
- 制定优先迁移策略，定义应用迁移波次和路径。
- 确定适用的高层级混合云或多云应用架构模式。
- 选择支持所选应用架构模式的网络架构模式。
理想情况下，您应将云网络模式与着陆区设计相结合。着陆区设计是整体混合云和多云架构的关键基础元素。设计需要与这些模式无缝集成。请勿单独设计着陆区。将这些网络模式视为着陆页设计的一部分。
着陆区可能由不同的应用组成，每个应用都有不同的网络架构模式。此外，在此阶段，请务必确定 Google Cloud 组织、项目和资源层次结构的设计，以便为混合云或多云集成和部署做好云环境着陆区的准备。
在此阶段，您应考虑以下事项：
- 定义迁移和现代化改造方法。本指南稍后会详细介绍迁移方法。迁移到 Google Cloud 的迁移类型部分也详细介绍了此方法。
- 利用评估和发现阶段的发现。将其与您计划迁移的候选工作负载保持一致。然后，制定应用迁移波次计划。该计划应纳入您在评估阶段确定的估算资源大小要求。
- 定义分布式应用之间以及应用组件之间针对预期混合云或多云架构所需的通信模型。
- 确定适合所选架构模式的工作负载部署原型，例如可用区级、区域级、多区域级或全球级。您选择的原型是构建特定于应用的部署架构的基础，这些架构可根据您的业务和技术需求量身定制。
- 确定迁移的可衡量成功标准，并为每个迁移阶段或波次设置明确的里程碑。选择标准至关重要，即使技术目标是将混合架构作为短期设置也是如此。
- 当应用在混合设置中运行时，请定义应用服务等级协议 (SLA) 和 KPI，尤其是对于可能在多个环境中分布组件的应用。
如需了解详情，请参阅迁移规划简介，以帮助规划成功的迁移并最大限度地降低相关风险。
部署阶段
在部署阶段，您可以开始执行迁移策略了。鉴于可能存在的许多要求，最好采用迭代方法。
根据您在规划阶段制定的迁移和应用波次，确定工作负载的优先级。在混合云和多云架构中，请先在 Google Cloud 与其他计算环境之间建立必要的连接，然后再开始部署。为了便于为混合云或多云架构实现所需的通信模型，请根据所选的设计和网络连接类型以及适用的网络模式进行部署。我们建议您在做出整体着陆区设计决策时采用这种方法。
此外，您必须根据定义的应用成功标准测试和验证应用或服务。理想情况下，这些标准应在迁移到生产环境之前同时包含功能测试和负载测试（非功能性）要求。
优化阶段
在优化阶段，测试您的部署：完成测试后，如果应用或服务符合预期的功能和性能容量，您就可以将其移至生产环境。Cloud 监控和可见性工具（例如 Cloud Monitoring）可以深入了解应用和基础架构的性能、可用性和运行状况，并帮助您根据需要进行优化。
如需了解详情，请参阅迁移到 Google Cloud：优化您的环境。如需详细了解如何为混合云或多云架构设计此类工具，请参阅混合云和多云环境的监控和日志记录模式。
评估候选工作负载
为不同工作负载选择计算环境对混合云和多云策略的成败有很大影响。工作负载部署决策应与特定业务目标保持一致。因此，这些决策应以可带来可衡量业务成效的目标业务应用场景为依据。不过，从对业务最重要的工作负载/应用着手并不总是必要，也不推荐这样做。如需了解详情，请参阅“迁移到 Google Cloud”指南中的选择要优先迁移的应用。
如业务和技术推动因素部分所述，混合云架构和多云架构有不同类型的推动因素和注意事项。
以下因素摘要列表可帮助您在混合云或多云架构中评估迁移用例，以便把握可带来可衡量业务成效的机会：
- 通过使用云服务实现某些业务功能或能力（例如使用现有本地数据训练机器学习模型的人工智能功能），从而实现市场差异化或创新的潜力。
- 可以节省应用的总拥有成本的潜力。
- 改进可用性、弹性、安全性或性能方面的潜力，例如在云中添加灾难恢复 (DR) 站点。
- 加速开发和发布流程的潜力，例如在云端构建开发和测试环境。
以下因素可帮助您评估迁移风险：
- 迁移导致的中断可能产生的影响。
- 您的团队在公有云部署方面的经验，或者在为新云服务提供商或第二个云服务提供商部署方面的经验。
- 需要遵守任何现有的法律或监管限制。
以下因素可以帮助您评估迁移的技术难题：
- 应用的大小、复杂性和存在时间
- 与其他应用和服务在不同计算环境中的依赖项数。
- 第三方许可施加的任何限制。
- 对特定版本的操作系统、数据库或其他环境配置的任何依赖项。
评估初始工作负载后，您可以开始确定工作负载的优先级，并定义迁移波次和方法。然后，您可以确定适用的架构模式和支持的网络模式。此步骤可能需要多次迭代，因为您的评估可能会随时间推移而发生变化。因此，在执行首次云部署后，还需要重新评估工作负载。
采用混合云或多云架构的架构方法
本文档提供了有关将工作负载迁移到云端的常见且经过验证的方法和注意事项的指南。本文详细介绍了设计混合云和多云架构策略中的指南，其中讨论了设计采用混合云或多云架构的策略时可采取的几种可能的步骤（以及推荐的步骤）。
云优先
云优先是一种常见的迁入公有云的方法。在此方法中，您将新工作负载部署到公有云，而现有工作负载保持原样。在这种情况下，仅当出于技术或组织原因而无法进行公有云部署时，才考虑在私有计算环境中进行传统部署。
云优先策略优缺点并存。从积极的方面看，它具有前瞻性。即您可以以现代化方式部署新工作负载，同时免除（或至少最大限度地减少）迁移现有工作负载带来的麻烦。
虽然云优先方法可以提供一定的优势，但可能会导致错失改进或使用现有工作负载的机会。因为新工作负载可能只占整体 IT 环境的一小部分，并且它们对 IT 支出和性能的影响可能有限。与尝试在云环境中部署新工作负载相比，分配时间和资源来迁移现有工作负载可能会带来更显著的好处或节省更多费用。
遵循严格的云优先方法还有可能增加 IT 环境的整体复杂性。这种方法可能会产生冗余，由于可能过度的跨环境通信而导致性能降低，或者导致计算环境不适合单个工作负载。此外，遵守行业法规和数据隐私权法律可能会限制企业迁移包含敏感数据的某些应用。
考虑到这些风险，您最好只针对选定的工作负载使用云优先方法。采用云优先方法后，您就可以专注于可以从云部署或迁移中受益最多的工作负载。此方法还考虑了现有工作负载的现代化。
云优先混合架构的一个常见示例是，存储关键数据的旧版应用和服务必须与新数据或应用集成。如需完成集成，您可以使用混合架构，通过 API 接口对旧版服务进行现代化改造，以便全新的云服务和应用能够使用这些服务。借助云端 API 管理平台（例如 Apigee），您可以只需进行最少的应用更改即可实现此类用例，并为旧版服务增强安全性、分析能力和可伸缩性。
迁移和现代化
混合多云和 IT 现代化是在良性循环中相互关联的独特概念。使用公有云可以促进和简化 IT 工作负载的现代化。对 IT 工作负载进行现代化改造有助于您从云端受益更多。
现代化工作负载的主要目标如下：
- 实现更高的敏捷性，以便您能够适应不断变化的需求。
- 降低基础架构和运营成本。
- 提高可靠性和弹性，最大限度地降低风险。
不过，在迁移过程中，同时对每个应用进行现代化改造可能并不可行。如迁移到 Google Cloud 中所述，您可以实现以下一种迁移类型，甚至根据需要组合多种类型：
- 重新托管（直接原样迁移）
- 更换平台（迁移并优化）
- 重构（迁移并改进）
- 重新设计架构（继续进行现代化改造）
- 重建（移除并替换，有时称为“淘汰并替换”）
- 重新购买
在就混合架构和多云架构做出战略决策时，请务必从成本和时间角度考虑策略的可行性。您不妨考虑分阶段迁移方法，先进行直接原样迁移或平台迁移，然后再进行重构或架构调整。通常，直接原样迁移有助于从基础架构的角度优化应用。应用在云端运行后，您可以更轻松地使用和集成云服务，以便利用云优先架构和功能进一步优化应用。此外，这些应用仍可通过混合网络连接与其他环境通信。
例如，您可以基于基于云的微服务架构，重构或重新设计基于虚拟机的大型单体式应用，并将其转换为多个独立的微服务。在本例中，微服务架构使用 Google Cloud 托管式容器服务，例如 Google Kubernetes Engine (GKE) 或 Cloud Run。不过，如果目标云环境不支持应用的原有架构或基础架构，您不妨考虑先从迁移平台、重构或重构迁移策略入手，在可行的情况下克服这些限制。
使用上述任何迁移方法时，请考虑对应用进行现代化改造（如果适用且可行）。实现现代化可能需要采用和实施站点可靠性工程 (SRE) 或 DevOps 原则，因此您可能还需要在混合设置中将应用现代化扩展到私有环境。虽然实现 SRE 原则的核心涉及工程，但这更像是一个转型过程，而不是一项技术挑战。因此，这可能需要改变流程和文化。如需详细了解在组织中实施 SRE 的第一步是获得领导层的支持，请参阅 在 SRE 中，不规划就是在规划失败。
混合和匹配迁移方法
这里介绍的每种迁移方法各有优劣，因此要实施混合云和多云端策略，您无需只采用一种方法。相反，您可以决定最适合每个工作负载或应用堆栈的方法，如下图所示。
此概念图展示了可同时应用于不同工作负载的各种迁移和现代化路径或方法，这些路径或方法取决于每个工作负载或应用的独特业务、技术要求和目标。
此外，相同的应用堆栈组件不必采用相同的迁移方法或策略。例如：
- 您可以使用 Google Cloud 中的 Cloud SQL，将应用的后端本地数据库从自托管 MySQL 迁移到托管式数据库。
- 您可以使用 GKE Autopilot 重构应用前端虚拟机，以便在容器上运行，Google 会管理集群配置，包括节点、伸缩、安全性和其他预配置设置。
- 您可以将本地硬件负载均衡解决方案和 Web 应用防火墙 WAF 功能替换为 Cloud Load Balancing 和 Google Cloud Armor。
如果工作负载中出现以下任何一种情况，请选择重新托管（直接迁移）：
- 它们对环境的依赖项相对较少。
- 它们被认为不值得重构，或者在迁移之前无法重构。
- 它们基于第三方软件。
对于具有以下特点的工作负载，请考虑重构（迁移和改进）：
- 它们具有必须解开的依赖项。
- 它们依赖于无法迁移到云端的操作系统、硬件或数据库系统。
- 它们无法有效利用计算或存储资源。
- 若要以自动化方式部署，需要付出一些努力。
对于以下类型的工作负载，请考虑重建（移除和替换）是否符合您的需求：
- 它们不再满足当前的需求。
- 它们可以与提供类似功能的其他应用集成，而不会影响业务要求。
- 它们基于已达到使用寿命的第三方技术。
- 它们需要支付多余的第三方许可费。
快速迁移计划介绍了 Google Cloud 如何帮助客户利用最佳实践、降低风险、控制费用，并简化成功实现云迁移之路。
其他注意事项
本文档重点介绍了在塑造整体混合云和多云架构方面发挥关键作用的核心设计注意事项。全面分析和评估整个解决方案架构中的这些注意事项，涵盖所有工作负载，而不仅仅是特定工作负载。
Refactor
在重构迁移中，您可以修改工作负载以利用云功能，而不仅仅是修改工作负载以使其在新环境中工作。您可以针对性能、功能、费用和用户体验来改进每个工作负载。正如重构：迁移和改进中所强调的那样，在某些重构场景中，您可以在将工作负载迁移到云端之前对其进行修改。这种重构方法具有以下优势，尤其是在您的目标是将混合架构构建为长期目标架构时：
- 您可以改进部署过程。
- 通过投资持续集成/持续部署 (CI/CD) 基础架构和工具，您可以加快发布节奏并缩短反馈周期。
- 您可以将重构作为基础，构建和管理具有应用可移植性的混合架构。
为了顺利实施此方法，通常需要对本地基础架构和工具进行投资。例如，设置本地 Container Registry 并配置 Kubernetes 集群以容器化应用。在这种混合环境中，Google Kubernetes Engine (GKE) Enterprise 版会很有用。下一部分将详细介绍 GKE Enterprise。您还可以参阅 GKE Enterprise 混合环境参考架构，了解更多详情。
工作负载可移植性
在混合架构和多云架构中，您可能希望能够在托管数据的计算环境之间迁移工作负载。为了帮助在环境之间无缝移动工作负载，请考虑以下因素：
- 您可以将应用从一个计算环境迁移到另一个计算环境，而无需对应用及其运维模式进行重大修改：
- 应用部署和管理在各个计算环境中保持一致。
- 可见性、配置和安全性在各种计算环境中保持一致。
- 使工作负载可移植的能力不应与工作负载的云优先性质产生冲突。
基础架构自动化
基础架构自动化对于混合云和多云架构中的可移植性至关重要。自动创建基础架构的一种常见方法是使用基础架构即代码 (IaC)。IaC 涉及在文件中管理基础架构，而不是在界面中手动配置资源（例如虚拟机、安全群组或负载均衡器）。Terraform 是一种常用的 IaC 工具，用于在文件中定义基础架构资源。此外，借助 Terraform，您还可以在异构环境中自动创建这些资源。
如需详细了解可帮助您自动预配和管理 Google Cloud 资源的 Terraform 核心功能，请参阅 适用于 Google Cloud 的 Terraform 蓝图和模块。
您可以使用 Ansible、Puppet 或 Chef 等配置管理工具来建立通用部署和配置过程。或者，您可以使用类似 Packer 这样的映像定义工具，为不同的平台创建虚拟机映像。通过使用单个共享配置文件，您可以使用 Packer 和 Cloud Build 创建用于 Compute Engine 的虚拟机映像。最后，您可以使用 Prometheus 和 Grafana 等解决方案来帮助确保跨环境监控的一致性。
基于这些工具，您可以汇编一个通用工具链，如下逻辑图所示。此常见工具链抽象出计算环境之间的差异。它还可以统一预配、部署、管理和监控。
虽然常见的工具链可以帮助您实现可移植性，但它有以下几个缺点：
- 使用虚拟机作为通用基础很难实现真正的云优先应用。此外，仅使用虚拟机会导致您无法使用云端托管的服务。您可能会错失减少管理开销的机会。
- 构建和维护通用工具链会产生管理费用和运营成本。
- 随着工具链的扩展，它可能会因您公司独特的需求而变得复杂。这种复杂性的增加可能会导致训练费用增加。
在决定开发工具和自动化功能之前，请先探索您的云服务提供商提供的托管服务。如果您的提供商提供支持相同用例的托管服务，您就可以抽象出其中的一些复杂性。这样，您就可以专注于工作负载和应用架构，而不是底层基础架构。
例如，您可以使用 Kubernetes 资源模型，通过声明式配置方法自动创建 Kubernetes 集群。您可以使用 Deployment Manager Convert 将 Deployment Manager 配置和模板转换为 Google Cloud 支持的其他声明式配置格式（例如 Terraform 和 Kubernetes 资源模型），以便在发布时实现可移植性。
您还可以考虑自动创建项目以及在这些项目中创建资源。此自动化功能可帮助您采用基础架构即代码方法进行项目预配。
容器和 Kubernetes
使用云端管理的功能有助于降低构建和维护自定义工具链以实现工作负载自动化和可移植性的复杂性。不过，仅使用虚拟机作为通用基础很难实现真正的云优先应用。一种解决方案是改用容器和 Kubernetes。
当您将软件从一个环境移动到另一个环境时，容器可帮助您的软件可靠地运行。由于容器可将应用与底层主机基础架构解耦，因此有助于在混合云和多云等计算环境中部署应用。
Kubernetes 负责处理容器化应用的编排、部署、伸缩和管理。它是开源的，由 Cloud Native Computing Foundation 管理。使用 Kubernetes 可提供构成云优先型应用基础的服务。因为您可以在许多计算环境中安装和运行 Kubernetes，所以您还可以使用它在跨计算环境中建立通用运行时层：
- Kubernetes 在云或私有计算环境中提供相同的服务和 API。此外，使用 Kubernetes 的抽象级别远高于使用虚拟机时的抽象级别，这通常会转化为较少的基础工作并提高开发者的工作效率。
- 与自定义工具链不同，Kubernetes 被广泛用于开发和应用管理，因此您可以利用现有的专业知识、文档和第三方支持。
- Kubernetes 支持满足以下条件的所有容器实现：
- 支持 Kubernetes 容器运行时接口 (CRI)
- 已被业界采用
- 不依赖于任何特定的供应商
当工作负载在 Google Cloud 上运行时，您可以通过使用代管的 Kubernetes 平台（例如 Google Kubernetes Engine [GKE]）来避免安装和运行 Kubernetes 的工作。这样可以帮助运维人员将重点从构建和维护基础架构转移到构建和维护应用。
您还可以使用 Autopilot，这是一种 GKE 运维模式，用于管理集群配置，包括节点、伸缩、安全性和其他预配置设置。使用 GKE Autopilot 时，请考虑您的伸缩要求及其伸缩限制。
从技术层面讲，您可以在许多计算环境中安装和运行 Kubernetes，以建立通用运行时层。但在实际操作中，构建和运行此类架构可能会带来复杂性。如果您需要容器级安全控制（服务网格），架构会变得更加复杂。
为了简化多集群部署的管理，您可以使用 GKE Enterprise 在任何位置大规模运行现代应用。GKE 包含强大的托管式开源组件，可保护工作负载、强制执行合规性政策，并提供深入的网络可观测性和问题排查功能。
如下图所示，使用 GKE Enterprise 意味着您可以将多集群应用作为舰队进行操作。
GKE Enterprise 提供以下设计选项，以支持混合架构和多云架构：
设计和构建本地或统一解决方案，以便将应用迁移到 GKE Enterprise 混合环境，从而获得类似云端的体验。如需了解详情，请参阅 GKE Enterprise 混合环境参考架构。
借助 GKE Multi-Cloud，您可以设计和构建解决方案，通过一致的治理、运营和安全状况来解决多云复杂性。如需了解详情，请参阅 GKE Multi-Cloud 文档。
GKE Enterprise 还提供类似环境的逻辑分组，可实现一致的安全、配置和服务管理。例如，GKE Enterprise 支持零信任分布式架构。在零信任分布式架构中，部署在本地或其他云环境中的服务可以通过端到端 mTLS 安全服务到服务通信在不同环境中进行通信。
工作负载可移植性注意事项
Kubernetes 和 GKE Enterprise 为工作负载提供了一个抽象层，可以隐藏计算环境之间的许多复杂性和差异。以下列表介绍了其中一些抽象：
- 应用可以通过最少的更改移植到不同的环境，但这并不意味着应用在两种环境中都能同样良好地运行。
- 底层计算、基础架构安全功能或网络基础架构的差异以及与依赖服务的接近度可能会导致性能大不相同。
- 在计算环境之间移动工作负载可能还需要您移动数据。
- 不同的环境可以有不同的数据存储和管理服务和设施。
- 使用 Kubernetes 或 GKE Enterprise 预配的负载平衡器的行为和性能可能会因环境而异。
数据移动
由于在计算环境之间大规模移动、共享和访问数据可能很复杂，因此企业级公司可能会犹豫不决是否要构建混合或多云架构。如果他们已经在本地或单个云端存储了大部分数据，这种犹豫可能会加深。
不过，Google Cloud 提供的各种数据迁移选项为企业提供了一整套全面的解决方案，可帮助他们迁移、集成和转换数据。这些选项可帮助企业以符合其特定用例的方式在不同环境中存储、共享和访问数据。最终，这有助于企业和技术决策者更轻松地采用混合云和多云架构。
在制定混合云和多云策略以及架构规划时，数据迁移是一项重要的考量因素。您的团队需要确定不同的业务应用场景以及支持这些场景的数据。您还应考虑存储类型、容量、易用性和移动选项。
如果企业针对受监管行业制定了数据分类，则该分类有助于确定特定数据类别的存储位置和跨区域数据传输限制。如需了解详情，请参阅敏感数据保护。敏感数据保护是一项全代管式服务，旨在帮助您发现、分类和保护数据资产。
如需了解从规划数据转移到使用最佳实践的完整流程，请参阅迁移到 Google Cloud：传输大型数据集。
安全
随着组织采用混合架构和多云架构，其攻击面可能会增加，具体取决于其系统和数据在不同环境中的分布方式。再加上不断变化的威胁形势，攻击面扩大可能会导致未经授权的访问、数据丢失和其他安全事件的风险增加。在规划和实施混合云或多云策略时，请仔细考虑安全性。
如需了解详情，请参阅 Google Cloud 的攻击面管理。
在构建混合架构时，将本地安全方法扩展到云端并不总是从技术上可行或可行。不过，硬件设备的许多网络安全功能都是云优先功能，并且以分布式方式运行。如需详细了解 Google Cloud 的云优先网络安全功能，请参阅云网络安全。
混合云和多云架构可能会带来额外的安全挑战，例如一致性和可观测性。每家公有云提供商都有自己的安全方法，包括不同的模型、最佳实践、基础架构和应用安全功能、合规义务，甚至安全服务的名称。这些不一致性可能会增加安全风险。此外，每家云服务提供商的责任共担模型也可能有所不同。请务必确定并了解多云架构中各个层级的确切职责划分。
可观测性对于从不同环境中获取数据分析和指标至关重要。在多云架构中，每个云平台通常都提供用于监控安全状况和错误配置的工具。不过，使用这些工具会导致数据孤岛化，从而无法在整个环境中构建高级威胁情报。因此，安全团队必须在工具和信息中心之间切换，才能确保云端安全无虞。如果没有对混合云和多云环境的全面端到端安全可见性，就很难确定漏洞的优先级并加以缓解。
如需全面了解所有环境的状况，请确定漏洞的优先级，并缓解您发现的漏洞。我们建议采用集中式公开范围模型。集中式可见性模型可避免在不同平台上手动关联不同的工具和信息中心。如需了解详情，请参阅混合云和多云环境的监控和日志记录模式。
在规划如何降低安全风险并在 Google Cloud 上部署工作负载时，为帮助您规划和设计云解决方案以实现安全性和合规性目标，请探索 Google Cloud 安全最佳实践中心和企业基础蓝图。
合规性目标可能会因行业特定法规以及不同区域和国家/地区不同的法规要求而异。如需了解详情，请参阅 Google Cloud 合规性资源中心。以下是构建安全的混合云和多云架构的一些主要建议方法：
制定量身定制的统一云安全策略和架构。混合云和多云安全策略应根据贵组织的具体需求和目标量身定制。
在实现安全控制措施之前，请务必了解目标架构和环境，因为每个环境都可以使用不同的功能、配置和服务。
考虑采用跨混合云和多云环境的统一安全架构。
标准化云设计和部署，尤其是安全设计和功能。这样可以提高效率，并实现统一的治理和工具。
使用多种安全控制措施。
通常，没有任何单一安全控制措施可以充分满足所有安全保护要求。因此，组织应采用分层防御方法（也称为深度防御）来组合使用多种安全控制措施。
监控和持续改进安全状况：贵组织应监控其不同的环境，以防范安全威胁和漏洞。还应努力不断改进其安全状况。
考虑使用云安全状况管理 (CSPM) 来识别和修复安全配置错误和网络安全威胁。CSPM 还提供跨混合云和多云环境的漏洞评估。
Security Command Center 是 Google Cloud 的内置安全和风险管理解决方案，可帮助识别错误配置、漏洞等问题。Security Health Analytics 是一款代管式漏洞评估扫描工具。这是 Security Command Center 的一项功能，可识别 Google Cloud 环境中的安全风险和漏洞，并提供相应的修复建议。
借助 Mandiant Attack Surface Management for Google Cloud，贵组织可以更好地了解其多云或混合云环境资产。该工具可自动发现来自多个云服务提供商、DNS 和扩展的外部攻击面的资产，让贵企业能够更深入地了解其生态系统。使用这些信息确定风险最高的漏洞和风险的修复优先级。
- 云安全信息和事件管理 (SIEM) 解决方案：有助于收集和分析来自混合云和多云环境的安全日志，以检测和响应威胁。 Google Cloud 的 Google Security Operations SIEM 可集中收集、分析、检测和调查您的所有安全数据，从而提供安全信息和事件管理服务。
使用 Google Cloud 构建混合云和多云架构：后续步骤
- 详细了解如何开始迁移到 Google Cloud。
- 了解混合云和多云端的常见架构模式、它们最适合的场景以及如何应用它们。
- 详细了解混合云和多云架构的网络模式以及如何设计它们。
- 探索、分析和比较 Google Cloud 上的不同部署原型。
- 了解 Google Cloud 中的着陆区设计。
- 详细了解 Google Cloud 架构框架
- 了解我们将虚拟机迁移到 Compute Engine 的最佳实践。