14 | 不够坚定：异地多活没有一步到位的遗憾

作者回复: 类似软件架构，任何组织架构都有局限性。虚实结合适用饿了么却未必适用美团，更何况，按成王败寇视角，胜利者经验更易被称颂。

作者回复: 如果按场景分，异地多活从难到易，依次是：实时交易 -> 非实时交易 -> 社交类 -> 内容类 -> 其他。游戏类不好说，需要具体情况具体分析。

作者回复: 几方面原因： 1、做两次耗费的人财物 + 时间，包括中间为多活 + 非多活并行预留的 buffer、两次切换带来的风险等； 2、即使只考虑机器硬件成本，也有 ROI 问题，因为从灾备上线到下线这段时间，灾备发挥作用很小（几乎可以认为只是 data backup），真出现紧急情况，切或不切的风险孰大孰小，真不好说； 3、即使只考虑机器硬件成本，多活的规模自由、伸缩自由就能体现出来。举个例子：2单元多活的硬件成本确实和灾备差不多（100%冗余），但3单元、4单元呢？虽然多活单元规模也不是越多越省钱（非简单线性下降，和多活设计相关，细节不展开了），但至少留出了规模自由、伸缩自由空间。

作者回复: 1、是的，一般指物理上聚集在一起的单体数据中心；2、针对外卖场景（打车类似，但简单很多），一般指将地图上大的区域（如：北京五环、上海外环等）划分为适合业务发展或满足用户需要的一个个不规则小区域。同时，针对B、C、D（配送）、BD（销售）等不同角色，区域划分规则也不尽相同（也就是一般说的「多张网」）。例如：B1区域商户服务C1（部分）+C2（部分）用户，同时，D1区域骑手服务B1（部分）+B2（部分）商户，又同时，BD1区域销售服务B3（部分）+B4（部分）商户。

作者回复: 很简单，物流和其他系统都基于统一基础设施（中间件、运维、工具、相关团队等），在基础设施进行多活改造后，除了切换并行期不得不同时支持多活、非多活及混合架构，后续所有统一基础设施（包括相关团队）将只支持多活架构。