行业案例：饿了么异地多活架构演进.pdfVIP

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

饿了么要做多活，是受业务发展的驱动，经过几年的高速发展，我们的业务已经扩大到单个数据中心撑

不住了，主要机房已经不能再加机器，业务却不断的要求加扩容，所以我们需要一个方案能够把服务器

部署到多个机房。

另外一个更重要的原因是，整个机房级别的故障时有发生，每次都会带来严重的后果，我们需要在发生

故障时，能够把一个机房的业务全部迁移到别的机房，保证服务可用。

异地多活面临的主要挑战是网络延迟，以北京到上海1468公里，即使是光速传输，一个来回也需要接

近10ms，我们在实际测试的过程中，发现上海到北京的网络延迟，一般是30ms。

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

L1cachereference0.5ns

Branchmispredict5ns

L2cachereference7ns

Mutexlock/unlock25ns

Mainmemoryreference100ns

Compress1KbyteswithZippy3,000ns3µs

Send2Kbytesover1Gbpsnetwork20,000ns20µs

SSDrandomread150,000ns150µs

Read1MBsequentiallyfrommemory250,000ns250µs

Roundtripwithinsamedatacenter500,000ns0.5ms

Read1MBsequentiallyfromSSD*1,000,000ns1ms

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

如果不做任何改造，一方直接访问另外一方的服务，那么我们的APP的反应会比原来慢60倍，其实考

虑上多次往返，可能会慢600倍。

如果机房都在上海，那么网络延迟只有内网速度的2倍，可以当成一个机房使用。

所有有些公司的多活方案，会选择同城机房，把同城的几个机房当成一个机房部署，可以在不影响服务

架构的情况下扩展出多个机房，不失为一个快速见效的方法。

我们在做多活的初期也讨论过同城方案，比如在北京周边建设一个新机房，迁移部分服务到新机房，两

个机房专线连接，服务间做跨机房调用。

虽然这个方案比较容易，也解决了机房的扩展问题，但是对高可用却没有好处，相反还带来了更高的风

险。

异地多活的关键

与同城多活的方案不同，异地多活的关键——限制机房间的相互调用，需要对业务进行单元化改造

——定义清晰的服务边界，减少相互依赖，让每个机房都成为独立的单元，不依赖于其他机房。

经过几番考量，我们最终选择了异地多活的方案，对这两个方案的比较和思考可以见下表，异地多活虽

然更困难一点，但是能同时达到我们的两个核心目标，更为可行。

设计：异地多活的实现思路和方法

我们的异地多活方案的，有几条基本原则，整个多活方案都是这些原则的自然推导。但在介绍一下这些

原则之前，先要说明一下饿了么的服务流程，才能让大家更好的理解这些原则的来由

下面这张简图是我们的主流程：

业务过程中包含3个最重要的角色，分别是用户、商家和骑手，一个订单包含3个步骤：

1.用户打开我们的APP，系统会推荐出用户位置附近的各种美食，推荐顺序中结合了用户习惯，推荐

排序，商户的推广等。用户找到中意的食物，下单并支付，订单会流转到商家。

2.商家接单并开始制作食物，制作完成后，系统调度骑手赶到店面，取走食物

3.骑手按照配送地址，把食物送到客户手中。

整个下单到配送完成，有严格的时间要求，必须在短短的几十分钟内完成，我们的服务和地理位置强相

关，并且实时性要求高，