背景：为什么要做异地多活？

饿了么要做多活，是受业务发展的驱动，经过几年的高速发展，我们的业务已经扩大到单个数据中心撑 不住了，主要机房已经不能再加机器，业务却不断的要求加扩容，所以我们需要一个方案能够把服务器 部署到多个机房。

另外一个更重要的原因是，整个机房级别的故障时有发生，每次都会带来严重的后果，我们需要在发生 故障时，能够把一个机房的业务全部迁移到别的机房，保证服务可用。 异地多活面临的主要挑战是网络延迟，以北京到上海 1468 公里，即使是光速传输，一个来回也需要接 近10ms，我们在实际测试的过程中，发现上海到北京的网络延迟，一般是 30 ms。

这 30 ms可以和运算系统中其他的延迟时间做个比较：

L1 cache reference ......................... 0.5 ns
Branch mispredict ............................ 5 ns
L2 cache reference ........................... 7 ns
Mutex lock/unlock ........................... 25 ns
Main memory reference ...................... 100 ns
Compress 1K bytes with Zippy ............. 3,000 ns = 3 µs
Send 2K bytes over 1 Gbps network ....... 20,000 ns = 20 µs
SSD random read ........................ 150,000 ns = 150 µs
Read 1 MB sequentially from memory ..... 250,000 ns = 250 µs
Round trip within same datacenter ...... 500,000 ns = 0.5 ms
Read 1 MB sequentially from SSD* ..... 1,000,000 ns = 1 ms

北京上海两地的网络延迟时间，大致是内网网络访问速度的 60 倍（30ms/0.5ms）.

如果不做任何改造，一方直接访问另外一方的服务，那么我们的APP的反应会比原来慢 60 倍，其实考 虑上多次往返，可能会慢600倍。

如果机房都在上海，那么网络延迟只有内网速度的2倍，可以当成一个机房使用。 所有有些公司的多活方案，会选择同城机房，把同城的几个机房当成一个机房部署，可以在不影响服务 架构的情况下扩展出多个机房，不失为一个快速见效的方法。

L1 cache reference ......................... 0.5 ns Branch mispredict ............................ 5 ns L2 cache reference ........................... 7 ns Mutex lock/unlock ........................... 25 ns Main memory reference ...................... 100 ns Compress 1K bytes with Zippy ............. 3,000 ns = 3 µs Send 2K bytes over 1 Gbps network ....... 20,000 ns = 20 µs SSD random read ........................ 150,000 ns = 150 µs Read 1 MB sequentially from memory ..... 250,000 ns = 250 µs Round trip within same datacenter ...... 500,000 ns = 0.5 ms Read 1 MB sequentially from SSD* ..... 1,000,000 ns = 1 ms

我们在做多活的初期也讨论过同城方案，比如在北京周边建设一个新机房，迁移部分服务到新机房，两 个机房专线连接，服务间做跨机房调用。 虽然这个方案比较容易，也解决了机房的扩展问题，但是对高可用却没有好处，相反还带来了更高的风 险。

异地多活的关键

与同城多活的方案不同，异地多活的关键—— 限制机房间的相互调用，需要对业务 进行单元化改造 —— 定义清晰的服务边界，减少相互依赖，让每个机房都成为独立的单元，不依赖于其他机房。