银行核心系统之分布式微服务.pdf

银行核心系统之分布式微服务 分布式事务是这两年大家讨论比较多的话题，其实淘宝十多年前就开始使用分布式了。当时 的淘宝网系统代码非常臃肿、业务解耦性高、开发效率低、功能上线周期长，业务方不满、 开发人员不够就继续招人，但新来的人看不懂系统原有逻辑，只好摸索着在 “合适的地方” 加一些 “合适的代码”，看看运行起来像那么回事后，就发布上线。常常是你改了商品相关 的某些代码，发现交易出问题了，甚至你改了论坛上的某些代码，旺旺出问题了。这让开发 人员苦不堪言，而业务方还认为开发人员办事不力。 并伴随着淘宝网访问量逐步上升，新兴功能和业务数据的不断增加，服务器的负载能力慢慢 提高，不得不对系统进行肢解和重构，从而开启了分布式时代。将用户信息、交易、商品、 评价这些模块拆分成具有不同业务特征的系统，从底层开始扩容，解决海量商品搜索、下 单、支付、系统稳定性等问题。有助于每个系统独立部署，业务简单，方便扩容；有大量可 重用的模块便于开发新的业务；能够做到专人专事，让技术人员更加专注于某一个领域 这些情况在银行核心系统中也不例外。 2016 年 7 月 15 日银监会在官网发布的《中国银行业信息科技 “十三五”发展规划监管指 导意见》中也提到要 “积极开展云计算架构规划，制定云计算标准，联合建立行业云平台， 主动实施架构转型，稳步实施架构迁移，到 “十三五”末期，面向互联网场景的主要信息系 统尽可能迁移至云计算架构平台”。加上近年来以阿里为代表的互联网企业提出的 “去 IOE”，希望打破国外技术垄断的局面，以及移动互联网、大数据、云计算等新兴技术的迅 速大致和广泛应用、业务量的迅速提升，当前 IT 技术架构面临极大压力和风险，在这种背 景下，分布式架构受到越来越多的关注，应用范围逐步扩大。 1、此文适合人群 银行从业人员，IT 架构师，系统分析师、开发工程师。 2、此文解决问题 对新人来说，学习完后对核心系统的分布式微服务有初步认识，对架构体系有新的理解，有 助于扩展个人知识面；对职场人来说，银行业信息系统采用分布式架构是大势所趋，当浪潮 来临，是不是只能 all in？在第三部分，或许你能看到小编不一样的看法。 3、此文分为四大部分 一、分布式微服务概述 （1）微服务定义 （2）微服务的主要优缺点 （3）微服务总体架构体系 （4）分布式一致性 （5）数据一致性级别 二、分布式事务常用解决方案 （1）刚性事务 （2）柔性事务 三、没被掀开的面纱（个人看法） 四、快来评论区讨论（三个问题） 1、分布式微服务概述 （1）微服务定义 微服务是一种架构风格，将单体应用划分为一组小的服务，服务之间相互协作，实现业务功 能；每个服务运行在独立的进程中，服务间采用轻量级的通信机制协作（RPC）；每个服务 围绕业务能力进行构建，并且能够通过自动化机制独立地部署（CI/CD）；服务可以使用不 同的语言进行开发，使用不同的存储方式。 8j1vlamwui 如上图，我们需要开发一款简单的订单应用，我们将产品、订单、客户等所有应用模块全部 打包在一个系统中，它提供了应用所有功能。尽管是模块化的架构，但应用程序被作为一个 整体进行打包和部署，很可能出现一个功能故障影响整个应用、应用模块越大则单个应用启 用时间越长、代码功能耦合高不易维护、或代码资源修改冲突的问题。那么就引入了微服 务 微服务是基于业务进行拆分的，至于拆分多小没有一个固定的标准，这点也一直是个争论的 话题。因为服务进行拆分之后，粒度比较细，那么程序构建和部署方面就会变得简单。 常见做法是由技术人员对应用模块的功能挨个进行拆分，包括交易检查、功能检查、逻辑判 断等挨个列出清单转至业务部门，在由业务部门拼接进行开发。就像核心系统中的 “乐高” 积木，借助简单的页面/接口，通过选择预先设计的业务元素（如密码检查、节假日检查、 黑名单客户检查）并结合业务需求，灵活、直观、快速的搭配，构建创新性的金融服务。 s4k1z977pte 所以，与其说微服务是一种系统设计思想，不如说是对原来工程实践的一种总结和组合。 小白科普 RPC （Remote Procedure Call）：指远程过程调用，是一种进程间通信方式，是一种技术 思想，而不是规范，它允许程序调用另一个地址空间（通常是共享网络的另一台机器上）的 过程或函数。对程序员来说，无论是调用本地的还是远程的函数，本质上编写的调用代码