|
|
51CTO旗下网站
|
|
移步端
创造专栏

多机房多活架构,结果怎么玩?

如前文所述,如果将单机房“全连接”架构复制到多机房,会有恢宏跨机房调用,大幅度增加请求时延,是工作无法收到的,要想降低这个时延,必须实行“同机房连接”。

笔者:58沈剑| 2020-02-12 11:34

明天情提要:

那时,咱们是怎么平滑上云的?》一文中提到了上云的全景,名将全部的体系,副一个机房,搬迁到另一番机房。

如上图:

  • 搬迁之前,系统部署在机房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沈剑”原创稿件,转载请联系原作者】

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

    【编纂推荐】

    1. 宜信微服务架构落地及其形成|分享实录
    2. 架构选型,结果什么时候选Redis?
    3. 那时,咱们是怎么平滑上云的?
    4. 悄悄告诉你,互联网公司可以的技艺架构!
    5. 顽强核干货:一位菜鸟码农的架构师“封神”的路!
    【义务编辑: 赵宁宁 TEL:(010)68476606】

    点赞 0
  • 架构  平滑上云  机房迁移
  • 分享:
    大家都在看
    猜你喜欢

    1. <source id="5716ebdd"></source>