SET化架构设计

互联网大厂单元化架构设计衍变之路

随着业务的多元化发展，拿滴滴，美团等大厂来说，如滴滴打车，外卖，酒店，旅行等持续高速增长，单个大型分布式的集群，通过机器+集群内部拆分，虽然具备了一定的可扩展性。但随着业务量的进一步增长，整个集群规模主键变得巨大，从而会在某个点达到瓶颈，无法满足扩展性需要，并且大集群内核心服务出现了问题，会影响全网用户

以滴滴打车、美团外卖举例：

打车业务量巨大，尤其是早晚高峰。全年订单已越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台物理机）