多机房多活架构,究竟怎么玩?

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

前情提要:

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

如上图:

  • 迁移之前,系统部署在机房A(M6)内,是单机房架构。
  • 迁移之后,系统部署在机房B(阿里云)内,换了一个机房。

当年,我们是怎么平滑上云的?》有三结论:

  • 单机房架构的核心是“全连接”;
  • 机房迁移方案的设计目标是:平滑迁移,不停服务;可以分批迁移;随时可以回滚;
  • 想要平滑的实施机房迁移,临时性的多机房架构不可避免;

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

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

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

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

  • web连业务服务;
  • 业务服务连基础服务;
  • 服务连数据库,主库写,从库读,读写分离;

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

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

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

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

  • 余额100,X在北京(就近访问机房A)消费了80元,余额仅剩20元,该数据在1分钟后会同步到机房B;
  • 余额100,X的夫人在广州(就近访问机房B)用X的账号消费了70元,余额剩余30元,该数据在1分钟后也会同步到机房A;

从而导致:

  • 超额消费(100余额,却买了150的东西);
  • 余额异常(余额是20,还是30?);

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

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

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

典型的业务:滴滴,快狗打车。

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

  • 下单用户在同一个城市;
  • 接单司机在同一个城市;
  • 交易订单在同一个城市;

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

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

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

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

  • 站点层只连接同机房的业务服务层;
  • 业务服务层只连接同机房的基础服务层;
  • 服务层只连接同机房的“读”库;
  • 对于写库,没办法,只有跨机房读“写”库了;

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

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

  • 百度的搜索100%是读业务;
  • 京东淘宝电商99%的浏览搜索是读业务,只有下单支付是写业务;
  • 58同城99%帖子的列表详情查看是读业务,只有发布帖子是写业务;

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

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

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

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

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

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

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

  • 跨机房主从同步数据,会多10毫秒延时;画外音:主从同步数据,本来就会有延时。
  • 跨机房写,会多10毫秒延时;

小结:

  • 理想多机房多活架构,是纯粹的“同机房连接”,仅有异步数据同步会跨机房;
  • 理想多机房多活架构,会有较严重数据一致性问题,仅适用于具备数据聚集效应的业务场景,例如:滴滴,快狗打车;
  • 伪多机房多活架构,思路是“最小化跨机房连接”,机房区分主次,落地性强,对原有架构冲击较小,强烈推荐;

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

思路比结论重要。

【本文为51CTO专栏作者“58沈剑”原创稿件,转载请联系原作者】

戳这里,看该作者更多好文

 

责任编辑:赵宁宁 来源: 51CTO专栏
相关推荐

2022-04-08 07:52:00

架构多机房多活

2022-07-05 15:08:52

机房架构

2018-04-02 09:33:03

多活技术架构运维

2023-11-28 07:45:48

Rust自动化测试

2020-11-20 09:23:01

高可用异地淘宝

2022-02-18 11:05:25

Jpa配置Address

2018-06-26 15:58:39

进程内缓存缓存数据

2019-03-18 10:32:33

容灾双活同城

2021-02-04 10:00:09

异地多中心容灾

2022-07-11 10:08:34

大数据平台机房

2022-08-16 15:20:12

微服务IT运维

2022-09-21 11:44:47

多机房部署数据库服务

2023-04-17 07:34:17

电商平台ChatGPT表格

2023-11-27 07:57:46

2023-05-30 07:27:45

高可用架构流量

2021-01-12 07:44:13

群消息在线

2011-07-12 10:01:04

2015-05-06 13:39:15

Windows系统复杂

2009-09-21 16:06:48

2022-11-04 17:50:16

架构Java
点赞
收藏

51CTO技术栈公众号