这些常见的云爆发挑战，其实并不用愁

云爆发是处理流量高峰的一个好方法，但它很复杂。不过，它并非不可能实现。不妨将这些策略整合到你的IT计划中，以启动和运行混合云。          

云爆发从来没有像某些人预期的那样发展起来，但是许多组织仍然渴望使用这种混合云结构。对于那些不怕潜在挑战的人来说，有几个关键的因素发挥了作用。             

大多数企业使用公有和私有云基础设施来托管其应用程序。一项调查发现，85%的IT领导者认为混合云是理想的运维环境，一半的人认为它满足了他们的所有需求。             

然而，“混合云”一词包含了各种各样的场景，从简单、被动的灾难恢复（DR）环境到复杂、冗余的主动-主动应用程序。后者——同时具有活动和负载均衡的公有和私有云环境——曾经被认为是理想的云运维模式，因为它使系统架构师能够充分利用两者的优点并将其缺点最小化。             

云爆发挑战             

 “云爆发”很好地结合了这两者的优点。在这个模型中，私有云基础设施处理基线资源需求，托管敏感的遗留数据库和后端系统；公有云基础设施处理季节性负载高峰、临时爆发和扩展web前端系统。             

云爆发的宏伟愿景甚至延伸到成本优化。在一个被称为“多云套利”的概念中，企业使用多个IaaS提供商以及实时成本分析软件，并在特定时间针对特定工作负载将突发事件导向最便宜的供应商。             

不幸的是，一个优雅的理论却变成了多云基础设施和应用程序设计的混乱现实。因此，很少有公司能够部署云爆发架构，即使很多公司希望这样做。事实上，怀疑论者认为，云爆发在很大程度上是一个神话。咨询公司Architecting  IT最近指出了四个阻碍采用的重大挑战：             

——网络，即在公有云和私有云之间建立低延迟、高带宽、冗余的连接，并自动将传入的连接路由到最佳位置。             

——安全性，因为它涉及跨多个环境的用户和系统的一致策略和控制。             

——数据一致性，或同步多个站点上的数据存储的问题，特别是在事务负载多的时期。             

——数据保护，当备份从多个源馈送时保持一致的相关问题。             

笔者认为还有第五个挑战：自动部署和动态扩展资源。这与公有云（主要是计算或容器实例，但也包括存储I/O）处理暂时的、突发的需求的能力有关。          

这些都是可以解决但很复杂的问题，也使得许多组织得出结论，云爆发不值得麻烦，至少在他们有新一代的分布式应用程序模型设计用于跨多个云之前是这样。对于那些没有被吓倒的人，下面说的是如何应对每一个云爆发的挑战。             

网络和安全 

网络和安全是最基本的云爆发挑战，因为它们必须在任何混合环境下解决，无论是否使用云爆发。幸运的是，在这个方面，IT团队可以找到最广泛的技术和服务，包括来自主要云提供商、电信公司、ISP和托管运营商的技术和服务。有几种安全的方法可以将私有云和公有云连接起来，以改进混合云连接：        

——使用标准VPN协议（通常是IPsec）和虚拟路由器将本地网络链接到公有云中的一个或多个私有子网的虚拟私有云。企业可以通过VPN将其企业网络扩展到云子网中，并通过合并虚拟服务（如路由器、NAT网关和internet网关）来保持对流量的完全控制。             

——使用云提供商服务（如AWS Direct Connect、Azure ExpressRoute或来自Google、Oracle和IBM的产品）的专用电路。这些产品在客户的私有云和公有云网络之间提供了一个专用的、低延迟的链接。由于端点位置的限制，服务通常在托管中心终止——在托管中心，服务可以连接到客户的专用机架，而不是企业数据中心。

——通过电信公司、ISP或托管提供商提供的服务的专用电路。这些服务与云提供商提供的服务类似，但它们利用与主要运营商的广泛互连，提供更多的终端位置。AT&T NetBond或Equinix Cloud Exchange等服务也简化了多云互连的设计，因为它们与所有主要的IaaS和SaaS提供商媲美。             

这两种类型的专用电路服务使企业能够完全控制网络路由、流量管理和安全策略。然而，像Direct Connect这样的云提供商服务是克服云爆发挑战的最佳选择。这些服务依赖于终止于云提供商数据中心的光纤电路，因此它们提供最高的性能和最低的延迟。             

数据一致性和保护

与云灾难恢复的实现类似，云爆发需要将应用程序组件从本地复制到公有云IaaS。一个组织必须手动构建必要的基础设施资源和网络拓扑，除非它已经完全实现了云不可知的基础设施即代码系统，如Terraform、Chef、Ansible或其他允许以编程方式实例化资源和配置的系统。然而，一旦到位，云提供商的原生工具，如AWS CloudFormation或Google cloud Deployment Manager，就可以在其他云区域自动扩展或复制资源。             

然后，根据你的应用程序架构，可以通过以下几种方式解决数据同步问题：             

——将数据库留在内部，并通过上述专用电路确保可靠的高速混合云连接。此策略适用于对延迟不敏感且不会连续访问数据库的应用程序，因为前端和业务逻辑应用程序层是负载增加时的主要瓶颈。             

——跨位置复制数据库，特别是对于事务性数据库负载很重的应用程序。复制固有地会引发数据一致性问题，但这些问题已经由支持多站点复制的数据库系统（如Oracle和Microsoft SQL Server）解决。需要实时一致性的应用程序必须使用更复杂的方法，如Oracle RAC、GoldenGate或各种第三方或开源产品，如Qlik Replicate或SymmetricDS。             

动态资源分配              

一旦网络管道和应用程序基础设施就位，云爆发的运维部分就需要在内部环境和云环境之间动态地指引导和均衡工作负载。      

主要工具是负载均衡器、应用程序交付控制器和虚拟网络接口。现代的负载均衡器有足够的配置选项来指定负载权重因子、资源/CPU限制和回退规定，以适应任何突发情况。云负载均衡服务，如AWS Elastic Load Balancing、Google Cloud Load Balancer 或Azure Load Balancing,会自动扩展容量以处理增加的流量。             

云爆发的另一个挑战是动态容量管理。由于Kubernetes可以自动扩展集群和pod（主机上的容器组），因此容器化应用程序在这方面具有固有的优势。所有主要的云Kubernetes服务都包括集群自动缩放。             

虽然主要的云平台确实支持通过EC2自动伸缩和Azure伸缩集等服务自动伸缩实例组，但对于VM托管的应用程序，容量管理更为棘手。这些工具响应来自其相应监控服务的策略，如虚拟CPU利用率、网络流量或其他指标。