cq9电子游戏app：银行核心系统之微服务

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

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

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

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

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

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

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

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

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

　　事务的特性ACIDAtomicity（原子性）：事务作为整体来执行，要么全部执行，要么全部执行。

　　Consistency（一致性）：事务应确保数据从一个一致的状态转变为另一个一致的状态。

　　Isolation（隔离线）：多个事务并发执行时，一个事务的执行不应影响其他事务的执行。

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

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

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

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

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

　　D）必须根本保障为了可用性、性能的需要，只有降低一致性（C）与隔离性（I）的要求。

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

　　实现一个完整的业务活动由一个主业务服务与若干从业务服务组成主业务服务负责发起并完成整个业务活动

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

　　3没被掀开的面纱（个人看法）银行核心系统分布式微服务建设之于大众，仍然像性之于少年，很多人都在谈论，但大部分不是真的懂。总之，不管是一个怎样的浪潮，要all in，还是要先看明白些好。若有不妥之处，还请指正。对于传统小银行、民营银行的现状来说，没有必要使用分布式微服务。首先，科技创新是一项巨大的成本投入，对人力、财力、机器采购、运维方面要求都高，比如对核心各应用模块的系统进行拆分，可以拆出上千个交易，虽然交易粒度变小了，但是从交易整体的跨网络传输上来看，交易效率不一定会提示。

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

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

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

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

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

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