| 编辑推荐: |
本篇文章介绍了微服务架构与单体架构，,使用分布式架构实践举例--分布式TA系统，全面解析阿里技术中台的架构实践
。
本文来自于51CTO，由火龙果软件Alice编辑、推荐。 |
|
一、分布式架构的优势和理念
1.传统单体架构特点
通常一个初创型项目，都是从单体架构开始的。
优点就是快，易于开发、测试、部署，一个WAR包发上生产就完事了。
缺点也很明显，因为所有模块都在一个程序包里，导致编译慢、启动慢、代码冲突，每次合并代码的时候都是恶梦，发布成功率？完全靠运气。
2.微服务架构 vs 单体架构
复杂度较小时采用单体应用生产效率更高，复杂度到了一定规模时单体应用的生产效率开始急剧下降，这时对其进行服务化拆分才是合算的。
微服务架构之所以得到广泛认可，源于对业务多变性的不可预测，微服架构能够不断的自演化 ，进而快速适应业务变化。
3.模块化开发
微服务架构，从业务顶层设计开始，按照业务线进行模块拆分，从表现层、逻辑层、数据层进行独立的剥离单体应用。很多企业都经历过单体应用到服务化应用的拆分过程，这里要注意业务的连续性、数据的完整性问题。
4.微服务架构的负载均衡优势
以前通常用LVS、F5作为接入层的负载均衡服务，主要提供限流、负载、安全等等。
在微服务架构中，由网关作为接入层，提供轻量级的负载均衡、协议转换、鉴权等服务，微服务通常有服务治理框架，如DUBBO等，提供服务治理、服务注册、服务发现、隔离等。
5.数据访问瓶颈解决方案--数据库垂直切分
分布式架构是如何解决数据访问瓶颈的呢？首先是数据库的垂直切分，比如，按用户、交易、账务拆分到独立的数据库当中，缓解了数据存储和访问的压力，当然也可以做主备库，进行读写分离的。
6.数据访问瓶颈解决方案--数据库水平切分
其次，进行数据库的水平切分，比如交易数据库和数据表的数据量太大，可以按交易时间进行分表、分库，拆分表的数量计算方法见上图。
拆表拆库是解决数据访问、存储问题，但是会给数据查询带来很大的麻烦，比如跨多表、多库的复杂查询场景。解决的办法很多，通常有：用ES进行复杂查询，筛用ID再到库里捞数据（即复杂查询拆分多次查询），或用分布式海量数据库方案，不去做太细粒度的拆分库表，如下面会提到的OceanBase。
二、分布式架构实践举例--分布式TA系统
1.传统TA系统架构
传统TA系统架构，清算串行效率低，无法通过增加机器线性扩展性能，一般使用大事务，出现问题全部回滚。
2.分布式TA系统架构
分布式TA系统架构，结构更合理，也更复杂。分成了：接入层、业务服务层、SOFAStack层、LAAS、运维工具链、治理控制。
接入层：包括协议转换、访问控制、文件传输、运维工作台。
业务服务层：即业务核心逻辑服务，如：账户、交易、账单、清算等。
SOFAStack：蚂蚁金服的通用服务组件，许多都开源了，包括：微服务框架、分布式事务、任务调度、消息队列、数据代理、链路跟踪等。
分布式TA系统的需求攻克的技术难题。分布式清算任务如何高效实现？分布式下，加大应用处理出错可能性，那清算任务如何确保正确性?下面会谈谈如何解决。
3.分布式任务调度平台
分布式任务调度平台，支持：
自定义分片，高效利用集群计算能力。
执行中可对任务进行暂停/续跑，强制取消。
任务失败重试机制，保障整体计算任务成功。
4.清算任务调度
清算任务调度，整个架构分为：1）任务拆分，即申请交易文件，按一定的逻辑进行数据分片；2）任务执行，将执行处理过后的数据，存入流水库；3）核心服务，包括交易、清算、账务、账户等。
5.清算的容错和核对机制
清算的容错和核对机制，包含：日初始化、文件导入、清算处理、收益计算、份额调整、清算导出、二次清算、收益导出。
每个环节都可以冲正重做。
可以按文件、用户、备份点进行作业回滚。
优点是，任意流程可回滚、精准逐笔核对，支持按中台用户回滚，缩短了清算时长。
三、分布式架构下如何保障系统的可靠性及稳定性
1.灰度发布机制
灰度发布机制，流程包括：beta发布、分组发布、灰度引流、全量发布。
清算灰度，可以灵活的按用户维度抽取分片，缩短灰度时间。
2.线上全链路压测
线上全链路压测，通过数据访问代理，压测数据进入线上影子表，不影响正常业务数据，全链路压测特点有：
①.压测环境复用生产，结果可靠；优于线下。
②.压测数据打标无法进入生产环境，表级隔离。
3.OceanBase高可用机制
OceanBase高可用机制，基于Paxos协议的典型三副本部署：
1）数据强一致性；
2）持续可用；
3）主备自动切换；
4）单机、机房、城市级故障：不停服务，不丢数据；
OceanBase分布式数据库方案，优于商用数据库的主备库方案，主要体现在：分布式数据库，写事务到达超过半数库，少数库异常不影响业务，两地三中心多活，灰度升级。
4.OceanBase常用部署方案
OceanBase的部署方案有：
同城三机房，同城多个核心机房，相距30公里以内，延迟约在0.5~2ms之间；
两地三中心，正常情况下和同城三中心部署的延迟一致，其中一个城市的一台ObServer 宕机会增加异地同步延迟。
5.同城双活容灾架构
同城容灾双活架构，平时以主机房为主，承载日常交易，少量交易走备机房，架构特点是：
1）同机房优先，避免跨损耗
2）对应用无任何侵入
3）像单机房一样开发部署应用
4）容灾自动切换 |
