中台架构
一. 背景
说起中台架构,就不得不提起2015年了的那个契机了,马云带着阿里同事拜访了一家传奇的游戏公司Supercell。2012年,Supercell推出了爆款游戏“部落冲突”,迅速风靡全球。这家游戏公司迅速成为了那些年的爆款游戏工厂。而马云参观的那一年,它的员工总数还在200人左右徘徊,却轻松收获了23.26亿美元的营收,净利润更是高达9.64亿美元。
平均下来,一个员工创造了千万级别的营收。
前台是各自为战的独立游戏开发小组,成员精简,方向自由,每一个团队都是一个独立的游戏产品的负责人。后台则是负责开发通用素材和算法的技术部门,他们的工作更加具有重复性,他们的产出为前台部门服务,方便快速试错。
在这个意义上,这个能够沉淀、复用企业能力、为前台提供支持的后台,就是后来中台建设的蓝图。 建设中台的目标,是通过复用提高企业整体的效率。
说回阿里,从2015年之后阿里也开始发起「大中台,小前台」战略,其实在此之前,阿里就已经有中台这个概念,只不过大家的叫法不一样罢了,其业务核心围绕着电商生态展开,包括淘宝、天猫、聚划算、咸鱼、盒马、本地生活等等业务和服务,从垂直业务到横向产品错综复杂,但是其核心能力都离不开用户、会员、商品、交易、履约、供应链、逆向等模块,所以第一步就是沉淀核心能力和流程标准到中台,然后中台快速支撑业务,减少业务有试错的成本,并且增加业务的迭代效率。
而阿里国际相较于国内淘天业务起步的比较晚,当时的国际团队主要业务有:LAZADA、DARAZ、AE、ICBU等面向国际或者直接本对本的国际业务。国际团队起步的初期,是完全参考和引入了国内淘天的架构模型,仍然以「大中台,小前台」的基本原则,围绕着业务中台来开展前台业务,而为了简单快速起步,一开始的时候,各个业务品牌以轻量级的二方包被中台集成,以中台视角发布和维护,这个模式的好处就是业务方很轻量,绝大多数的业务能力都下沉到了中台,所以业务可以快速试错,快速创新,而中台主要做好能力沉淀,定义标准化流程。
但是后来随着各个品牌的业务不断发展和扩大,前台业务的迭代速度也越来越频繁,而且业务方的个性化诉求也越来越多,所以业务方对中台团队的业务理解力和相应速度都提出了很高的要求,因此职责边界开始慢慢下移,开始以业务视角为主、中台支持为辅的模式,这种模式的好处就是中台可以减少不必要的业务理解和开发,而业务方也有更大的权限来实现自己的个性化需求。
即使职责边界已经划分清晰,但是随着组织架构的调整或者业务的扩张,还是慢慢的出现了一些协同上的问题,比如说发布频率的不一致、职责边界越来越模糊等等一系列矛盾,大家开始想要找到一个既可以互不影响迭代进度,又可以实现相互交互的一种模式,所以现在国际化中台开始尝试一些新的架构模型:sidecar、serverless等。
二. 中台集成
不管是中台集成还是中台被集成,中台其核心还是需要解决业务落地,从中台视角来看,需要解决以下一系列问题:
- 如何识别和透传流量的业务身份
- 如何做到数据隔离和资源隔离
- 中间件如何支持
- 中台的标准流程定义如何支持业务方的个性化扩展
- 如何与业务进行高性能、高容错的通讯交互
- 如何做到独立发布部署、与业务互不影响
- 有完善的产品和可视化平台
- 监控
- ……
为了实现以上目标,必须从下到上,从里到外的的一系列建设,包括:Iaas、中间件、框架、产品等。
1. 流量染色和路由
中台需要在同一领域支撑多个业务品牌,想要做到隔离性,那么就必须要对每一个品牌流入的流量进行染色,保证流量之间的安全隔离,这涉及到整个流量链路路由分支的选择,而且如果发生异常,可根据流量标进行溯源。
- 租户标识透传:确保从网关到DB层的全链路租户上下文一致
- 资源配额管控:根据染色标签实施差异化限流(如VIP租户QPS 1000,普通租户100)
- 故障爆炸半径控制:将问题流量快速隔离到特定泳道
- 灰度发布:按租户分组逐步放量新功能
- A/B测试:相同租户的不同用户群体走差异化逻辑
- 压测隔离:染色流量绕过监控计费系统
2. 流程引擎
中台需要在各个业务域中定义流程执行标准,例如 加购->下单->支付 ,默认情况下业务都会按照这个流程节点流转,但是有些业务需要对标准的业务流程制定个性化诉求,因为流程引擎必须保证在进行默认逻辑流转的情况下,可以允许业务方进行自定义节点定义,并且中台流程和个性化流程可以打通,实现水平+垂直流转。
- 不可变要素:
- 核心状态流转路径(如订单必须经过「创建→支付→履约」)
- 关键业务校验规则(如风控拦截点)
- 可扩展要素:
- 节点处理人规则(可替换为业务自定义角色体系)
- 非关键节点增删(如在售后流程中添加「质检」环节)
3. SPI
SPI的设定一方面是为了支持上述流程引擎水平+垂直的需求,也是为了中台可以根据染色的流量,配合SPI实现某些特定功能和业务的个性化实现。包括:
spi定义、spi实现、业务身份等核心概念
在满足用户使用场景的基础上,允许扩展多维度的隔离方式,包括地区、租户、产品、个性化场景等等
父子场景继承:对于父子场景的情况,Lattice支持的逻辑是:优先按照场景码寻址,若寻不到,则向上递归寻找父场景实现,实现:子继承父,父为子兜底的能力
兼容多模式调用:支持local调用、IPC调用、RPC调用
实现SPI级的监控运维。
4. 中台&业务间通讯
问题1:中台跟业务的能力边界是什么?
- 关键点在于如何在业务与中台的协同过程中,保证业务自主性,同时能够保持中台能力的可持续迭代,不额外增加协同成本;本质上需要做到关注点分离,平台需要提供稳定的能力以及稳定的扩展,业务具备基于业务场景灵活编排中台能力的机制,并具备开放二次扩展的机制,业务可以自主的决定对上层行业的开放能力设计,而不在受限于中台的扩展限制;—— 核心的考虑指标是业务自助率。
问题2:中台被集成的方式是什么?
- 在问题1被定义清楚之后,业务跟平台有了较清晰的边界,那么对于集成方式而言,可以选择jar包、镜像、sidecar、pod、独立应用等方式,需要结合实际考虑。
问题3:中台未来的交付形态是什么?
- 中台未来的交付形态,也一定程度上影响了业务集成的复杂度,业务研发除了代码开发外,还要维护整个应用/容器相关的内容,同时还需要感知因为部署架构复杂度带来了流量相关的复杂问题,所以中台除了交付稳定性较高的平台代码外,还需要解决业务容器运行时相关的问题。
如何实现
在梳理清楚现状和痛点并且确定了中台被集成的方向之后,接下来就是探索有哪些方式可以实现,以及每一个方式应当如何落地。
单纯对“中台能力供前台业务使用”这一诉求来说,可以实现的架构有很多种:
中台以jar包当时提供给前台业务(或反过来), classload 隔离。
中台以独立部署的sidecar容器的方式提供 IPC 服务给前台业务(或反过来),容器隔离。
中台以独立应用的方式提供 RPC 服务给前台业务(或反过来),机器隔离。
等…
可以实现这一诉求的方式有很多,但是我们要搞明白的是哪一种架构是前台业务能接受并且维护和理解成本最低的,哪一种架构是中台能力可复用并且可独立发布运维和版本管理的,又是哪一种架构是面对高并发的时候可以扛得住压力的。
从全局角度出发,不管哪一种部署架构必须是可以解决业务和中台耦合的问题以及冲突的问题;同时坚持中台能力可复用性的原则下实现业务的自主性。
- 隔离性:互不干扰,提高安全性和稳定性。
- 可复用性:业务集成,尽可能增加中台能力的复用性。
- 快速部署:业务方可以实现快速部署和快速启动,尽可能的不强依赖中台应用。
- 独立部署:如果可以实现业务方的独立部署,那么迭代效率将大幅提升。
- 独立监控:细粒度的监控,包括基础监控,中间件监控等。这也就表示业务同学和中台同学可以只对各自需要关注的容器进行告警和监控,也减少了业务同学的维护成本和排查问题的复杂度。
对于交互模式来说,要根据情况来定,包括安全性、性能、集成难度等等维度来确定,可以采用二方包集成、sidecar集成、以及serverless集成,你管哪一种方式,市场现在都已经有较为成熟的方案可以复用了。
三. 规划
基于上述的技术方案和发展历程,我们可以参考阿里国际中台的初步模式,采用「大中台、小前台」+「合作共建」的模式,将多点视为中台,种子视为前台,从存量功能或者从增量需求中选择一些模块和功能作为开始,从0打造一个样板间,采用「流量路由 + 流程引擎 + 个性化路由」的技术方案,实现一个轻量级的且业务可自主开发、迭代和维护的节奏目标。
1. 初期
初步的目标是打造样板间,建立标准
- 种子:
- 定义样板间包含哪些业务
- 个性化业务实现
- 多点:
- 流量染色✅(个人理解这个他们已经有了)
- 流程引擎+SPI路由(不确定他们有没有,但是我估计大概率也是已经有的)
- 支持种子的业务
- 合作共建:
- 不足基础能力
- 业务间的交互
- 前台独立发布的devops产品
从技术可行性来说,阿里国际已经做了大量落地,因此没有太大的阻塞点,但是需要和多点一起讨论和梳理还有哪些能力需要共建
从产品维度来说,在打造样板间期间,我理解暂时不需要有额外的产品建设,既保证快速轻量,也保证尽可能的复用多点现在的技术和产品,如果无法满足现有诉求,可以进行微量开发。
2. 中期
可以慢慢将种子的个性化业务都拆分出来到前台业务,简化和标准化多点作为中台角色的业务流程。