vlambda博客
学习文章列表

全文共5313字，阅读需要10分钟

Techo大会完美收官！！

什么？没能去现场怎么办？想知道分享内容是什么？

Techo大会全程回顾来啦！

注：发言仅代表讲师个人观点

在云原生场景下，微服务架构以其高度的弹性、灵活性和高效性，受到广大开发者们的青睐。在转型微服务架构的过程中，大家也都会有这样的思考：在架构转型初期，为什么选用微服务架构？

大家都会有一些实际的操作经验，以前在ATM转帐，后来经历了网上银行、手机银行，后面的银行系统，也就是今天绝大部分银行还在用的典型业务架构都是这样：请求首先上传到一个渠道层，进行信息的整合、过滤等。然后会到客户服务层，很多SOA在这个地方得以体现，再到更细的一些应用业务层。

后面则是各个比较独立的模块，比如说红色的就是典型的核心业务系统，最上面的三个：存款、贷款、支付结算是最核心的模块。下面是客户管理和其他的产品管理等，这是属于核心业务系统相关联的业务。一般来说，客户信息系统可以分成OLTP业务在线处理系统和OLAP数据分析系统。核心业务系统就是OLTP系统，随着大数据的持续发展，OLAP系统也显得越来越重要，价值越来越大。

以前重点是OLTP系统，现在我们把它简化一下，首先看一下OLTP一般的架构模型。很多互联网系统会把Gateway放在Nginx等后面，这里放在前面是因为银行的系统会有一个前置的网关去保护核心系统，所以我把Gateway简化了，可以看到这个请求从DNS Server发起解析之后，经过Load Balancer层到Web Server，把请求作为客户端的负载均衡发到业务层，然后再到DB Cache和DB，这是一个典型的OLTP的模型。

# 传统厂商像IBM怎么样做核心银行系统呢？

这里可以看一下刚才那个系统对标IBM产品是怎么样去实现的。这个的重点是AOR、TOR，他们是基于CICS交易中间件的服务实例，我们知道银行核心系统主要是处理交易，这里CICS AOR对标的是应用服务器，后面有CF来做缓存，再下面是Db2。

大家可以看一下最右边的HA标识，其实我们每一层都做了HA，在分布式架构里面非常强调两个特点就是服务冗余以及服务出现故障后的自动迁移，传统的集中式也非常注重这两大特点。只不过我们要理解它的不同点在哪儿，不同点在于IBM这套体系里面有一个前置条件：硬件是高可靠的，IBM以服务器、硬件设备专长，它的冗余服务，不光是体现在软件上面。比如当今基于X86的分布式集群，基本上觉得X86机器很容易坏，所以我们软件架构和负载需要有非常多的冗余服务。

在之前，IBM这套体系有硬件的可靠性加成，它的做法也是一样的道理。比如说CPU、内存、传输通道都有差不多20%的冗余设计，一旦一个地方出问题，可以马上启动备份硬件去接管。我觉得在IT系统本质后面的哲学理论是一样的，都是基于冗余服务和故障自动迁移。

这张图里面显示的是IBM一台大型主机的系统架构。但像工行、农行这些大银行系统是由四台这样的机器组成，每一台机器你可以想象成相当于冰箱大小，每个机器上划分两个或多个虚拟机，每个行都差不多这样。但不同点在于后面的TOR、AOR，也就是我们讲的应用服务器，它的业务逻辑层不一样，需要根据自己的业务来部署。其他的比如Db2和缓存CF都是一样的，而CF也很有特色，它是软硬件一体化，很多比如全局的帐单号可以通过这个生成，效率也非常高，这是IBM这套架构方案在传统银行做出来的核心银行系统。

很多基于Oracle或其他传统厂商的系统其实都大同小异，只不过产品换成了其他厂商系列，硬件能做到这个程度的厂商很少，因为供给少价格自然就贵。所以后来出现的分布式体系，可以叫商业上的降维打击，从另外一条路去改变IT世界的系统，把硬件重要性降低了。这里要注意这套系统的几个特点：水平拆分，应用是单体和数据集中存放，可以看到TOR方面扮演的是网关层作用，可以做鉴权、分发、组装等，后面AOR是真正处理业务的，再下面有缓存层、数据访问层到Db，它具备水平拆分的特点，但是应用仍然是单体的，数据是集中存放的。

接下来讲一下集中式跟分布式的特点比较，这一套体系很多银行觉得非常重要不愿意变动，但是这些产品也需要升级需要打补丁。这时候他们都会问能不能不打？如果打的话，能不能保持很多服务人员现场和在线支持，为什么这样呢？因为它的应用是单体，单体出现问题会引起全局性的问题，需要各方面的人来协同排查，负担非常重。所以这个东西对于IBM和客户来讲消耗都非常大。整个过程中如果打一百次只有一次有问题，但每一次都需要大量的人力物力投入，这对于所有人来说都是非常大的消耗，和我们为什么采用微服务是有很大的关系的。

# 那为什么要往微服务去转变呢？

微服务是可以自治的服务，是小团队可以开发、部署和演进的服务，很大程度能克服上述的问题。当然整个系统也不是一夜之间就进入到微服务，我们经历过水平拆分，还有SOA面向服务架构，很多人误认为SOA跟微服务很相似，其实它俩差别很大。SOA主要改造连接旧系统，而微服务往往是根据业务划分全新构建，需要把业务搞清楚并进行拆分，划分成服务之后再做实现。

微服务架构有几个非常火的词，叫Service Mesh（服务网格）和云原生架构，这几个都跟微服务有关系。Service Mesh是跨语言支持的微服务框架，是为了更好的实现业务，能够把服务通信和治理这些基础设施剥离出来，让用户专注于处理自己的业务逻辑，因此才有了Service Mesh服务网格。因为需要考虑微服务拆分之后怎么样更高效的部署？由此诞生了云原生架构。云原生架构更多是讲你的部署和运维的方式，整个是一套体系的。整个过程用了一张图是从红色到绿色，是渐变的过程，不是一个剧变的过程，是世界自然发展的过程。

# 我们看一下微服务架构模型是什么样子？

核心点在于它的服务跟自己的数据是自成一套体系，一个小的团队就可以运维。这是基于康威定理，一个组织结构什么样子，就决定了你的系统什么样子。所以涉及到微服务的架构改造，不光是架构模型的变化，更多是组织结构的变化。体现的特点在功能上是水平拆分，业务上是垂直拆分，数据是分布式存放。

接下来我们快速看一下集中式架构和分布式架构对比的特点，从对比的特点就能理解为什么这样演进？集中式架构是垂直扩展，举个简单的例子：IBM大型机，通过增加服务器CPU等硬件资源实现scale up。比如说原来1秒可以处理1万个需求，有了Scale-up之后，可以扩展为1万2，2万等，所以它是通过垂直扩展实现业务扩展。

这种把数据存放在一起是有自己的优势的，比如这些大银行背后的账务系统数据几十个T，不像分布式存到很多的服务器上面，它存放在一个集中的地方，所以数据的强一致容易保证。对于分布式系统，我们的开发模型是微服务，数据分散存放，更容易实现的是最终一致。

我觉得很有意思的一个现象是在和很多人讨论微服务架构的时候，其实没有人会关心硬件机器是什么，大家似乎都有同样的一个假设，这个机器就是x86 server这样，我们更多关注的是微服务架构本身怎么样从软件架构方面实现系统目标。当然这两个系统的区别和优劣势都已经很清楚了，单体肯定是比较慢的，已经不适合现在互联网应用快速发展和迭代的需要。

IBM也在做转型，它也是希望在云、云原生这套体系里面能够有很好的定位，能够支撑微服务，支撑客户的数据化改造。微服务分布式体系里面，当然代表着一些新的问题，比如服务拆分是非常难的一件事情，需要一定的经验。后续几位讲师会在这个方面里给大家更深入的探讨。还有数据一致性的问题，因为数据分开存放一定会导致数据一致性问题变得更加复杂。

接下来我们看一下微服务架构下的分布式事务的演化、分类与实现。因为时间太有限，所以我只能高度概括和大家过一下这一系列的话题，如果大家感兴趣的话，可以下去再深入研究一下，这块东西还是很有意思。

我们先看一下分布式事务或者数据一致性方案，主要分为刚性事务（数据强一致ACID），还有一种是柔性事务（数据最终一致BASE）。

# 刚性事务怎么样实现呢？

2PC，传统事务中间件CICS，Tuxedo和数据库DB2，Oracle，都是实现了2PC协议，后来还有3PC，还包括分布式多节点的Paxos。2PC主要是投票和提交两个阶段，但是存在阻塞和极端情况下状态不知道该提交还是回滚，按道理来讲，应该把2PC场景协议划出来，更清晰一些。因为时间有限，我只能概括一下通过故事的方式跟大家讲。

前面两个CICS和Tuxedo是IBM和Oracle最有名的事务处理中间件， 后面DB2和Oracle是作为事务参与方，他们都实现了XA协议。整个过程中因为有同步堵塞的问题，和对资源的锁定时间比较长，在以前系统里面，事务协调方与参与方因为协议指令问题导致的状态不确定，从2PC理论上是很难解决的，如果出现这个问题，一定会出现事务处于什么样的一个悬挂状态，这就是为什么银行有很多单子，有很多日志，极端情况下需要做人工的介入补偿。

但是这种Case比较少，每个系统都要去考虑做系统的投入产出比怎么样，如果这种Case特别少的情况下，是可以能够容忍2PC协议来处理事务交易方案。所以大批量的银行交易系统都还是基于2PC的，因为它很好的支撑了数据的强一致，银行最关心的是账务信息一定要实时一致。

后面的Paxos是分布式的数据库用的一些算法，包括ZAB，Raft都是Paxos改进的一些算法，性能优化，变得更快。

后面柔性事务，核心点是数据最终一致，就是那个Base理论，强调可用性，数据的一致性只强调最终一致就可以了，中间有一些软状态没有关系。这个柔性事务主要有TCC、SAGA、AT，也是一个不断优化和演进的过程，再往下是事务消息的方式来做，这些都用的比较多。

刚才讲了IBM支撑的交易处理系统，到今天互联网的分布式事务，补偿性柔性事务，本质上结构差别在于前面场景提交的事务是一个独立的服务，但这个服务里面涉及到多个DB参与方，你可以认为它是一个长事务，涉及到多个DB参与的长事务。但他本身做了很多优化，下面这类分布式事务的核心不同点在于它把这个长事务转化成一系列的本地事务。我这个服务就只关心自己的事务，我的数据一不一致，而整体的数据一不一致，我有别的补偿性事务框架，或者是消息中间件，通过它们来调度协调，以保证数据最终一致。

# 为什么像IBM这一类的事务处理中间件性能会非常高？

我刚才讲的IBM打造的银行核心系统，它的DB都放在DB2里，涉及到的事务参与方绝大多数都是一个resource manager，所以就做了一个优化，并没有真正按照2PC每个参与方都要走的流程，我先要应答一下回答我可不可以再决定回滚或提交，并没有很死板的走这个流程。它只有一个resource manager的话，就直接做操作了，如果有问题再去补偿。如果没有什么问题就是一个步骤。这个思想其实就是Saga思想。所以IBM很多产品中的思想都是很先进的。

对于柔性事务，我们先看一下TCC，然后再理解Saga。TCC架构模型中，事务管理器会申请开启一个事务，从事务协调器拿到一个全局XID，然后注册子交易。每个子交易要实现有三个接口Try和Commit/Cancel，我需要通过Try方法把资源预留下来，要看我的帐户可不可以正常使用，我的帐户里有多少钱。如果第一步各个子交易都预留了成功，就到confirm，如果某些预留失败就到Cancel执行回滚了。但是Confirm其实什么也没有干，只是一个确认的过程，Saga的作用就把刚才那一部分Try和Confirm进行优化，直接执行，如果有失败就向前重试或者整体向后回滚。

接下来我们看一看TCC和2PC是不是一回事，看起来它的思想高度一致，但实际上很不一样。

2PC的Prepare完全与这个业务逻辑没有关系，而TCC是有业务介入的，而Saga就是TCC的一个优化。Saga这种模式注意只能保证ACD不保证隔离性。Saga实现上又分协同式Saga和编排式Saga，还要注意幂等和空悬挂等问题。

最后，推荐大家在分布式事务实践上，注意考虑业务规避，尽量减少分布式事务场景，尽量使用BASE柔性事务，最后才是CP刚性事务。柔性事务通常推荐Saga或者异步消息处理。刚性事务通常推荐2PC实现，而且现实中也还有大批量的客户用2PC实现的系统，我们要怎样整合到微服务的框架里面，其实有很多要考虑的东西。基于时间的原因，我今天的分享就到这里。非常感谢大家，谢谢！

精彩内容未完待续，我们下期见！

#2021#

了解更多微服务、消息队列的相关信息！

解锁超多鹅厂周边！