互联网大厂单元化架构设计衍变之路
随着业务的多元化发展,拿滴滴,美团等大厂来说,如滴滴打车,外卖,酒店,旅行等持续高速增长,单个大型分布式的集群,通过机器+集群内部拆分,虽然具备了一定的可扩展性。但随着业务量的进一步增长,整个集群规模主键变得巨大,从而会在某个点达到瓶颈,无法满足扩展性需要,并且大集群内核心服务出现了问题,会影响全网用户
以滴滴打车、美团外卖举例:
打车业务量巨大,尤其是早晚高峰。全年订单已越10亿
外卖业务量庞大,目前单量突破1700w/天
面临问题
容灾问题
核心服务(比如订单服务)挂掉,会影响全网所有用户,导致整个业务不可用
数据库主库集中在一个IDC,主机房挂掉,会影响全网所有用户,整个业务无法快速切换和恢复
资源扩展问题
单IDC的资源(机器、网络带宽等)已经无法满足,扩展ICD时,存在跨机房访问时延问题(增加异地机房时,时延问题更加严重)
数据库主库单点,连接数有限,不能支持应用程序的持续扩展
大集群拆分问题
分布式集群规模开大后,会相应的带来资源扩展、大集群拆分及容灾问题
所以对业务扩展及容灾需求考虑,我们需要一套从底层架构彻底解决问题的方案,业界主流解决方案:单元化架构方案(阿里、支付宝、饿了么、微信 等)
SET化方案目标
业务:解决业务遇到的扩展性和容灾问题,支撑业务的高速发展
通用性:架构侧形成统一通用的解决方案,方便个业务线接入使用
SET化架构设计
解决容灾问题:
UnitA一套业务的核心组件,比如网购,从加入购物车到下单,经过A、B、C、D等步骤,全部部署到UnitA的一个机房中,UnitB和UnitC是UnitA的备份,如果UnitA的服务或MQ发生故障,就会路由到UnitB或UnitC中
非核心的业务组件部署到center中
解决扩展问题:
UnitA可以是旅游,UnitB可以是外卖,将来还可以扩展
相关概念
流量路由:按照特殊的key(通常为userid)进行路由,判断某次请求该路由到中心集群还是单元化集群
中心集群:为进行单元化改造的服务(通常不在核心交易链路)成为中心集群,跟当前架构保存一致
单元化集群:
每个单元化集群只负责本单元内的流量处理,以及实现流量拆分及故障隔离
每个单元化集群前期只存储本单元产生的交易数据,后续会做双向数据同步,实现容灾切换需求
中间件(RPC、KV、MQ等)
RPC:对于SET服务,调用封闭在SET内;对于非SET服务,沿用现有路由逻辑
KV:支持分SET的数据产生和查询
MQ:支持分SET的消息生产和消费
数据同步
全局数据(数据量小且变化不大,比如商家的菜品数据)部署在中心集群,其他单元化集群同步全局数据到本单元化内
未来演变为异地多活架构时,各单元化集群数据需要进行双向同步来实现容灾需要
SET化路由策略及其能力
异地容灾:
通过SET化架构的流量调度能力,将SET分别部署到不停地区的数据中心,实现跨地区容灾支持
高效本地化服务
利用前端位置信息采集和域名解析策略,将流量路由由最近的SET,提供最高效的本地化服务
比如O2O场景天然具有本地生产,本地消费的特点,更加需要SET化支持
集装箱式扩展
SET的封装性支持更灵活的部署扩展性,比如SET一键创建/下线,SET一键发布等(比如docker)
C不是很重要,所以放到中心集群,需要的时候去中心集群调用
中心集群A可以通过路由服务同单元的Set服务
Set3中B如果调用不到本单元的C(本单元优先级最高),可以通过路由服务调用Set2中的C
SET架构原则
对业务的透明原则:
SET架构的实现业务代码透明,业务代码层面不需要关心SET化规则,SET部署的问题
SET切分规则:
理论上,切分规则由业务层面按需定制
实现上,建议优先选最大的业务维度进行切分
比如海量用户的O2O业务,按用户位置信息进行切分。此外接入层、逻辑层和数据层可以有独立的SET切分规则,有利于实现部署和运维成本的最优化
部署规范原则:
一个SET并不一定只限制在一个机房,也可以跨机房或者跨地区部署;为保证灵活性,单个SET内机器数不宜过多(如不超过1000台物理机)