异地多活的五大挑战

根据微博的实践，做异地多活普遍会遇到五类问题。机房之间的延时：微博北京两个核心机房间延时约1ms，但北京到广州机房有近40ms延时，对比微博核心Feed接口总平均耗时约120ms，而Feed依赖几十个服务上百个资源，如果都跨机房请求，性能会完全不可接受——这说明延时挑战的实质不是”延时数字大不大”，而是”这点延时相对于业务本身的总耗时预算占比有多高”。专线问题：为了连通广州机房，微博租了两条北京到广州的专线，成本巨大，且单条专线稳定性很难保障，基本每个月都会出或大或小的问题。数据同步问题：MySQL怎么做数据同步、HBase怎么做数据同步、还有各种自研组件都要统统做多机房同步，几十毫秒延时加上专线本身较弱的网络质量，让数据同步成为最棘手的一环。依赖服务部署问题：核心服务往往依赖大量小服务，把所有小服务都做异地多活部署，改造和维护成本过大；但如果不部署，又会撞上前面提到的机房间延时问题——这是一个”全改造成本太高、不改造性能不达标”的两难。配套体系问题：光是把服务部署到第二机房、没有真正引入流量，根本不算”双活”；而要引入流量，就要求预览、发布、测试、监控、降级等整套配套流程都能支持异地部署，覆盖开发测试运维全流程，这些工作技术上不算复杂，但操作层面极容易疏漏出问题——微博刚开始做异地多活部署时，就因为测试人员没有在上线时对广州机房做预览测试，造成过线上问题。这五类挑战共同说明，异地多活远不只是”多建一个机房、把数据同步过去”这么简单，它同时是一次跨越网络架构、存储架构、服务依赖治理、研发运维流程的系统性改造。