前情提要：

《 当年，我们是怎么平滑上云的？ 》一文中提到了上云的背景，将所有的系统，从一个机房，迁移到另一个机房。

如上图：

迁移之前，系统部署在机房A（M6）内，是单机房架构。

迁移之后，系统部署在机房B（阿里云）内，换了一个机房。

《当年，我们是怎么平滑上云的？ 》有三结论：

（1）单机房架构的核心是“全连接”；

（2）机房迁移方案的设计目标是：平滑迁移，不停服务；可以分批迁移；随时可以回滚；

（3）想要平滑的实施机房迁移，临时性的多机房架构不可避免；

【4】核心问题四，临时性多机房架构如何实施？

如前文所述，如果将单机房“全连接”架构复制到多机房，会有大量跨机房调用，极大增加请求时延，是业务无法接受的，要想降低这个时延，必须实施“同机房连接”。

多机房多活架构，什么是理想状态下的“同机房连接”？

如上图所示，多机房多活架构，最理想状态下，除了异步数据同步跨机房通讯，其他所有通讯均为“同机房连接”：

（1）web连业务服务；

（2）业务服务连基础服务；

（3）服务连数据库，主库写，从库读，读写分离；

上述架构，每个机房是一套独立的系统，仅仅通过异步数据同步获取全量数据，当发生机房故障时，将流量切到另一个机房，就能冗余“机房级”故障，实现高可用。

上述多机房架构存在什么问题？

“异步数据同步”存在延时（例如：1min），这个延时的存在，会使得两个机房的数据不一致，从而导致严重的业务问题。

举个例子，某一个时刻，用户X有余额100元，两个机房都存储有该余额的精准数据，接下来：

（1）余额100，X在北京（就近访问机房A）消费了80元，余额仅剩20元，该数据在1分钟后会同步到机房B；

（2）余额100，X的夫人在广州（就近访问机房B）用X的账号消费了70元，余额剩余30元 ，该数据在1分钟后也会同步到机房A；

从而导致：

（1）超额消费（100余额，却买了150的东西）；

（2）余额异常（余额是20，还是30？）；

上述架构适合于什么业务场景？

任何脱离业务的架构设计都是耍流氓。

当每个机房都有很多全局业务数据的访问场景时，上述多机房架构并不适用，会存在大量数据不一致。但当每个机房都访问局部业务数据时，上述多机房架构仍然是可行的。

典型的业务：滴滴，快狗打车。

这些业务具备 数据聚集效应：

（1）下单用户在同一个城市；

（2）接单司机在同一个城市；

（3）交易订单在同一个城市；

这类业务非常适合上述多机房多活架构，多个机房之间即使存在1分钟延时的“异步数据同步”，对业务也不会造成太大的影响。

多机房多活架构，做不到理想状态下的“同机房连接”，有没有折中方案？

如果完全避免跨机房调用的理想状态做不到，就尽量做到“最小化”跨机房调用。

如上图所示，在非必须的情况下，优先连接同机房的站点与服务：

（1）站点层只连接同机房的业务服务层；

（2）业务服务层只连接同机房的基础服务层；

（3）服务层只连接同机房的“读”库；

（4）对于写库，没办法，只有跨机房读“写”库了；

该方案没有完全避免跨机房调用，但它做到了“最小化”跨机房调用，只有写请求是跨机房的。

但互联网的业务，绝大部分是读多写少的业务：

（1）百度的搜索100%是读业务；

（2）京东淘宝电商99%的浏览搜索是读业务，只有下单支付是写业务；

（3）58同城99%帖子的列表详情查看是读业务，只有发布帖子是写业务；

写业务比例相对少，只有很少请求会跨机房调用。

该多机房多活架构，并没有做到100%的“同机房连接”，通常称作 伪多机房多活架构。

伪多机房多活架构，有 “主机房”和“从机房”的差别。

多机房多活架构的初衷是容机房故障，该架构当出现机房故障时，可以把入口处流量切到另一个机房：

（1）如果挂掉的是，不包含主库的从机房，迁移流量后能直接容错；

（2）如果挂掉的是，包含主库的主机房，只迁移流量，系统整体99%的读请求可以容错，但1%的写请求会受到影响，此时需要将从库变为主库，才能完全容错。这个过程需要DBA介入，不需要所有业务线上游修改。

画外音：除非，站点和服务使用内网IP，而不是内网域名连接数据库。架构师之路已经强调过很多次，不要使用内网IP，一定要使用内网域名。

伪多机房多活架构，是一个实践性，落地性很强的架构，它对原有架构体系的冲击非常小，和单机房架构相比，仅仅是：

（1）跨机房主从同步数据，会多10毫秒延时；

画外音： 主从同步数据，本来就会有延时。

（2）跨机房写，会多10毫秒延时；

小结：

（1）理想多机房多活 架构，是纯粹的“同机房连接”，仅有异步数据同步会跨机房；

（2） 理想多机房多活架构，会有较严重数据一致性问题，仅适用于具备数据聚集效应的业务场景，例如： 滴滴，快狗打车 ；

（3） 伪多机房多活架构，思路是“最小化跨机房连接”，机房区分主次，落地性强，对原有架构冲击较小，强烈推荐；

临时性多机房多活架构，是机房迁移过程中的一个过渡状态，机房迁移步骤又该如何 ？且听 明天分解。

思路比结论重要。

《 当年，我们是怎么平滑上云的？ 》

讨论：

贵司有没有多机房多活，架构如何？