多云部署就是云高可用方案了吗？

对于大多数来说，云计算是把双刃剑。一方面，我们受益云计算带来的好处，因其可以随时随地访问服务和数据，被广大用户高度认可。但是，另一方面，云计算也隐藏着巨大风险，一旦服务宕机，企业将承受无法预估的损失。

为了将损失降到最小，企业将一部分业务部署到公有云。另外，还要将关键业务的底层基础设施，以两地双活，或者多地多中心的形式，做异地灾备。这种部署模式，极大地确保了企业数据和服务的持久性、安全性和可用性，避免因为服务中断给企业带来损失。为了进一步防止企业业务宕机，许多公司甚至将他们的服务分散到多个供应商。

但是，这样就足够了吗？多云部署真的就是高可用方案了吗？

2017年2月，美国顶级云服务供应商亚马逊AWS旗下的Simple Storage Service （简单存储服务），简称S3，因为一名工程师手滑而掉线了5个小时。此次宕机事件，导致北美东部地区的服务中断，许多依赖S3的客户的网站和服务受到影响。

总的来看，受S3中断影响的工作负载分为两类:一类是那些被认为“不是关键任务”的工作负载，即那些缺乏足够的体系架构，用来做探索性业务的工作负载。另一类是，缺乏足够健壮的体系架构，但是已经有关键业务在上面做尝试性应用，这类公司感受到了最强烈的冲击。在这种情况下，如果你在另一个云服务商的云上有副本，可减轻S3服务中断产生的影响。但是，跨云复制也会增加更多的复杂性，如果采用专有的跨区复制解决方案，会是另外一种体验，可大大减少企业云运维成本。

从应用部署角度看，如果你想让不同云提供商之间实现相同功能的高可用性，就必须抽象出特定的功能。这意味着用户的云端整合能力，仅限于多个平台的共有属性。即使是差异服务能抽离，但是在单个级别的服务上，抽离出不同提供商实现的差异性，也会产生大量的额外工作。

另外，从容器级别的程序实现看，由于不同提供商拥有不同的IaaS，用户需要在多个平台上运行相同的容器协调器，并限制底层功能的使用(或通过公共接口访问底层功能)。虽然在不同的云服务中使用容器运行相同的程序，在理论上是可行的；但是，实现条件是，这种想法根本不切合实际，容易人为产生错误，并且更容易宕机。数据复制方式和IaaS产品本身的差异性，会极大地增加机器宕机的可能。

再者，从数据安全性和服务遵从性的角度来看，管理多云环境存在着巨大挑战。我们需要做很多工作，包括提供虚拟网络、防火墙规则、监视规则、日志记录以及身份验证和访问权限管理等，整个过程既困难又耗时。并且，不同云服务更新迭代的速度特别快，我们需要用额外的工具、体系，以及过程管理、培训服务等，确保跨平台的一致性和服务的遵从性。

所以，选择不同的云，不一定就已经是高可用方案了。我们还要添加新的工具或者过程管理方案，用来解决实际业务问题。比如：多云解决方案，可能会拥有更多更具体的最佳实践经验。