前情提要: 《当年,多机我们是房多怎么平滑上云的?》一文中提到了上云的背景,将所有的活架系统,从一个机房,构究迁移到另一个机房。竟玩 如上图: 《当年,房多我们是活架怎么平滑上云的?》有三结论: 【4】核心问题四,临时性多机房架构如何实施? 如前文所述,如果将单机房“全连接”架构复制到多机房,会有大量跨机房调用,极大增加请求时延,是业务无法接受的高防服务器,要想降低这个时延,必须实施“同机房连接”。 多机房多活架构,什么是理想状态下的“同机房连接”? 如上图所示,多机房多活架构,最理想状态下,除了异步数据同步跨机房通讯,其他所有通讯均为“同机房连接”: 上述架构,每个机房是一套独立的系统,仅仅通过异步数据同步获取全量数据,当发生机房故障时,将流量切到另一个机房,就能冗余“机房级”故障,实现高可用。 上述多机房架构存在什么问题? “异步数据同步”存在延时(例如:1min),这个延时的存在,会使得两个机房的数据不一致,从而导致严重的业务问题。 举个例子,某一个时刻,用户X有余额100元,两个机房都存储有该余额的云南idc服务商精准数据,接下来: 从而导致: 上述架构适合于什么业务场景? 任何脱离业务的架构设计都是耍流氓。 当每个机房都有很多全局业务数据的访问场景时,上述多机房架构并不适用,会存在大量数据不一致。但当每个机房都访问局部业务数据时,上述多机房架构仍然是可行的。 典型的业务:滴滴,快狗打车。 这些业务具备数据聚集效应: 这类业务非常适合上述多机房多活架构,多个机房之间即使存在1分钟延时的“异步数据同步”,对业务也不会造成太大的影响。网站模板 多机房多活架构,做不到理想状态下的“同机房连接”,有没有折中方案? 如果完全避免跨机房调用的理想状态做不到,就尽量做到“最小化”跨机房调用。 如上图所示,在非必须的情况下,优先连接同机房的站点与服务: 该方案没有完全避免跨机房调用,但它做到了“最小化”跨机房调用,只有写请求是跨机房的。 但互联网的业务,绝大部分是读多写少的业务: 写业务比例相对少,只有很少请求会跨机房调用。 该多机房多活架构,并没有做到100%的“同机房连接”,通常称作伪多机房多活架构。 伪多机房多活架构,有“主机房”和“从机房”的差别。 多机房多活架构的初衷是容机房故障,该架构当出现机房故障时,可以把入口处流量切到另一个机房: 画外音:除非,站点和服务使用内网IP,而不是内网域名连接数据库。架构师之路已经强调过很多次,不要使用内网IP,一定要使用内网域名。 伪多机房多活架构,是一个实践性,落地性很强的架构,它对原有架构体系的冲击非常小,和单机房架构相比,仅仅是: 小结: 临时性多机房多活架构,是机房迁移过程中的一个过渡状态,机房迁移步骤又该如何?且听明天分解。 思路比结论重要。 【本文为专栏作者“58沈剑”原创稿件,转载请联系原作者】 戳这里,看该作者更多好文