16、RabbitMQ学习笔记—BAT/TMD大厂单元化架构设计衍变之路

随着大型互联网公司业务的多元化发展,就拿滴滴、美团等大厂来讲,如滴滴打车、单车、外卖、酒店、旅行、金融等业务持续高速增长,单个大型分布式体系的集群,通过加机器+集群内部拆分(kv, mq、 MySQL等) ,虽然具备了一定的可扩展性。但是,随着业务量的进一步增长,整个集群规模逐渐变得巨大,从而一定会在某个点上达到瓶颈,无法满足扩展性需要,并且大集群内核心服务出现问题,会影响全网所有用户。
以滴滴打车、美团外卖举例来说:
打车业务体量巨大,尤其是在早晚高峰期。全年订单量已越10亿。
外卖业务体量庞大,目前单量已突破1700W/天,对于如此庞大的单个大型分布式集群,会面临以下问题:

• 1、容灾问题
  核心服务(比如订单服务)挂掉,会影响全网所有用户导致整个业务不可用;
  数据库主库集中在一个IDC,主机房挂掉,会影响全网所有用户,整个业务无法快速切换和恢复;
• 2、资源扩展问题
  单IDC的资源(机器、网络带宽等)已经没法满足,扩展IDC时,存在跨机房访问时延问题(增加异地机房时,时延问题更加严重) ;
  数据库主库单点,连接数有限,不能支持应用程序的持续扩展
• 3、大集群拆分问题
  核心问题:分布式集群规模扩大后,会相应的带来资源扩展、大集群拆分以及容灾问题。
  所以出于对业务扩展性以及容灾需求的考虑,我们需要一套从底层架构彻底解决问题的方案,业界主流解决方案:
  单元化架构方案(阿里、支付宝、饿了么、微信等)

同城"双活"架构介绍:
目前很多大型互联网公司的业务架构可以理解为同城"双活"架构,注意这里的“双活”是加引号的,具体可以这样理解:
业务层面上已经做到真正的双活(或者多活) ,分别承担部分流量;存储层面比如定时任务、缓存、持久层、数据分析等都是主从架构,会有跨机房写；一个数据中心故障,可以手动切换流量,部分组件可以自动切换;
两地三中心架构介绍:
使用灾备的思想,在同城"双活"的基础上,在异地部署一套灾备数据中心,每个中心都具有完备的数据处理能力,只有当主节点故障需要容灾的时候才会紧急启动备用数据中心;

SET化方案目标:

• 业务:解决业务遇到的扩展性和容灾等需求,支撑业务的高速发展
• 通用性:架构侧形成统一通用的解决方案,方便各业务线接入使用

• 流量路由：
  按照特殊的key进行路由，判断某次请求该路由到中心集群还是单元化集群
• 中心集群：
  未进行单元化改造的服务（通常不在核心交易链路，比如：供应链）成为中心集群，跟当前架构保持一致
• 单元化集群：
  每个单元化集群只负责本单元被的流量处理，以实现流量拆分以及故障隔离
  每个单元化集群前期只存储本单元产生的交易数据，后续会做双向数据同步，实现容灾切换需求
  中间件
  RPC:对于set服务，调用封闭在set内，对于非set服务，沿用现有路由逻辑
  KV：支持分set的数据生成和查询
  MQ：支持分set的消息产生和消费
  数据同步:
  全局数据(数据量小且变化不大,比如商家的菜品数据)部署在中心集群,其他单元化集群同步全局数据到本单元化内;
  未来演变为异地多活架构时,各单元化集群数据需要进行双向同步来实现容灾需要
  SET化路由策略及其能力:
• 异地容灾:
  通过SET化架构的流量调度能力,将SET分别部署在不同地区的数据中心,实现跨地区容灾支持
• 高效本地化服务
  利用前端位置信息采集和域名解析策略,将流量路由到最近的SET,提供最高效的本地化服务;
  比如020场景天然具有本地生产,本地消费的特点,更加需要SET化支持
• 集装箱式扩展:
  SET的封装性支持更灵活的部署扩展性,比如SET-键创建/下线, SET-键发布等
  
  
  
  

set化架构实现