很多产品发展到一定规模之后，可能会走出国门，技术架构要做到国际化。或者基于高可用 / 高性能的需求，需要做异地多活。
多数据中心架构
两者在是实现上有一定类似之处，比如都可以建立独立的数据中心，数据中心内部做一套自治系统，也就是说独立数据中心内需要具备完备的功能，做到链路内聚，内聚服务可以独立在数据中心内运行。
系统自治对于服务层来说比较简单，服务扩容时无状态服务只要做到可以水平扩展就可以了。所以统一部署到数据中心内即可。
但存储服务就比较复杂一些，需要保证数据中心内服务可以独立运行，还需要做好多数据中心之间的数据同步，因为需要保证多个数据中心之间的数据一致。
可能是Master-Master架构，就是两个数据中心都是可写的，或者是Master-Slave架构，一个写另一个读，具体使用哪种，需要依业务场景来设计。
Master-Master存储架构
Master-Master架构，处理数据一致性是个很大的挑战，两个数据中心之间因地理位置较远，存在较大的延迟。
如果是国际化系统的独立部署，延迟会更高一些，比如国内用户写到上海Master，所有写操作需要回到国内数据中心完成。国外用户数据写到国外数据中心Master，写操作在国外数据中心进行。
架构层次上看是Master-Master，在用户数据纬度看是Master-Slave模式，每条数据只能在用户归属的数据中心写入，再通过异步复制方式写到其他数据中心中。
多数据中心通过数据复制方式实现了数据最终一致性。如何在业务逻辑纬度处理这种数据弱一致性带来的问题呢？
需求一：用户访问数据问题
想象一个场景，如果用户可以根据自己的位置就近接入数据中心，那么所有的读写数据处理一致性的场景就会收到影响，业务逻辑需要对数据一致性做到实时改变，需要做好数据一致性处理和用户请求依照数据实时性做路由。
整体设计上会带来高昂的实现成本和维护成本，很大一定程度上限制了系统的无状态扩容的能力。
所以我们可以限制用户访问哪个数据，通过路由服务将用户路由到常用的数据中心，那里有其已归属的数据。这样用户数据读写的一致性问题就迎刃而解了。数据可以做到一定程度的强一致，也不需要在数据之间做数据的实时同步，也降低了数据同步带来的宽带需求。
需求二：用户访问其他用户数据
上面解决了用户自己数据读写的需求，但是当用户想访问其他用户的其他数据中心数据时应该怎么处理呢？
这种场景下我们从业务角度考虑下，其实大部分场景对数据一致性要求并不高。需求场景下可以支持一定的数据延迟，也并不会带来太大的问题。
如果对于数据一致性要求比较高的场景，比如支付金融场景，可以提供全局的分布式事务或是分布式锁的方式解决。当然场景很少，所以也不会带来太大问题。
数据同步的可靠性实现
数据中心之间需要做大量的数据同步，数据是否达到最终一致，取决于数据同步服务是否可靠。
这种情况一般借助于消息队列实现，依靠消息队列的顺序写，一个备份同步成功即算作成功，如果失败则重试。这样可以让消息队列有更好的可用性和写入性能。
每个数据中心将需要同步的数据写入本数据中心的消息队列，由其他数据中心对数据进行拉取与重放，达到数据同步的目的。
异地多活容灾
很多巨型互联网产品发展到一定规模之后，其可用性往往造成很大经济损失，比如微信，支付宝这些用户规模巨大的产品，如果可用性有一点的降级，都会对大规模的用户影响，所以微信，支付宝这些产品早已做了异地多活。
比如某个数据中心园区主光纤被挖断，可能造成几千台服务器不可用，引发整个数据中心服务瘫痪。
以前我曾遇到一次这样的事故，当时某个数据中心服务不可用，我们尝试修改接入服务，将故障中心的流量迁走，但是收效甚微。
数据中心内的上百个服务虽然做了容灾和冗余设计，每个模块看起来都没有单点故障问题。但整体上无数个服务实例分散在数据中心多个机房几千台服务器上，服务之间通过RPC调用，调用链路复杂，呈网状结构。
同时虽然服务做了冗余和可用性设计，但是没有做过对应的容灾等级规划和容灾验证与故障演练，没人知道切走流量是否可以保证整个服务多个数据中心是否可用，是否会出现什么不可控情况造成雪崩。
所以针对于类似问题，可以做多个园区的容灾设计，每个数据中心服务部署到物理隔离的多个园区，单个园区整体故障时，也不会造成整个数据中心的不可用。
传统灾备方案
传统数据中心的灾备方案，一般是同城两个互备数据中心，异地建设一个灾备中心，三个数据中心平时只能一个提供在线服务，故障时将业务流量切到其他数据中心。一份数据在多个园区之间保留至少2个以上副本，这样在一个园区故障后，可以无损对外提供服务。
这种方案的问题在于，灾备中心平时无实际流量，在主数据中心故障时，切换到灾备数据中心可能还会造成大量服务不可用情况，同时造成资源浪费。
所以优化方案是，三个数据中心可以同时提供服务，某个数据中心故障时，另外两个园区业务流量只会各增加50%。每个园区资源跑在容量的2/3，保留1/3容量，提供无损容灾能力。
因为三个园区同时提供在线服务，所以服务故障时，要解决的是怎样把服务流量切到其他园区，方案也就更简单了。
有了迁移容灾方案，是否可以做到故障时自动迁移流量，对业务透明呢？
这就需要我们对服务模块可以准确识别出某些服务可用性问题，然后自动切换到其他服务实例，而避免被拖死。
同时还需要建立一套手工操作对全局对业务透明的系统，可以在大型网络故障时，由人工介入，实现业务流量快速迁移或分散到其他园区或数据中心。
设计并部署了整体技术方案之后，很重要的一点就是需要做故障演练，看看迁移效果是否符合预期。
