此架构指南提供有关使用 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 | 开发者关系工程师
推动因素、注意事项、策略和方法
本文档定义并讨论了业务目标、驱动因素和要求，以及这些因素在构建混合云和多云架构时如何影响您的设计决策。
目标
组织可以采用混合云或多云架构，既可以作为满足特定业务目标的永久性解决方案，也可以作为临时状态来满足某些要求，例如迁移到云端。
回答以下与您的业务相关的问题，有助于您明确业务需求，并针对如何实现部分或全部业务目标制定具体预期。这些问题侧重于您的业务需求，而不是如何从技术上实现这些需求。
- 哪些业务目标促使您决定采用混合云或多云架构？
- 混合云或多云架构将有助于实现哪些业务和技术目标？
- 哪些业务驱动因素影响了这些目标？
- 具体业务要求是什么？
在混合云和多云架构的背景下，企业客户的一项业务目标可能是将在线销售业务或市场从单个区域扩展到全球，成为其细分市场中的全球领导者之一。其中一个业务目标可能是在六个月内开始接受全球（或特定区域）用户的采购订单。
为了支持上述业务需求和目标，一个潜在的主要技术目标是利用公有云的全球功能和服务，将公司的 IT 基础架构和应用架构从仅限本地部署的模式扩展到混合架构。此目标应具体明确且可衡量，并清楚定义目标区域和时间表方面的扩展范围。
一般来说，混合云或多云端架构本身可能并不是一种目标，而是一种满足技术目标的手段，而这些技术目标是由某些业务需求驱动的。因此，选择合适的混合云或多云架构之前要先明确这些需求。
请务必区分 IT 项目的业务目标和技术目标。您的业务目标应侧重于组织的宗旨和使命。您的技术目标应侧重于构建技术基础，使组织能够满足其业务需求和目标。
业务驱动因素会影响业务目标和目的的实现。 因此，明确确定业务驱动因素有助于制定更符合市场需求和趋势的业务目标或目的。
以下流程图说明了业务驱动因素、目标、目的和要求，以及技术目标和要求，并说明了所有这些因素之间的关系：
业务和技术驱动因素
考虑业务驱动因素如何影响技术目标。选择混合架构时，一些常见的、有影响力的业务驱动因素包括：
- 遵从有关数据主权的法律法规。
- 借助云财务管理和成本优化学科（例如 FinOps），减少资本支出 (CAPEX) 或一般 IT 支出。
- 云采用可以由有助于减少资本支出的方案推动，例如在混合云或多云架构中构建灾难恢复解决方案。
- 改善用户体验。
- 提高灵活性和敏捷性，以应对不断变化的市场需求。
- 提高成本和资源使用的透明度。
请一并考虑采用混合云或多云架构的业务驱动因素列表。不要孤立地看待这些指标。您的最终决定应取决于业务优先事项的平衡。
在组织意识到云的优势后，如果没有任何限制（例如成本或需要将高度安全的数据托管在本地的特定合规性要求），组织可能会决定完全迁移。
虽然采用单一云提供商可以带来多项好处，例如降低复杂性、实现服务之间的内置集成，以及提供承诺使用折扣等成本优化选项，但在某些情况下，多云架构仍可为企业带来益处。以下是采用多云架构的常见业务驱动因素，以及与每个驱动因素相关的注意事项：
- 遵从有关数据主权的法律法规：最常见的情形是，组织将其业务扩展到新的区域或国家/地区，并且必须遵守新的数据托管法规。
- 如果现有使用的云服务提供商 (CSP) 在相应国家/地区没有本地云区域，那么出于合规性考虑，常见的解决方案是使用在相应国家/地区有本地云区域的另一家 CSP。
- 降低成本：降低成本通常是采用某项技术或架构的最常见业务驱动因素。不过，在决定是否采用多云架构时，除了服务费用和潜在的价格折扣之外，还应考虑其他因素。考虑在多个云端构建和运营解决方案的成本，以及现有系统可能引发的任何架构限制。
有时，与多云策略相关的潜在挑战可能会超过其带来的好处。多云策略日后可能会产生额外费用。
- 管理复杂性增加。
- 保持一致的安全性。
- 集成软件环境。
- 实现一致的跨云性能和可靠性。
- 组建一支具备多云技能的技术团队可能成本高昂，并且可能需要扩充团队，除非由第三方公司管理。
- 管理各个 CSP 的产品定价和管理工具。
- 如果没有能够提供统一的费用可见性和信息中心的解决方案，就很难高效地管理多个环境中的费用。在这种情况下，您可以酌情使用 Looker 云费用管理解决方案。如需了解详情，请参阅有效优化云结算成本管理的策略。
- 利用每个 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，不规划就是规划失败。
混搭迁移方法
本文讨论的每种迁移方法都有各自的优点和缺点。因此要实施混合云和多云端策略，您无需只采用一种方法。相反，您可以决定最适合每个工作负载或应用堆栈的方法，如下面的图表所示。
此概念图展示了可同时应用于不同工作负载的各种迁移和现代化路径或方法，这些路径或方法由每个工作负载或应用的独特业务、技术要求和目标驱动。
此外，同一应用堆栈组件不必采用相同的迁移方法或策略。例如：
- 应用的后端本地数据库可以从自托管 MySQL 重新平台化为使用 Google Cloud中的 Cloud SQL 进行管理的数据库。
- 应用前端虚拟机可以重构为使用 GKE Autopilot 在容器上运行，其中 Google 管理集群配置，包括节点、伸缩、安全性和其他预配置设置。
- 本地硬件负载均衡解决方案和 Web 应用防火墙 WAF 功能可替换为 Cloud Load Balancing 和 Google Cloud Armor。
如果工作负载中出现以下任何一种情况，请选择重新托管（直接迁移）：
- 它们对环境的依赖项相对较少。
- 它们被认为不值得重构，或者在迁移之前重构不可行。
- 它们基于第三方软件。
对于具有以下特点的工作负载，请考虑重构（迁移和改进）：
- 它们具有必须解开的依赖项。
- 它们依赖于无法迁移到云端的操作系统、硬件或数据库系统。
- 它们无法有效利用计算或存储资源。
- 它们无法在不费一番功夫的情况下以自动化方式部署。
如果工作负载中出现以下情况，请考虑重建（移除和替换）：
- 它们不再满足当前的需求。
- 它们可以与其他提供类似功能的应用程序集成，而不会影响业务需求。
- 它们基于已达到使用寿命的第三方技术。
- 它们需要支付多余的第三方许可费。
快速迁移计划展示了 Google Cloud 如何帮助客户运用最佳实践、降低风险、控制费用并简化云迁移之路。
其他注意事项
本文档重点介绍了在塑造整体混合云和多云端架构方面发挥关键作用的核心设计注意事项。全面分析和评估整个解决方案架构（包括所有工作负载，而不仅仅是特定工作负载）中的这些注意事项。
重构
在重构迁移中，您可以修改工作负载以利用云功能，而不仅仅是让它们在新环境中工作。您可以针对性能、功能、费用和用户体验来改进每个工作负载。如重构：迁移并改进中所述，在某些重构方案中，您可以在将工作负载迁移到云端之前对其进行修改。这种重构方法具有以下优势，尤其是在您的目标是构建混合架构作为长期目标架构的情况下：
- 您可以改进部署过程。
- 投资持续集成/持续部署 (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 转换将 Deployment Manager 配置和模板转换为 Google Cloud 支持的其他声明性配置格式（例如 Terraform 和 Kubernetes 资源模型），以便在发布时可移植。
您还可以考虑自动创建项目以及在这些项目中创建资源。这种自动化可帮助您采用基础架构即代码方法进行项目预配。
容器和 Kubernetes
使用云管理功能有助于降低构建和维护自定义工具链的复杂性，从而实现工作负载自动化和可移植性。不过，仅使用虚拟机作为通用基础很难实现真正的云优先应用。一种解决方案是改用容器和 Kubernetes。
当您将软件从一个环境移动到另一个环境时，容器可帮助您的软件可靠地运行。由于容器将应用与底层主机基础架构分离，因此有助于在混合云和多云等计算环境中进行部署。
Kubernetes 负责处理容器化应用的编排、部署、伸缩和管理。它是开源的，由 Cloud Native Computing Foundation 管理。使用 Kubernetes 可提供构成云优先应用的基础的服务。因为您可以在许多计算环境中安装和运行 Kubernetes，所以您还可以使用它在跨计算环境中建立通用运行时层：
- Kubernetes 在云或私有计算环境中提供相同的服务和 API。此外，使用 Kubernetes 的抽象级别远高于使用虚拟机时的抽象级别，这通常会转化为较少的基础工作并提高开发者的工作效率。
- 与自定义工具链不同，Kubernetes 被广泛用于开发和应用管理，因此您可以利用现有的专业知识、文档和第三方支持。
- Kubernetes 支持以下所有容器实现：
- 支持 Kubernetes 容器运行时环境接口 (CRI)
- 已在行业中广泛应用
- 不依赖于任何特定供应商
当工作负载在 Google Cloud上运行时，您可以使用 Google Kubernetes Engine (GKE) 等托管式 Kubernetes 平台来避免安装和运行 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提供的各种数据迁移选项为企业提供了一套全面的解决方案，可帮助企业迁移、集成和转换数据。这些选项可帮助企业在不同环境中存储、共享和访问数据，以满足其特定使用场景的需求。这种能力最终将使业务和技术决策者能够更轻松地采用混合云和多云架构。
数据迁移是混合云和多云策略以及架构规划方面的一项重要考虑因素。您的团队需要确定不同的业务应用场景以及支持这些应用场景的数据。您还应考虑存储类型、容量、可访问性和迁移选项。
如果企业针对受监管的行业制定了数据分类，则该分类有助于确定某些数据类别的存储位置和跨区域数据移动限制。如需了解详情，请参阅 Sensitive Data Protection。 Sensitive Data Protection 是一项全代管式服务，旨在帮助您发现、分类和保护数据资产。
如需了解从规划数据转移到使用最佳实践的完整流程，请参阅迁移到 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 Security Operations SIEM（由 Google Cloud 提供）可在一个位置收集、分析、检测和调查您的所有安全数据，从而提供安全信息和事件管理。
使用 Google Cloud构建混合云和多云架构：后续步骤
- 详细了解如何开始迁移到 Google Cloud。
- 了解混合云和多云端的常见架构模式、它们最适合的场景以及如何应用它们。
- 详细了解混合云和多云架构的网络模式以及如何设计这些模式。
- 在 Google Cloud上探索、分析和比较不同的部署原型。
- 了解 Google Cloud中的着陆区设计。
- 详细了解 Google Cloud Well-Architected Framework
- 了解我们将虚拟机迁移到 Compute Engine 的最佳实践。