异地多活

为什么要做异地多活?

做多活，是受业务发展的驱动，经过几年的高速发展，我们的业务已经扩大到单个数据中心撑不住了，主要机房已经不能再加机器，业务却不断的要求加扩容，所以我们需要一个方案能够把服务器部署到多个机房。另外一个更重要的原因是，整个机房级别的故障时有发生，每次都会带来严重的后果，我们需要在发生故障时，能够把一个机房的业务全部迁移到别的机房，保证服务可用。

目标

1. 服务可以扩展到多个机房
2. 能够应对整个机房级别的故障

解决这两个问题的常见办法是做异地多活，把服务分散到多个机房，自然扩展和高可用的问题就迎刃而解了

对于一个业务快速增长的企业，每次故障带来的损失也相应是加速增长的，而技术的投入总体上是线性的，初期故障损失小于技术投入，在某个时间点，故障的损失会超过技术投入，这时就要用一些高可用方案，来避免故障，多活就是其中最重要的一种。

如果机房都在上海，那么网络延迟只有内网速度的 2 倍，可以当成一个机房使用。所有有些公司的多活方案，会选择同城机房，把同城的几个机房当成一个机房部署，可以在不影响服务架构的情况下扩展出多个机房，不失为一个快速见效的方法。我们在做多活的初期也讨论过同城方案，比如在北京周边建设一个新机房，迁移部分服务到新机房，两个机房专线连接，服务间做跨机房调用。虽然这个方案比较容易，也解决了机房的扩展问题，但是对高可用却没有好处，相反还带来了更高的风险。

与同城多活的方案不同，异地多活的方案会限制机房间的相互调用，需要定义清晰的服务边界，减少相互依赖，让每个机房都成为独立的单元，不依赖于其他机房。经过几番考量，我们最终选择了异地多活的方案，对这两个方案的比较和思考可以见下表，异地多活虽然更困难一点，但是能同时达到我们的两个核心目标，更为可行。

方案

服务划分方法（Sharding）

1. 地理位置
2. 用户 id
3. …

流量路由

基于某种划分规则，开发统一的流量路由层（API Router），这一层负责对客户端过来的 API 调用进行路由，把流量导向到正确的空间。API Router 部署在多个公有云机房中，用户就近接入到公有云的 API Router，还可以提升接入质量.

全局 ID

节点 ID+自增

数据复制：

为了实现可用优先原则，所有机房都会有全量数据，这样用户可以随时切换到其他机房，全量数据就需要对数据进行实时复制，开发相应的中间件，对 mysql，zookeeper ，消息队列和 redis 的数据进行复制。