服务可以扩展到多个机房
能够应对整个机房级别的故障
1. 业务内聚
单个订单的旅单过程，要在一个机房中完成，不允许跨机房调用。
这个原则是为了保证实时性，旅单过程中不依赖另外一个机房的服务，才能保证没有延迟。
我们称每个机房为一个 ezone，一个 ezone 包含了饿了么需要的各种服务。
一笔业务能够内聚在一个 ezone 中，那么一个定单涉及的用户，商家，骑手，都会在相同的机房，
这样订单在各个角色之间流转速度最快，不会因为各种异常情况导致延时。
恰好我们的业务是地域化的，通过合理的地域划分，也能够实现业务内聚。
2. 可用性优先
当发生故障切换机房时，优先保证系统可用，首先让用户可以下单吃饭，容忍有限时间段内的数据不一致，在事后修复。
每个 ezone 都会有全量的业务数据，当一个 ezone 失效后，其他的 ezone 可以接管用户。
用户在一个ezone的下单数据，会实时的复制到其他ezone。
3. 保证数据正确
在确保可用的情况下，需要对数据做保护以避免错误，在切换和故障时，
如果发现某些订单的状态在两个机房不一致，会锁定该笔订单，阻止对它进行更改，保证数据的正确。
4. 业务可感
因为基础设施还没有强大到可以抹去跨机房的差异，需要让业务感知多活逻辑，业务代码要做一些改造，
包括：需要业务代码能够识别出业务数据的归属，只处理本 ezone 的数据，过滤掉无关的数据。
完善业务状态机，能够在数据出现不一致的时候，通过状态机发现和纠正。为了实现业务内聚，我们首先要选择一个划分方法（Sharding Key），对服务进行分区，让用户，商户，骑手能够正确的内聚到同一个 ezone 中。
分区方案是整个多活的基础，它决定了之后的所有逻辑。
基于地理位置划分规则，我们开发了统一的流量路由层（API Router），
这一层负责对客户端过来的 API 调用进行路由，把流量导向到正确的 ezone。A
PI Router 部署在多个公有云机房中，用户就近接入到公有云的API Router，还可以提升接入质量。