项目背景及目标

20 世 纪 90 年 代 末 ，面 向 服 务 架 构（Service Oriented Architecture，SOA）概念被提出，在近 20年的企业信息化建设过程中，研发者进行了大量的面向服务的架构实践，从企业应用集成（EAI）的推出逐步到企业服务总线（ESB）的流行。然而，复杂的 ESB企业服务总线在中小金融机构中依然处于重要的位置，整个系统的架构并没有实现完全的组件化以及面向服务。伴随着移动互联网技术的快速发展，企业在提升客户体验、快速升级迭代业务上面临越来越大的压力。

在此背景下微服务架构的概念被提出，尤其是金融科技企业出现将应用系统迁移到微服务架构下的趋势，本课题基于中小金融机构面临的痛点问题，借鉴微服务架构理念进行探索与研究，以期为中小金融机构提供一条可行的微服务架构转型实践方案。

现有银行组织过程资产体系下，如何建设微服务模式的IT基础架构。用银行现有的技术手段对微服务模式进行实现，做好既有服务的融合和新服务的接入。从银行的角度来说，银行系统经历了多年的发展，系统组成复杂。如何能保证原有系统提供的接口服务可用的前提下，实现微服务架构的灵活，要比单纯建立一套基于微服务的互联网引用更为困难。

项目方案

中小银行在人力有限的情况下选择使用微服务架构其实目的在于，在微服务架构的基础上快速进行应用的开发。以应对市场的变化，完成业务的快速部署上线。在满足安全的前提下进行屏蔽开发端的安全问题。复用银行在多年建设过程中所产生的组织过程资产。这也是我们建立微服务架构体系交易系统的初衷。

我们实践课题的过程中，针对微服务流行的互联网架构和银行应用特点进行了比较。发现如果照搬互联网的解决方案，会存在一些风险：

首先基于互联网的微服务架构多基于Web和Web容器，对于银行业务的适应性有欠缺。

其次服务间通信安全和互信机制没有很好的体现出来。

后因为基于Web和Web容器，所以很多系统架构的通讯方式其实是RESTful的。因此依赖于JAX-RS 2.0的Java规范。所以与语言无关性这一点很难实现。下面针对上面提到的问题进行展开的描述。

微服务架构本身也带来了一些问题，比如微服务的一个主要缺点是微服务的分布式特点带来的复杂性。开发人员需要基于RESTful和RPC实现微服务之间的调用和通信，而这就使得服务之间的发现、服务调用链的跟踪和质量问题变得的相当棘手。因为银行本身体系内的应用程序，形成于不同的开发团队、历史时期和应用语言。所以如果没办法对这些服务程序提供一套完整的工具链条，如何有效的让为银行服务的外包公司融入到这一架构体系内这个问题本身就可以让银行放弃微服务架构。所以如果基于现有ESB的体系处理这个问题就很好解决了。首先外包公司都与现在运行的ESB进行通讯，所以通讯的问题迎刃而解。其次ESB在服务于通讯的同时可以为服务进行路由，降低服务间调用的复杂度，服务的调用链条统一由路由应用进行处理。后ESB的工具成熟，从开发到调试，部署运维都有很成熟。大大减轻了架构变迁的成本。

部署基于微服务的应用也要复杂得多。单体应用可以简单的部署在一组相同的服务器上，然后前端使用负载均衡即可。每个应用都有相同的基础服务地址，例如数据库和消息队列。而微服务由不同的大量服务构成。每种服务可能拥有自己的配置、应用实例数量以及基础服务地址。这里就需要不同的配置、部署、扩展和监控组件。在这一点上成熟的商用ESB天生已经避免了很多问题，现行系统的部署和维护经验可以很好的避免微服务化后所面临的服务批量化地狱。

项目创新点

依托于现有的ESB架构体系，建立微服务系统体系是甘肃农信受理渠道与后端系统的枢纽，提供了交易校验、协议转换、数据转换以及集中授权控制等通用功能。既可以降低改造成本，又实现了微服务的架构优势。本项目属于优化改造范畴，基于后端服务的复用和流程化的服务编排的思想，改造现有程序。系统主要分为一下几个部分：

路由引擎：是应用服务体系中各交易的枢纽、体系的核心。所有渠道的服务请求报文以及所有同三方交互的报文都要经过路由引擎，网关对相应的服务请求进行接收、解析，并根据规则分发至目的服务端，并可实现服务的全生命周期管理。

数据转换引擎：在微服务框架基于ESB的方式进行实现后，对于互联网应用的请求端屏蔽了很多交易的报文细节，但是原系统中有多种报文格式。为实现这些服务间的复用设计了数据报文转换引擎，基于XSLT加工处理，统一放到XSLT中进行转换。

服务间安全：在使用微服务进行服务拆分后如何解决服务间调用安全问题也是本课题需要解决的问题。我们实现了服务间通过安全密钥中心进行非对称密钥校验的技术方案。以保证服务间的信任。

技术实现特点

充分利用银行的组织过程资产，针对农村金融机构的系统建设特点进行设计实施。保证现有系统兼容性的同时对敏捷开发提供了基础环境。

本套系统基于现有的ESB系统，因此在项目实施过程中技术爬坡平缓。规避了新项目实施过程中的技术风险。并且不需要全部从写所有的服务代码，避免了投入过多的开发地狱。

项目过程管理

2018年1月 – 2018年3月

系统架构研究和梳理，终确定系统架构。考察国内的主流平台架构，在研究过程中针对现实问题在新架构中确定实现模型，以现有信息作为输入进行桌面推演。 对确定的系统架构，以现有复杂系统的业务流程下进行桌面推演，根据推演结果搭建一套基础架构。

2018年3月 – 2018年7月

对现有系统进行梳理，确定改造迁移步骤，根据确定的系统架构，对现有相关系统进行改造开发。提出系统验收标准和搭建集成测试环境，对完成改造的系统进行全面测试。  

在新架构下逐步完成改造迁移工作，并进入集成测试环境，对系统进行集成测试。依据系统建设初期的设想和集成测试案例对系统进行测试，完全符合系统设计要求。

2018年8月 – 2018年10月

典型系统的小范围应用实验。撰写课题研究论文。研究论文发表与实验报告。

项目运营情况

目前系统已经上线运行，在手机银行和微信银行的缴费类交易和转账路由交易上线成功进行生产运行。与银联的无卡支付二三类户开户交易的联机测试已经完成，正在等待排期上线。由于系统基于原系统体系内进行改造更新，所以运维的难度没有明显增加。缴费类业务在有模板的情况下基本上保证两周内开发测试完成。

项目成效

缩短开发时间，将普通缴费类业务的上线时间由原来的一个月左右缩短到半个月。系统间更为独立，降低系统间的耦合度。

因使用路由引擎方式进行交易路由，所以在电信管控黑名单之类的阻断类交易更容易融合入系统中。对交易流程的插入、修改等操作有更高的灵活性。

经验总结

1.从微服务架构理念出发，结合现有系统和开发平台。设计实现跨平台，分布式集群模式下的微服务交易系统。满足互联网交易复杂性和快速开发需求的特点，在此基础上实现与现有系统平台的平滑过渡；

2.服务进行拆分后，将开发、维护代码的过程标准化、流程化，做到小限度开发，小限度测试的敏捷开发原则；

3.新系统架构上线后与旧系统进行兼容，新增功能在新架构上实施。旧有系统功能逐步迁移至新系统架构。终实现落地去IOE化的分布式服务、内存数据库结构，以确保系统具有弹性、安全、高效的风险应对能力。

转载请注明出处和本文链接。