阿里专家讲中台：技术中台-分布式架构在蚂蚁金服的实践

来源| 阿里云峰会

文| 技术领导力社区

本文整理自，阿里高级技术专家-许文奇在2019阿里云峰会上的分享《技术中台-分布式架构在蚂蚁金服的实践》，结合技术领导力社区架构专家的点评和解读，全面解析阿里技术中台的架构实践。

一、分布式架构的优势和理念

01

传统单体架构特点

（本文图片来源：阿里云峰会 版权归作者）

通常一个初创型项目，都是从单体架构开始的。

优点就是快，易于开发、测试、部署，一个WAR包发上生产就完事了。

缺点也很明显，因为所有模块都在一个程序包里，导致编译慢、启动慢、代码冲突，每次合并代码的时候都是恶梦，发布成功率？完全靠运气。

02

微服务架构 vs 单体架构

（点击图片放大）

复杂度较小时采用单体应用生产效率更高，复杂度到了一定规模时单体应用的生产效率开始急剧下降，这时对其进行服务化拆分才是合算的。

微服务架构之所以得到广泛认可，源于对业务多变性的不可预测，微服架构能够不断的自演化 ，进而快速适应业务变化。

03

模块化开发

微服务架构，从业务顶层设计开始，按照业务线进行模块拆分，从表现层、逻辑层、数据层进行独立的剥离单体应用。很多企业都经历过单体应用到服务化应用的拆分过程，这里要注意业务的连续性、数据的完整性问题。

04

微服务架构的负载均衡优势

以前通常用LVS、F5作为接入层的负载均衡服务，主要提供限流、负载、安全等等。

在微服务架构中，由网关作为接入层，提供轻量级的负载均衡、协议转换、鉴权等服务，微服务通常有服务治理框架，如DUBBO等，提供服务治理、服务注册、服务发现、隔离等。

05

数据访问瓶颈解决方案--数据库垂直切分

分布式架构是如何解决数据访问瓶颈的呢？首先是数据库的垂直切分，比如，按用户、交易、账务拆分到独立的数据库当中，缓解了数据存储和访问的压力，当然也可以做主备库，进行读写分离的。

06

数据访问瓶颈解决方案--数据库水平切分

其次，进行数据库的水平切分，比如交易数据库和数据表的数据量太大，可以按交易时间进行分表、分库，拆分表的数量计算方法见上图。

拆表拆库是解决数据访问、存储问题，但是会给数据查询带来很大麻烦，比如跨多表、多库的复杂查询场景。解决的办法很多，通常有：用ES进行复杂查询，筛用ID再到库里捞数据（即复杂查询拆分多次查询），或用分布式海量数据库方案，不去做太细粒度的拆分库表，如下面会提到的OceanBase。

二、分布式架构实践举例--分布式TA系统

07

传统TA系统架构

传统TA系统架构，清算串行效率低，无法通过增加机器线性扩展性能，一般使用大事务，出现问题全部回滚。

08

分布式TA系统架构

分布式TA系统架构，结构更合理，也更复杂。分成了：接入层、业务服务层、SOFAStack层、LAAS、运维工具链、治理控制。

接入层：包括协议转换、访问控制、文件传输、运维工作台。

业务服务层：即业务核心逻辑服务，如：账户、交易、账单、清算等。

SOFAStack：蚂蚁金服的通用服务组件，许多都开源了，包括：微服务框架、分布式事务、任务调度、消息队列、数据代理、链路跟踪等。

分布式TA系统的需求攻克的技术难题。分布式清算任务如何高效实现？分布式下，加大应用处理出错可能性，那清算任务如何确保正确性?下面会谈谈如何解决。

09

分布式任务调度平台

分布式任务调度平台，支持：

自定义分片，高效利用集群计算能力。

执行中可对任务进行暂停/续跑，强制取消。

任务失败重试机制，保障整体计算任务成功。

10

清算任务调度

清算任务调度，整个架构分为：1）任务拆分，即申请交易文件，按一定的逻辑进行数据分片；2）任务执行，将执行处理过后的数据，存入流水库；3）核心服务，包括交易、清算、账务、账户等。

11

清算的容错和核对机制

清算的容错和核对机制，包含：日初始化、文件导入、清算处理、收益计算、份额调整、清算导出、二次清算、收益导出。

每个环节都可以冲正重做。

可以按文件、用户、备份点进行作业回滚。

优点是，任意流程可回滚、精准逐笔核对，支持按中台用户回滚，缩短了清算时长。

三、分布式架构下如何保障系统的可靠性及稳定性

02

灰度发布机制

灰度发布机制，流程包括：beta发布、分组发布、灰度引流、全量发布。

清算灰度，可以灵活的按用户维度抽取分片，缩短灰度时间。

13

线上全链路压测

线上全链路压测，通过数据访问代理，压测数据进入线上影子表，不影响正常业务数据，全链路压测特点有：

1、压测环境复用生产，结果可靠；优于线下。

2、压测数据打标无法进入生产环境，表级隔离。

14

OceanBase高可用机制

OceanBase高可用机制，基于Paxos协议的典型三副本部署：

1）数据强一致性；

2）持续可用；

3）主备自动切换；

4）单机、机房、城市级故障：不停服务，不丢数据；

OceanBase分布式数据库方案，优于商用数据库的主备库方案，主要体现在：分布式数据库，写事务到达超过半数库，少数库异常不影响业务，两地三中心多活，灰度升级。

15

OceanBase常用部署方案

OceanBase的部署方案有：

同城三机房，同城多个核心机房，相距30公里以内，延迟约在0.5~2ms之间；

两地三中心，正常情况下和同城三中心部署的延迟一致，其中一个城市的一台ObServer 宕机会增加异地同步延迟。

16

同城双活容灾架构

同城容灾双活架构，平时以主机房为主，承载日常交易，少量交易走备机房，架构特点是：

1）同机房优先，避免跨损耗

2）对应用无任何侵入

3）像单机房一样开发部署应用

4）容灾自动切换

特别推荐一个分享架构+算法的优质内容，还没关注的小伙伴，可以长按关注一下：
长按订阅更多精彩▼
如有收获，点个在看，诚挚感谢