异地双活的四个误区

郑昀（老兵笔记） 20190305

阿里云华北二机房2019年3月3日凌晨服务中断长达三小时，我在微博上喊出了：工程师赶忙起床，切多活流量啊。

那么切多活有什么常见误区呢？

A，灾备（主备）仍是双活？
多年前，你们每每作成了灾备机房，一主一备。结果是，真正灾难发生的时候，最高领导人下不了决心切机房，由于没法预料切换后果（灾难老是不期而遇，切过去就可能切不回来了）。
因此必定是多个数据中心同时运行着一样的应用，拥有一样的数据，任何一个客户的交易能够在分钟级所有路由到另外一个中心并对外提供服务，不至于说灾难来临时才发现集群没法工做。

B，双活测试模拟正常流量切换就够了吗？
不是模拟在正常状况下的多活切换，那怎么测怎么有。
而是模拟灾难发生（忽然发生）的时候，另一个机房物理消失了，你该如何切换。
咱们过去犯的两个错误是：
-用代码逻辑限制双活机房之间的数据库同步不能延时超过N分钟，超过了就阻止切换；
-限制双活机房的 otter 服务访问超时时间不得超过N分钟，超过了就阻止切换。
问题就在于，真正灾难发生的时候，机房已物理不可访问了，这时候就是要马上地、所有地切换流量，人下达的命令就是最终裁决。拼着损失一分钟的交易和脏数据，也要把交易切到另外一个机房。

C，全部业务都双活吗？
基于互联网公司经常使用的基本可用性保障原则，只是保障核心业务双活。
怎么定义核心业务？即不能容忍中断的服务。
用户注册，商户进件，这些都属于能容忍临时性中断的服务。
非核心业务应用都被标记为非多活业务，非多活数据库与多活数据库要严格区分开来。

D，切机房的时候直接切吗？
双活意味着两个机房都不须要维护一个能承载全部流量的集群，不然太费钱。
因此模拟切机房流量的时候，必定要测试与核心业务有关的全部应用自动扩容，扩容以后再切换流量。测试扩容的效率，分钟级扩容完毕。
因此你的应用最好都是部署在Docker容器集群上的，这样才能作到扩容分钟级。
并且你们通常是混合云部署，因此在不一样的云平台上，你的应用部署底层基础最好都如出一辙，方便你扩容和切换。

-EOF-
欢迎订阅老兵笔记：