之前的总结：《当年，我们是怎么平滑上云的?》提到了上云的背景，将所有系统从一个机房迁移到另一个机房。如上图所示：迁移前，系统部署在A机房（M6），为单机房结构。迁移后系统部署在B机房（阿里云），机房换了。《当年，我们是怎么平滑上云的?》得出三个结论：单体机房架构的核心是“全连接”；机房迁移方案的设计目标是：平滑迁移，不间断服务；可以批量迁移；随时可以回滚；要想顺利实施机房迁移，临时多机房架构是必然的；[4]核心问题4，临时多机房架构如何实现？上文提到，如果将单个机房的“全连接”架构复制到多个机房，会出现大量的跨机房调用。业务大幅增加请求延迟是不可接受的。为了减少这种延迟，必须实现“同机房连接”。多机房多活架构，什么是理想的“同机房连接”？如上图所示，多机房多活架构，在理想状态下，除了异步数据同步跨机房通信外，其他所有通信都是“同机房连接”：web连接业务服务；业务服务连接基础服务；服务连接数据库，主库写，从库读，读写分离；在上述架构中，每个机房是一个独立的系统，全量只通过异步数据获取同步数据，当一个机房出现故障时，将流量切换到另一个机房，这样就可以做到“机房级”故障冗余，实现高可用，上面说的multi有什么问题-机房架构?“异步数据同步”有一个延时（比如：1min），这个延时的存在会使得两台电脑的数据rooms不一致，导致业务出现严重问题。比如某时刻，用户X的余额为100元，两个机房都存储了准确的余额数据。20元，数据1分钟同步到B机房；余额100，X老婆在广州（就近访问B机房）用X的账户消费了70元，余额30元，1分钟后出数据。会同步到A机房；导致：过度消费（100余额，却买了150东西）；余额异常（余额是20还是30？）；上述架构适合什么业务场景？这是流氓行为。当每个机房都有很多全局业务数据访问场景时，上面的多机房架构就不适用了，会出现很多数据不一致的情况。但是，当每个机房访问本地业务数据时，上述多机房架构还是可行的。典型企业：滴滴、快狗打车。这些服务有一个数据聚合效应：下单的用户在同一个城市；接单司机同城；交易订单在同城；延迟一分钟的“异步数据同步”，对业务影响不大。多机房多活架构无法实现理想的“同机房连接”。有什么妥协吗？如果无法达到完全避免跨机房调用的理想状态，则尽量“减少”跨机房调用。如上图，如果不需要，先连接同机房的站点和服务：站点层只连接同机房的业务服务层；业务服务层只连接到同一机房的基础服务层；服务层只连接同一个机房??的“读”库；对于写库，没办法，只能跨机房读“写”库；这个方案并没有完全避免跨机房调用，但是确实“最小化”了跨机房调用，只有写请求是跨机房的。但是，绝大多数互联网业务都是读多写少的业务：百度搜索100%是阅读业务；京东淘宝电商99%的浏览搜索都是读业务，只有订单支付才是写业务；99%的58同城查看帖子列表详情为读服务，仅发布帖子为写服务；写服务占比较小，只有少数请求跨机房调用。多机房多活架构并没有做到100%“与同一机房连接”，通常被称为伪多机房多活架构。伪多机房多活架构有“主机房”和“从机房”的区别。多机房多活架构的初衷是为了容纳机房的故障。当本架构机房出现故障时，入口处的流量可以切换到另一个机房：容错；如果包括主库在内的上位机房宕机，只迁移流量，整个系统99%的读请求可以容错，但是1%的写请求会受到影响。这时候需要把从库换成主库。为了完全容错。这个过程需要DBA介入，不需要上游修改所有业务线。画外音：除非，站点和服务使用内网IP而不是内网域名连接数据库。架构师之路已经强调过很多次了，不要使用内网IP，一定要使用内网域名。伪多机房多活架构是一种实用性强的架构。对原有架构体系影响很小。与单机房架构相比，只是：跨机房的主从同步数据会增加10毫秒的延迟；画外音：主从同步数据，会有延迟。跨机房写入时，会有额外10毫秒的延迟；总结：理想的多机房多活架构是纯粹的“连入同一机房”，只有异步数据同步会跨机房；理想的多机房多活架构会存在比较严重的数据一致性问题只适用于有数据聚合效应的业务场景，比如：滴滴，快狗打车；伪多机房多活架构，思想是“尽量减少跨机房连接”，机房分主次，实现性强。对原有架构影响小，强烈推荐；临时多机房多活架构是机房迁移过程中的一种过渡状态。机房迁移的步骤是怎样的？听听明天的分解。想法比结论更重要。【本文为专栏作者《58神剑》原创稿件，转载请联系原作者】点此阅读更多该作者好文
