如何设计混合云架构？

混合云架构将跨地理分布的公共云、私有云和本地基础设施的多个环境汇集在一起​​，作为一个单一的托管 IT 基础设施。在基本层面上，这可能只是一家企业在其本地数据中心托管遗留应用程序——在公共云服务上调用一些API 。然而，这种初步实施并不是混合云基础架构的最佳旗舰用例。

最大潜力的混合云包括利用云实现基础设施即服务 (IaaS)、平台即服务 (PaaS) 和软件即服务 (SaaS) 功能，能够托管在本地、私有云和公共云以及边缘环境的组合上运行应用程序，并具有无锁定多云方法的灵活性。了解设计模式和要考虑的关键因素有助于提炼设计此类混合云架构所涉及的复杂性。

现代混合云架构的基本要素

最近，混合云方法通常涉及将一些服务从本地基础设施迁移到公共或私有云，并且这些服务相互通信。即使构建了一个新的应用程序以托管在公共云上，它也会遵循传统的面向服务的架构 (SOA)。

但是，今天，基于微服务的架构是混合云模型的核心。微服务是一种将应用程序分解为更小的组件或服务以便于部署的方法。这些微服务与 SOA 中的服务不同，因为它们有自己的技术堆栈并部署在容器中，容器是包含微服务及其依赖库的轻量级可执行文件。

容器是轻量级的，因为它们共享机器的操作系统 (OS) 内核，这意味着每个容器只包含微服务及其依赖项。任何操作系统依赖项都从容器所在的硬件共享。这种虚拟化允许微服务在任何本地或云环境中独立部署。而自给自足性使得微服务与 SOA 有很大不同，更适合云部署，其中对弹性和灵活性的需求以优化云资源是至关重要的。

容器化作为在任何环境中隔离进程的打包模型并不是一个新概念，但2013 年作为容器引擎出现的Docker创建了一个通用的打包结构。此外，像Kubernetes这样的容器编排平台可以跨混合云环境自动部署 Docker 或任何其他符合开放容器倡议 (OCI) 标准的容器。

容器化范式对混合云的影响

容器化的出现有助于真正利用混合云的优势，重点转移到工作负载的轻松移植和服务在您选择的云环境上的自动部署。几年前，关于混合云架构的讨论中的关键问题集中在每个工作负载应该在哪个云或本地环境中运行，以及如何让这些不同的环境相互通信。从本质上讲，托管位置和物理连接仍然是主要考虑因素。

例如，处理敏感数据的应用程序将托管在私有云上。或者，难以实现现代化的遗留应用程序将继续存在于本地。同时，组织会将需要可扩展性的应用程序提升并转移到公共云环境。然后，他们将建立虚拟专用网络 (VPN) 隧道或消息流等通道，以促进环境之间的通信。

这些仍然是需要考虑的重要因素，但是对于容器化范例，重点已经从物理位置和连接性转移到将工作负载从一个环境无缝移动到另一个环境的灵活性。因此，无论是在私有云还是公共云中托管应用程序都不一定是一个严格的决定。如果该策略不起作用，则可以轻松地跨环境移动打包为容器的工作负载、扩大和缩小规模，甚至在不同环境中运行相同服务的实例。所有这一切促成了现代、高度可用且灵活的架构，该架构可提供高性能、资源效率和成本节约。

设计混合云架构时的主要考虑因素

混合云架构的设计和实施需要考虑很多因素，包括企业的业务目标、当前的技术格局、数字化转型目标和安全考虑。由于这种具有多个混合云解决方案的架构可能会很快变得复杂，因此利用 ops 工具进行集中、无缝和可扩展的云管理非常重要。以下是创建混合云战略时需要考虑的一些因素。

现代化战略

对于大多数组织而言，混合云计算的想法始于现代化或将其应用程序从本地迁移到云端，有几种方法可以执行此操作：

• 直接迁移：启动现代化的最常见方法之一，直接迁移是将整个应用程序从本地迁移到云环境。这涉及更改底层硬件以利用安全且可扩展的云计算资源和基础设施服务。当没有足够的时间进行重构或重新架构时，这是一个方便的选择。
• 重构：与其将完整的单体应用程序迁移到云端——这不仅耗时而且可能是不必要的——最好确定一两个服务（没有合规性或紧急性能改进需求的东西），重构它们（例如，添加胶水代码以公开 REST API，因为以前的服务接口可以与特定平台紧密耦合）并部署在云端。这种分阶段的移动提供了将少量流量路由到云上的新实例的机会，以获得测试和学习的机会，并最终将服务的所有实例移动到云中。
• 重构：最后，还有一种最复杂的方法，将所有系统组件分解为单一职责的微服务，这些微服务是模块化的，并且具有独立的生产路径和容器化。这涉及完全重写并且是一个昂贵的过程，但它也使回报最大化。

统一控制平面

企业运营团队通过统一的控制平面管理他们的云环境，该控制平面提供跨环境的内聚和一致的云运营体验。它支持核心集群管理功能，如工作负载调度和编排、持续集成和部署 (CI/CD) 管道、日志记录、遥测和联合安全。目标是从应用程序团队中抽象出各个云服务提供商 (CSP) 和运行时的底层复杂性，并为运营团队提供一个通用接口来管理企业中的工作负载。

以下是统一控制平面的一些优势：

• 利用跨虚拟机、容器或无服务器部署的动态工作负载放置策略。
• 尽享轻松加入更多提供商或边缘位置的能力。
• 构建功能即服务 (FaaS)等 PaaS 功能，这些功能具有高可用性并可跨不同的云实施工作。
• 集中合规管理。

API 网关和服务网格

集中式API 网关和服务网格等架构模式支持对路由、服务到服务通信、安全性、速率限制和可观察性等云功能进行透明管理。

API网关 作为跨地域的统一前门，负责处理“南北”流量功能，包括：

• 用户认证与授权
• 节流和速率限制
• 交通管理
• API生命周期管理
• 云安全防护栏
• 边缘分析

另一方面，服务网格处理服务依赖项之间的“东西向”流量：

• 集群中的安全服务到服务通信
• 具有负载平衡、路由规则、重试、故障转移、灾难恢复和故障注入的流量管理
• 集群内所有流量的指标、日志和跟踪遥测，包括集群出口和入口
• 分布式可追溯性以检测跨服务边界的请求流
• 自动发现服务

例如， Istio是一个开源服务网格层，它根据云管理员提供的预定义配置来指导服务之间的通信。它充当 Kubernetes 编排层的边车，并与容器一起工作，对程序员和管理员来说是不可见的。

安全

混合云架构的复杂性需要在不同层采用多层方法来确保端到端的安全和保护。 IBM Cloud、Amazon Web Services (AWS)、Microsoft Azure 和 Google Cloud 等 CSP 有责任根据服务水平协议 (SLA) 对外围层的任何调用进行身份验证和授权，从而在企业应用程序周围构建防火墙。这包括拒绝服务保护和遵守隐私法规，如通用数据保护条例 (GDPR) 和健康保险流通与责任法案 (HIPAA)。

在本地基础架构中，可以使用 API 网关实现边界安全，API 网关保护所有 API 端点。来自驻留在数据中心之外的 Web 服务或移动应用程序的任何调用都必须通过 API 网关进行验证和路由。

云计算环境包含一个额外的安全层，其形式是在服务网格和编排平台公开的 API 中定义的控制策略。这些策略确保只有安全调用才能转发到 Kubernetes 节点，然后再转发到微服务。

此外，微分段的概念——将环境划分为不同的逻辑安全段以定义每个服务和工作负载的访问控制策略——可用于在环境中运行的服务之间构建和划分安全级别。最后，加密策略作为额外的数据保护层。

网络连接

在单个云区域中，可用性区域具有连接网络中所有节点的专用光纤网络，允许企业创建带宽不受限制且网络延迟低的高可用性架构。然而，跨区域和多个云提供商的通信是通过公共互联网路由的，并且以更高的延迟和潜在的故障为代价。

在混合云架构中，底层提供者之间存在三种数据交换模式：

• 互联网上的公共 IP 地址（由于共享带宽导致高延迟）
• VPN 等托管服务（更可预测的延迟和更高的安全性）
• 通过公共存在点 (POP) 的专用互连（CSP 提供的昂贵选项，但延迟最小，安全性最高）

由于这些选项在传输速度、延迟、可靠性、SLA、复杂性和定价方面有所不同，因此在设计网络连接层之前权衡限制和收益非常重要。

开发平台对开源的偏见

混合云意味着能够将工作负载从一个环境转移到另一个环境，并拥有在任何云上运行的应用程序开发平台。真正的云原生，不应该紧紧依赖任何特定的技术、平台甚至CSP，企业应该对市场变化保持敏捷。

开源架构支持这种统一的开发方法，开发人员可以管理其底层基础架构，而不管用于其实现的技术如何。开源不再处于边缘地位，不再有使用它来获得成本效益的利基、排他性受众；由于其丰富的功能、质量和基于社区的开发，它现在已成为主流并占据了中心位置。

正如Red Hat Report on The State of Enterprise Open Source所报告的那样，即使在安全性等敏感领域，开源软件现在也被视为一个不错的选择。安全性、质量和对云原生架构的支持是企业对开源表现出有意识的偏见的主要原因。