分布式事务是这两年大家讨论比较多的话题，其实淘宝十多年前就开始使用分布式了。当时的淘宝网系统代码非常臃肿、业务解耦性高、开发效率低、功能上线周期长，业务方不满、开发人员不够就继续招人，但新来的人看不懂系统原有逻辑，只好摸索着在“合适的地方”加一些“合适的代码”，看看运行起来像那么回事后，就发布上线。常常是你改了商品相关的某些代码，发现交易出问题了，甚至你改了论坛上的某些代码，旺旺出问题了。这让开发人员苦不堪言，而业务方还认为开发人员办事不力。

并伴随着淘宝网访问量逐步上升，新兴功能和业务数据的不断增加，服务器的负载能力慢慢提高，不得不对系统进行肢解和重构，从而开启了分布式时代。将用户信息、交易、商品、评价这些模块拆分成具有不同业务特征的系统，从底层开始扩容，解决海量商品搜索、下单、支付、系统稳定性等问题。有助于每个系统独立部署，业务简单，方便扩容；有大量可重用的模块便于开发新的业务；能够做到专人专事，让技术人员更加专注于某一个领域......这些情况在银行核心系统中也不例外。

2016年7月15日银监会在官网发布的《中国银行业信息科技“十三五”发展规划监管指导意见》中也提到要“积极开展云计算架构规划，制定云计算标准，联合建立行业云平台，主动实施架构转型，稳步实施架构迁移，到“十三五”末期，面向互联网场景的主要信息系统尽可能迁移至云计算架构平台”。加上近年来以阿里为代表的互联网企业提出的“去IOE”，希望打破国外技术垄断的局面，以及移动互联网、大数据、云计算等新兴技术的迅速大致和广泛应用、业务量的迅速提升，当前IT技术架构面临极大压力和风险，在这种背景下，分布式架构受到越来越多的关注，应用范围逐步扩大。

1、此文适合人群

银行从业人员，IT架构师，系统分析师、开发工程师。

2、此文解决问题

对新人来说，学习完后对核心系统的分布式微服务有初步认识，对架构体系有新的理解，有助于扩展个人知识面；对职场人来说，银行业信息系统采用分布式架构是大势所趋，当浪潮来临，是不是只能all in？在第三部分，或许你能看到小编不一样的看法。

3、此文分为四大部分

一、分布式微服务概述

（1）微服务定义
（2）微服务的主要优缺点
（3）微服务总体架构体系
（4）分布式一致性
（5）数据一致性级别

二、分布式事务常用解决方案

（1）刚性事务
（2）柔性事务

三、没被掀开的面纱（个人看法）

四、快来评论区讨论（三个问题）

1、分布式微服务概述

（1）微服务定义

微服务是一种架构风格，将单体应用划分为一组小的服务，服务之间相互协作，实现业务功能；每个服务运行在独立的进程中，服务间采用轻量级的通信机制协作（RPC）；每个服务围绕业务能力进行构建，并且能够通过自动化机制独立地部署（CI/CD）；服务可以使用不同的语言进行开发，使用不同的存储方式。

如上图，我们需要开发一款简单的订单应用，我们将产品、订单、客户等所有应用模块全部打包在一个系统中，它提供了应用所有功能。尽管是模块化的架构，但应用程序被作为一个整体进行打包和部署，很可能出现一个功能故障影响整个应用、应用模块越大则单个应用启用时间越长、代码功能耦合高不易维护、或代码资源修改冲突的问题。那么就引入了微服务....

微服务是基于业务进行拆分的，至于拆分多小没有一个固定的标准，这点也一直是个争论的话题。因为服务进行拆分之后，粒度比较细，那么程序构建和部署方面就会变得简单。

常见做法是由技术人员对应用模块的功能挨个进行拆分，包括交易检查、功能检查、逻辑判断等挨个列出清单转至业务部门，在由业务部门拼接进行开发。就像核心系统中的“乐高”积木，借助简单的页面/接口，通过选择预先设计的业务元素（如密码检查、节假日检查、黑名单客户检查）并结合业务需求，灵活、直观、快速的搭配，构建创新性的金融服务。

所以，与其说微服务是一种系统设计思想，不如说是对原来工程实践的一种总结和组合。

小白科普
RPC（Remote Procedure Call）：指远程过程调用，是一种进程间通信方式，是一种技术思想，而不是规范，它允许程序调用另一个地址空间（通常是共享网络的另一台机器上）的过程或函数。对程序员来说，无论是调用本地的还是远程的函数，本质上编写的调用代码基本相同。
本地过程调用&远程过程调用：本地过程调用就好比你现在在家里，想要扫地，那你直接打开扫地机器人开关就可以了；远程过程调用就好比你现在不在家，家里有客人要来，打个电话叫家人赶紧打扫下卫生。
容器：简单的说，可以理解为每个运行时的服务，便于系统对若干服务间的管理。

（2）微服务的主要优缺点

优点：

1.解耦了业务复杂度，服务能够聚焦一个指定的业务功能或业务需求；
2.强模块化边界，对其他服务依赖性弱；
3.可独立部署，独立升级，团队新成员不用很深入别人的代码也能够很快投入生产；
4.技术多样性，能使用不同的语言开发，如Java、Python、PHP、C#等。

缺点：

1.分布式系统复杂性，要考虑网络延迟、异步、序列化、负载等，难以管理；
2.分布式一致性，银行系统相比互联网公司，对账户资金要求更高；
3.运维复杂性，要保证系统成千上万的服务有效运转，成本开销大；
4.测试复杂性，测试需要启动和它有关的所有服务。

（3）微服务总体架构体系

总体架构在逻辑上划分为接入层、网关层、业务服务层、支撑服务层、平台服务层和基础设施层。

基础设施层：是系统运行的必要条件，原子交易，经过聚合服务整合后有一整套交易能力。

平台服务层：主要用来保证系统的平稳运行，根据实际业务情况合理分配资源及发布系统。

支撑服务层：实根据业务需要给系统提供高质量的服务，与开放平台的流程管理系统类似。

业务服务层：可以分为聚合服务和基础服务。聚合服务是不同的基础服务聚合在一起，完成复杂的业务处理；基础服务是单一的业务处理。

网关层：网关层是接受外部流量的屏障，用于保证系统的安全和稳定，如黑名单过滤、安全认证等。

接入层：是通过负载均衡接入请求到内部平台。

（4）分布式一致性

数据一致性简单的说，就是对一个副本数据进行更新的时候，必须确保也能够更新其他的副本，否则不同副本之间的数据将不一致。举个例子，比如用户A向用户B转100元，那么用户A的账户减100元，用户B的账户就一定要增加100元，金额多了或是少了都不对，就出现了数据不一致的情况。

微服务化之前：业务采用本地事务，多个本地SQL调用可以用一个大的事务块封装起来，如果某一个数据库操作发生异常，就可以将之前的SQL操作进行回滚，只有所有SQL操作全部成功，才最终提交，这就保证了事务强一致性。

微服务化之后：多个数据库操作可能被拆分到多个独立的数据库中，此时原来的本地SQL调用演变成了 远程服务调用，事务一致性无法得到保证。

（5）数据一致性级别

数据一致性级别一般分为三类，强一致性、弱一致性和最终一致性。

·强一致性：也称为刚性事务，本身就支持ACID，所以不会存在数据不一致的问题。也是最符合用户直觉的，它要求系统写入什么，读出来的也会是什么，用户体验好，但实现起来往往对系统的性能影响大。比如网银系统涉及的金融交易，所以交易数据都必须符合核心系统的对账。

·弱一致性：也称为柔性事务，与强一致性相反，这种一致性级别约束了系统在写入成功后，不承诺立即可以读到写入的值，也不承诺多久之后数据能够达到一致，但会尽可能地保证到某个时间级别（比如秒级别）后，数据能够达到一致状态。

·最终一致性：是弱一致性的一个特例，系统会保证在一定时间内，能够达到一个数据一致性。它是弱一致性中非常推崇的一种一致性模型，也是业界在大型分布式系统的数据一致性上比较推崇的模型。在技术上实现难度不高，一般借助异步消息机制实现，基于网络正常且系统交易平稳前提下，可以接近同步效果，客户体验也好。

银行核心系统与互联网有很大不同，以保证事务一致性为先，而分布式一致性正是微服务架构下一个比较大的弊端。因为直接涉及到客户账户金额的变动，一是客户不能容忍，二是银行每秒都有成百上千笔业务，所以一旦出现数据一致性问题，后果不堪设想。

2、分布式事务常用解决方案

关于分布式事务中的一些基本概念，我们先回顾下。

◇事务：由一组操作构成的可靠、独立的工作单元。

◇事务的特性ACID

Atomicity（原子性）：事务作为整体来执行，要么全部执行，要么全部执行。
Consistency（一致性）：事务应确保数据从一个一致的状态转变为另一个一致的状态。
Isolation（隔离线）：多个事务并发执行时，一个事务的执行不应影响其他事务的执行。
Durability（持久性）：已提交的事务修改数据会被持久保存。

◇本地事务：事务由资源管理器（如RDMS）本地管理。

优点：

1.支持ACID属性；
2.可靠且高效；
3.状态可以只在资源管理器中维护；
4.应用编程模型简单。

缺点:

1.不具备分布式处理能力；
2.隔离的最小单位由资源管理器决定，如单笔记录。

◇全局事务（DTP模型）-标志分布式事务

大家应该都听过两阶段提交，其实两阶段提交是X/Open这个组织发布的DTP模型来定义的一个协议，主要定义规范和API接口，由厂商进行具体的实现。不过一般很少采用两阶段提交实现分布式事务实现。

◇两阶段提交（Two Phase Commit）

准备操作与ACID：

·A：准备后，仍可提交与回滚，主要是确认能否执行提交操作并分配资源、加锁...
·C：准备时，操作者发送响应，一致性检查必须ok
·I：准备后，事务结果仍然只在事务内可见
·D：准备后，事务结果已经持久，即准备好提交

缺点：

1.协议成本（长时间资源占用），比如有多个资源管理器，必须等到所有资源管理器准备完成后才统一发起提交；
2.准备阶段的持久成本
3.全局事务状态的持久成本
4.潜在故障点多带来的脆弱性
5.准备后，提交前的故障引发一些列隔离与恢复难题

◇JavaEE平台中的分布式事务实现

与两阶段提交类似，是针对上层应用实现分布式事务的协议。

◇标准分布式事务解决方案的利弊

优点是严格的ACID；

缺点是效率非常低（微服务架构下已不太使用）。

（1）刚性事务

◇CAP定理

一致性（C）

指数据在多个副本之间是否能够保持一致的特征。当执行数据更新操作后，仍然可以保证系统数据处于一致的状态。

可用性（A）

系统提供的服务必须一直处理可用的状态。对于用户的每一个操作请求总是能够在“有限时间内”返回结果。这个有限时间是系统涉及之初就指定好的系统运行指标。返回的结果指的是系统返回用户的一个正常相应结果，而不是“out ot memory error”之类的系统错误信息。

分区容错性（P）

分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性服务，除非是整个网络环境都发生了故障。组成分布式系统的每个节点的加入与退出都可以看成是一个特殊的网络分区。简单的说就是：系统部分节点出现故障后，连接正常节点还可以使用系统提供的服务。

CP：放弃可用性，追求一致性和分区容错性，基本不会选择，网络问题会直接让整个系统不可用。

AP：放弃一致性（这里说的一致性是强一致性），追求分区容错性和可用性，这是很多分布式系统设计时的选择，例如很多NoSQL系统就是如此。

CA：放弃分区容错性，加强一致性和可用性，其实就是传统单机数据库的选择。

结论：分布式系统，最重要的是满足业务需求，而不是追求抽象、决定的系统特性。由于网络分区是分布式应用的基本要素，由此开发者需要在C和A上做出平衡。

◇BASE理论

BASE是基于CAP定义演化而来，是对CAP中一致性和可用性权衡的结果。

BASE就是为了解决关系型数据库强一致性引起的问题而引发的可用性降低，而提出的解决方案。

BA：Basic Availability 基本业务可用性（支持分区失败）

S：Soft state 柔性状态（状态允许有短时间不同步，异步）

E：Eventual consistency 最终一致性（最终数据是一致的，但不是实时一致）

原子性（A）与持久性（D）必须根本保障

为了可用性、性能的需要，只有降低一致性（C）与隔离性（I）的要求。

（2）柔性事务

柔性事物可以分为四大类，两阶段型、补偿性、异步确保型和最大努力通知型。理解这四种类型，有助于在实际业务场景中我们进行分析，哪些场景和业务更适合用哪种分布式事务解决方案。业务活动举例如下：

由上图我们可以看到，两阶段型是分布式环境下事务处理的典型模型，比如处理红包、更新客户账、收费处理等；异步确保型主要是异步处理事务，比如核心系统中的热点账户异步记账、核算分离、虚实账户余额更新等，可以理解为与交易无直接关系，但必须要做的动作；最大努力通知型主要是通知的处理，比如有银行账户动账短信通知、理财产品提前到期通知、商户通知、对账文件等。

◇柔性事务中的服务模式

◇TCC操作

TCC是一种业务模型，位于业务服务层而非资源层，没有单独的准备阶段，Try操作更灵活且业务是可控的，但是开发成本比较高。TCC操作可以分为3个部分，如下：

1.Try：尝试执行业务

·完成所有业务检查（一致性）

·预留必须业务资源（准隔离性）

2.Confirm:确认执行任务

·真正执行业务

·不作任何业务检查

·只使用Try阶段预留的业务

·Confirm操作要满足幂等性

3.Cancel:取消执行业务

·释放Try阶段预留的业务资源

·Cancel操作要满足幂等性

◇柔性事务解决方案：TCC（两阶段型、补偿型）

实现

·一个完整的业务活动由一个主业务服务与若干从业务服务组成

·主业务服务负责发起并完成整个业务活动

·从业务服务提供TCC型业务操作

·业务活动管理器控制业务活动的一致性，它登记业务活动中的操作，并在业务活动提交时确认所有的TCC型操作的confirm操作，在业务活动取消时调用所有TCC型操作的cancel操作

成本

·实现TCC操作的成果

·业务活动结束时confirm或cancel操作的执行成本

·业务活动日志成本

使用范围

·强隔离性、严格一致性要求的业务活动

·适用于执行时间较短的业务（如处理账户、收费等业务）

TCC的案例比如银行转账会用到；可靠消息最终一致性（异步确定型），案例可以参考支付宝、eBay；最大努力通知（定期校对），案例可以银行通知、商户通知等，目前也还在学习之中，就先说到这里，有机会的话在拿案例做演示。

总的来说，分布式事务常用解决方案分刚性事务和柔性事务。刚性事务一般不适用于微服务场景的，基于CAP定理和BASE理论衍生出柔性事务，柔性事物又分为TCC（典型场景有转账）、可靠消息最终一致（可以理解为基于提高性能的前提下，异步处理的交易对本次交易没有决定性作用的转异步处理，但必须可靠。案例可以参考支付宝、eBay）、最大努力通知（典型案例有银行短信通知）。实际场景方案方面业余时间在了解中，有机会的话在拿案例做演示，就先说到这里。

3 、没被掀开的面纱（个人看法）

银行核心系统分布式微服务建设之于大众，仍然像性之于少年，很多人都在谈论，但大部分不是真的懂。总之，不管是一个怎样的浪潮，要all in，还是要先看明白些好。若有不妥之处，还请指正。

对于传统小银行、民营银行的现状来说，没有必要使用分布式微服务。首先，科技创新是一项巨大的成本投入，对人力、财力、机器采购、运维方面要求都高，比如对核心各应用模块的系统进行拆分，可以拆出上千个交易，虽然交易粒度变小了，但是从交易整体的跨网络传输上来看，交易效率不一定会提示。

其次，小行科技部门相对投入少，话语权不多，加上核心系统不像互联网公司能完全划分业务和技术，反而考虑更多的是业务和使用场景以及金融业务的游戏规则，所以采用分布式微服务风险较大。但如果行里研发能力强，可以根据实力情况进行微服务处理，对非核心系统进行一些重构和优化。

最后，分布式架构因为应该全行系统统一考虑，而不针对其中一个系统，因为核心与外围系统之间、或是核心系统各个业务间，联系都非常紧密。如果核心系统实现分布式微服务，但外围系统设计还是传统思路，那么就需要一个公共平台将服务给串接起来。想到了ESB，但从设计维护角度来看，仅是配置项就会让人手忙脚乱，清理各系统之间的调用关系更复杂。

总的来说，个人觉得银行核心系统进行分布式改造没有太大必要，当数据或交易量到达一定程度才需要考虑系统架构，量小的话可以增加内存、CPU、机器等方式来解决问题。不过话说回来，金融互联网是趋势，从长远的角度来看，传统银行的研发模式一定会拖后腿，日子会不太好过，这是危机也是机会。所以，我们主张面对互联网的挑战，找准新形势下新一代核心系统架构的重点，结合实际用处进行理性的选择、谨慎地规划。

4、快来评论区讨论（三个问题）

莎士比亚说过，一千个读者,就有一千个哈姆雷特。不同的人阅读文章或是对同一个问题，往往有着不同的感悟与理解，所以借此机会抛出同行的三个问题，和大家讨论一下分布式架构、微服务化。

1）银行系统的客户终端实际上是往操作简单，服务全面方向发展，比如综合开户，一键提交、生成客户资料、开银行账户、存钱全一次性完成，而且必须保证事务一致性，那么系统设计如果微服务化后，银行整架构中由谁负责串接是最合适的？

2）分布式事务是怎么样保证预提交后的正式提交一定全部成功？ 如果预提交都通过后，正式提交出错了应该如何处理？

3）我们都知道银行系统即使对单一数据库资源的访问都很难完全避免死锁的情况发生，在分布式事务的隔离性描述里提到是在预提交时加锁，一直到事务执行结束才释放锁，我觉的在同样的一个复杂业务，分布式事务的加锁时间一定比单一事务的加锁时间长，发生锁等待的概率也更大，在这个方面分布式架构是否有相应技术解决这个问题？

快来评论区说说吧~

**本文原作者：代堂鸣
转自作者个人公众号：小代嘚吧嘚**