异地双活的四个误区

郑昀（老兵笔记） 20190305

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

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

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

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

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

D，切机房的时候直接切吗？
双活意味着两个机房都不需要维护一个能承载所有流量的集群，否则太费钱。
所以模拟切机房流量的时候，一定要测试与核心业务有关的所有应用自动扩容，扩容之后再切换流量。测试扩容的效率，分钟级扩容完毕。
所以你的应用最好都是部署在Docker容器集群上的，这样才能做到扩容分钟级。
而且大家一般是混合云部署，所以在不同的云平台上，你的应用部署底层基础最好都一模一样，方便你扩容和切换。

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