Multi Cloud 多云混合云架构
Multi Cloud 多云混合云架构 - 业界参考资料与思考.
混合云架构
A、混合云的多活架构指南
1. 企业选择混合云的技术诉求
稳定性
随着云厂商的技术建设，稳定性越来越高，且同 region 的多可用区方案进一步降低了企业集中式故障的概率。但云厂商仍存在中心式服务，如 region 的网络汇聚、统一的结算系统等。
region级别的可用性，还是比较依赖云厂商的可用性，尤其是一些中心式服务，可能可用性不能达到要求。
对于用户使用时间窗口特别集中的业务，对稳定性的要求更高。比如在线素养课就是在有限时间内老师和学生完成知识传授，如果在这段时间内云服务出现故障，学生的学业受到影响，学生和老师需要重新匹配时间才能完成学习计划。健康码、打车软件这些使用集中在早晚高峰的场景也是同理。对于 SLA 要求更高的业务，选择多云多活是必然的趋势。
实际应用场景，尤其是跟人的现实活动挂钩的，对可用性要求比线上服务要更高。
成本 &服务
但随着互联网红利不断消退，公司希望实现成本效益最大化，引入更多的供应商也是必选的手段之一。新的供应商，可以用来做数据灾备，或者用于峰值时的弹性计算，也或者按照不同业务进行切分。
不希望鸡蛋放到一个篮子里，厂商锁定可能在议价时处于劣势。而如果可以灵活选择供应商，就可以选择折扣比较多的云服务。
2. 多云SLA的挑战
稳定性
多活架构是用来解决稳定性问题的，但若不能做到多云各自完整的闭环，彼此之间还有千丝万缕的调用依赖，故障率反而会增加。
如果每个云都是单独的服务，并且存在互相调用问题。那么故障的几率是乘积的关系，其实是比单云可用性要更低的。
所以每个服务，都部署到多云上，将会极大地提高SLA。但在这种架构的过渡时期，则必须面对以上问题。
除了部署异构导致的故障率加剧外，脑裂加剧也是一大隐患。多家云厂商中数据存储一般采用主从的方式进行同步，master 所在的主云故障后，需要将另一边云的数据存储提主。但是主云并不是完整挂掉，运维人员无法从控制台登陆，无法将 master 降为 slave。但用户南北流量或者定时任务还在持续请求，主云仍有可能还在处理写入流量。这时候从云的切主，就会导致不可避免的脑裂。脑裂无法简单的进行修复，需要业务研发 case by case 的进行修复，代价巨大。
“脑裂"类似的场景很多，比如数据同步，以及在A云故障时，如何将数据放回B云，是值得思考的问题。
效率
如果做不到多云的对等部署，不得不通过持续演练的方式来应对墒增，保证多云架构的有效性。一旦松懈了，很有可能导致花大精力做的架构升级，但在真正的单云故障面前不起任何作用。另外，在两次演练之间的窗口内，架构能否很好的应对单云故障也是存疑的。
虽然多云号称可以解决单云故障问题，但系统是熵增的，必须通过不断的演练来确保这一点。不然可能真的故障的时候，手忙脚乱，导致各种业务问题。
B、如何正确选择多云架构？
1. 多云架构优势
多云架构有如下优势：
* 灾难恢复，当一家云供应商出现故障时，数据存储可以从另一家云供应商进行恢复。虽然云厂商有多地域，单地域也有多可用区，但还是存在中心化的依赖。这种依赖的故障就会导致整个云的故障。后面提到的故障主要指这种类型的故障。
* 故障转移，当一家云供应商出现故障时，使用另一家云供应商承接服务，实现服务平稳不中断。
* 成本优化，任意的采购只要有了两家及以上供应商，采购方就有了充分选择和议价的能力。
* 避免供应商锁定，单一供应商，除了没有议价能力外，各种依赖也会使得变更极为困难。
* 数据主权，企业提供服务，但产生的数据产权也是归属于服务对象。服务对象既有普通的用户（行权由国家主体代为进行），也有机构。他们对产权的需求，连带的导致企业的云基础设施选择也受其限制。
* 特定服务访问，不同云有自己优势的服务，一般出现在 PaaS 层，如各式各样的数据库、大数据实时方案等。使用多云可以集各家之长。
- 便于全球化业务，基于当地优势云，快速部署一套当地的服务集群。
- 业务本地化，边缘节点更接近用户，体验更良好（游戏业务居多？）
2. 5种多云架构模式
Good！回看文章。