如何设计混合云架构

在不久的过去，混合云方法通常涉及将部分服务从本地基础设施迁移到公有云或私有云，同时这些服务彼此通信。即便新应用程序是为公有云托管而构建的，它仍遵循传统的面向服务的架构 (SOA)。

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

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

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

容器化的出现帮助真正发挥了混合云的优势，重点转向工作负载的易于迁移以及在所选云环境中自动部署服务。

几年前，关于混合云架构的讨论中，关键问题主要集中在每个工作负载应该运行在哪个云或本地环境，以及如何让这些不同环境相互通信。从根本上说，托管位置和物理连接性仍然是主要的考虑因素。

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

这些因素仍然很重要，但在容器化范式下，关注点已从物理位置和连接性转向在不同环境之间灵活地无缝迁移工作负载。因此，是否将应用程序托管在私有云还是公有云中，不必成为一个僵硬的决定。如果策略行不通，打包为容器的工作负载可以轻松在不同环境间迁移，进行弹性伸缩，甚至在不同环境中运行同一服务的多个实例。

这一切促成了一个现代化、高度可用且灵活的架构，提供高性能、资源效率和成本节约。

混合云架构的设计与实施需要考虑多个因素，包括企业的业务目标、当前的技术环境、数字化转型目标以及安全性考量。由于涉及多种混合云解决方案的架构可能很快变得复杂，因此利用运维工具实现集中、无缝且可扩展的云管理非常重要。在制定混合云策略时，需要考虑以下因素。

现代化战略

对于大多数组织而言，混合云计算的概念始于现代化，即将其应用程序从本地部署迁移到云，并且实现这一目标的方法有多种：

• 整体迁移：这是启动现代化最常见的方法之一，整体迁移是将完整应用从本地环境迁移到云环境。这涉及到改变底层硬件，以利用安全、可扩展的云计算资源和基础设施服务。当没有足够的时间进行重构或重新架构时，这是一个方便的选择。
• 重构：与其将整个单体应用程序迁移到云端，这不仅耗时，而且在某些情况下也不必要，更好的做法是识别一两个服务（例如，不涉及合规性或急需性能改进的服务），对其进行重构（例如，通过添加粘合代码来暴露 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 端点。来自数据中心外部的 Web 服务或移动应用程序的任何调用都必须通过 API 网关进行验证和路由。

在云计算环境中，还存在一层额外的安全机制：通过服务网格和编排平台所暴露的 API 定义的控制策略。这些策略确保只有安全的调用会被转发到 Kubernetes 节点，并进一步传递给微服务。

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

网络连接

在单个云区域内，可用区通过专用光纤网络连接网络中的所有节点，使企业能够构建高可用架构，带宽几乎不受限制且网络延迟低。然而，不同区域及多云提供商之间的通信需要通过公共互联网进行，因此会带来更高的延迟和潜在的故障风险。

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

• 通过公共 IP 地址经互联网传输（由于带宽共享，延迟较高）
• 通过托管服务如 VPN（延迟更可预测，安全性更高）
• 通过公共接入点 (POP) 的专用互连（CSP 提供的昂贵方案，但延迟最低且安全性最高）

由于这些选项在传输速度、延迟、可靠性、SLA、复杂性和定价方面各不相同，因此，在设计网络连接层之前，必须权衡限制因素和优点。

开发平台对开源技术的偏好

混合云意味着既能跨环境迁移工作负载，又能在任意云平台运行应用开发环境。要实现真正的云原生，就必须避免对任何特定技术、平台乃至云服务商的强依赖，使企业能够敏捷应对市场变化。

开源架构使这种统一的开发方式成为可能，开发人员能够管理其底层基础设施，而不受其实现所使用技术的限制。开源已不再是边缘化、仅供少数追求成本效益的用户使用的技术；它已成为主流，并因其丰富的功能、高质量以及基于社区的开发模式而占据了核心地位。

据 Red Hat Report on The State of Enterprise Open Source（ibm.com 外部链接）报道，即使在像安全这样敏感的领域，开源软件现在也被视为一个很好的选择。企业对开源表现出明显偏好，主要原因是安全性、质量以及对云原生架构的支持。

更多信息请参阅 JJ Asghar 的文章“Cultivating Careers, Communities and Companies with Open Source”。

IBM Cloud 混合云解决方案为应用程序和数据提供灵活性和可移植性。Linux、Kubernetes 和容器支持混合云堆栈，并与 Red Hat OpenShift 结合创建一个连接本地和云资源的通用平台。

深入了解基于 IBM Cloud 构建的混合云解决方案。

要开始构建自己的混合云解决方案，请注册 IBMid 并创建 IBM Cloud 帐户。