基于统一开发平台的微服务架构转型升级之路 | 某国有大型银行案例

转载本文需注明出处：EAWorld，违者必究。
 

引言：

某银行是一家国有大型银行，从2016年开始采用了咱们的SOA开发平台做为基础Java开发平台。

2018年，咱们发布了新一代微服务开发平台EOS Platform 8，而其正在谋求技术架构转型升级，正好借助咱们的新一代微服务开发平台，对已有的SOA架构技术平台进行升级。

做为该银行Java开发平台项目的架构师，本文我为你们分享其统一开发平台技术架构转型升级的历程，并结合银行重点项目——公司客户营销系统的案例，向你们讲述微服务项目建设的一些实践经验，但愿给正在或即将进行微服务架构转型的企业获得一些启发。
 

目录：

一、统一开发平台建设历程
二、微服务架构落地的关键点
三、基于平台应用实践
四、总结
 

1.统一开发平台建设历程

建设背景

在经济新常态下，国内商业银行正面临持续加深的市场化改革和互联网金融大潮的双重挑战。同时，国家日益重视银行业信息科技风险防范和管理工做，提出信息系统“安全、可控”的战略目标。为应对新经济形势下的新挑战和“自主、可控”的新任务，银行业须要从如下两方面来提升自身IT建设能力：

第一，在IT管理层面，银行须要创建统一管控体系，实现项目集中化管理、提高自主掌控能力，下降系统运行和维护风险；
第二，在架构层面，银行须要统一的技术路线、技术架构和数据标准，不断积累可复用的企业资产，提高系统快速交付能力。
 

建设过程

该银行在自主创新上起步很早，长期以来一直坚持走国产化和开源软件的道路。

该银行自2016年开始围绕普元EOS+BPS+BIIP进行SOA架构Java开发平台建设；2017年初发布Java开发平台1.0版本，截止到2018年，已经由40多个系统基于Java开发平台建设和上线运行； 2017~2018年，围绕Java开发平台，建设开发运维标准规范、技术可研标准规范、开源技术选型标准规范、培训及考试认证体系。

可是传统的SOA项目开发周期长，弹性伸缩能力弱，系统内外间耦合程度高，没法从根本架构上知足银行向互联网银行转变的需求。做为银行自主创新的核心，Java开发平台技术架构亟待转型。因此从2018年起，借助咱们的新一代微服务开发平台，实现技术架构升级，并引入Devops提高系统开发运维一体化能力。
 

2.微服务架构落地的关键点

微服务落地关键技术选型

在当前市面上存在多个流行的微服务框架，要在框架中选择一款适合本身的微服务框架。在普元，经过对多个微服务框架进行比较，最终选择了SpringCloud做为基础的微服务框架。

其中以
Eureka做为服务注册中心
SpringBoot做为服务容器
SWAGGER做为在线文档自动生成+功能测试
Apollo做为配置中心，来提供配置的热更新功能
使用Vue+IviewUI来支撑前端工程模块化的开发
使用Skywaking做为微服务的监控
 

先后端分离明确分工

在开发方式上，使用先后端分离的开发模式。在传统的开发模式中，开发人员急须要关注后端逻辑的开发，还须要关注前端页面的开发，开发职责比较混乱。

先后端分离的开发模式：前端倾向于呈现，着重处理用户体验相关的问题；后端则倾向于业务逻辑、数据处理和持久化等。在设计清晰的状况下，后端只须要以数据为中心对业务处理算法负责，并按约定为前端提供 API 接口；而前端使用这些接口对用户体验负责。

与此同时，前端能够根据用户不一样时期的体验需求迅速改版，后端对此毫无压力。同理，后端进行的业务逻辑升级，数据持久方案变动，只要不影响到接口，前端能够绝不知情。

在先后端分离的开发模式下，前端和后端应该之前端为主导。为何呢？由于前端开发人员会受到项目/产品经理或客户的直接影响：这个地方应该放个按钮，那个操做应该这么进行等等。前端还要与美工对接：这样的设计很差实现，是否能够改为那样。客户要求必须这么操做，可是这个设计作不到，因此前端还要跟后端对接：对于某些应用，甚至是多个后端。所以前端能够成为项目沟通的中心，比后端更合适承担主导的角色。
 

高可靠高可用确保服务稳定

在微服务架构下，全部的服务均为无状态的。所谓的无状态是指对单次请求的处理，不依赖其余请求；也就是说，处理一次请求所需的所有信息，要么都包含在这个请求里，要么能够从外部获取到（好比说数据库），服务器自己不存储任何信息。使用无状态的服务， 服务实例能够进行多节点的实例的部署。

在咱们的微服务架构中全部的服务节点均使用MM双节点配置，并能够进行多节点扩展，来达到服务的高可用高可靠。
 

持续发布，快速发布微服务应用

在微服务的架构下，持续发布咱们面临的两大问题：

一、部署流程的多样性
二、应用会被拆分红多个微服务，部署到多n个节点。如何作到微服务的持续发布，快速响应

首先咱们将任务进行原子化（如：组件的编译、打包、数据初始化、部署等每一项定义为一个任务），这些任务可进行任意的编排。

其次咱们经过定义发布流水线，用户进行发布流程编排，直接设置环境中部署任务（在部署任务中设置具体的组件部署方式，部署配置）、编排环境的顺序等进行自由的持续发布。
 

多策略部署，实现应用快速切换

针对微服务应用的快速切换，咱们提供多策略的部署方式：

一、滚动升级作灰度发布，对外接口保持不变
二、蓝绿切换，对外接口不变
三、API多版本，对外接口发生变化
 

3.基于平台应用实践

Yes Or No, 微服务架构的优点与挑战?

第一个须要思考的问题，就是我该不应采用微服务架构来实施这个项目。回答该不应，首先来看看微服务架构有那些优点，对我提出了哪些要求，我需不须要它的这个优点，又可否解决它的问题。

微服务的优点很明显，显著的有如下几点：

一、微服务业务功能简单，功能边界清晰，易于开发、理解和维护
二、每一个服务能够由专门的开发团队开发，自由选择技术栈，如数据库、编程语言
三、服务间调用采用的API接口，只要接口不变，内部调整对其余微服务透明
四、微服务无状态部署，经过注册中心自动发现，能够新增或者移除服务实例按需弹性伸缩，横向扩展很容易
五、单个微服务十分轻量，启停速度很快，且便于持续自动化部署
六、每一个微服务都是独立部署，技术栈选择自由，因此能够独立演进

但一样的它也给项目实施和运维人员提出了更高了要求：

一、开发测试阶段，由于涉及服务依赖，而依赖服务若是没有就绪，须要编写Mock或者挡板
二、微服务架构是天生的分布式架构，而分布式有它固有的复杂性，如网络延迟、分布式事务、容错等
三、微服务数量多，分散在众多节点上，对他们的运维监控成本大幅提高
四、虽然发布单个微服务很容易，可是一个微服务项目每每包含众多微服务实例，且服务依赖对服务启动顺序有要求，整个应用的发布相比单体应用反而要复杂
五、一个业务请求牵涉多个服务间调用，出现问题后，若是没有集中日志收集、调用链路跟踪，定位问题相比单体应用要困难的多
 

Yes Or No, 那些系统适合采用微服务架构？

根据上述微服务架构的优势和要求，咱们能够知道微服务架构并非万能的，有它适合采用的系统，这些系统包括：

一、对于业务流程较为复杂，且业务会逐渐变得更加复杂的系统，单体应用将十分庞大，后期难以修改和维护，应考虑使用微服务架构。
二、为了知足业务需求，项目中引入了众多的技术栈，中间件，单体应用会给开发者带来很大的困扰，应考虑将应用拆分红多个独立部署的采用最优技术栈实施的微服务。
三、高并发的，有高可用和弹性伸缩需求的系统，每每是那些面向庞大数量互联网用户的平台类、交易类系统，应考虑利用微服务架构便于横向扩展和弹性伸缩的特性。
四、单体应用版本发布成本高，而单个微服务的变动和发布都很容易，那些有高频率版本发布需求的系统，应使用微服务架构。
五、没有数据实时强一致要求，可接受数据最终一致的系统，可以使用微服务架构。
 

How,单体到微服务怎么拆？

通过一番比对，这个项目适合采用微服务架构。那么该怎么对项目进行服务拆分呢，拆分到什么粒度为止呢？

18年初，某银行使用微服务开发平台建设公司客户营销项目，首先面临的问题就是微服务如何拆分，结合咱们的经验，提出了如下5个拆分原则：

一、按照业务拆分

按照业务来拆分微服务是很天然的，将同类业务划归一个微服务，有利于开发人员理解需求和开发（不一样的业务由不一样的开发人员来开发），同时清晰的功能边界天生具备高内聚的优势，避免了微服务间频繁的远程调用，提高了性能和稳定性。

二、按照请求数拆分

某些服务被频繁调用，而某些服务不多被调用，频繁调用的服务可考虑与不多被调用的服务隔离出来独立部署。

三、常变与不变

某些服务可能很频繁的因需求的变动而频繁发布新版本和上线，为避免影响那些不变的服务，这些频繁变化的服务应当隔离出来独立部署。

四、避免过分拆分

若是发现某些服务频繁的相互调用，说明这两个服务所属的业务由很紧密的耦合关系，考虑合并为一个服务。

五、避免分布式事务

若是服务间存在多方更新的状况，即A调用B，A又调用C或者B又调用C，B和C均要更新数据库，且B和C要求同时成功或者同时失败，则出现了多方更新，应考虑合并B和C。
 

How,微服务怎么开发？

 

微服务划分完了，是否是能够进入开发了呢？ 进入开发前，首先要看一看平台提供了那些基础能力，这些是不须要重复去开发的。

咱们目前在这家银行正在建设的微服务开发平台，建设有包括微服务开发IDE、服务注册中心、配置中心、API网关、认证鉴权中心、日志中心、管理监控中心等基础服务组件，项目组只需关心自身业务微服务的开发。

采用敏捷开发模式，每一个微服务组件开发由1到2人负责，每日经过持续集成日构建，快速迭代开发。

公司客户营销项目也是基于微服务开发平台进行建设，建设中作了如下约定：

一、先后端分离+Rest通讯，前端采用Vue，后端采用Spring Boot，Rest+Json通讯；

二、使用平台提供的API网关统一接入，先后端通讯、系统间的服务调用都要通过API网关，网关上作负载、限流、调用认证鉴权中心服务作用户身份认证和权限校验；

三、Rest服务返回的对象统一，包含Http Status状态码和消息体，Service和Ctroller直接抛出业务异常，业务异常统一为一种类型的运行时异常，经过Spring MVC的统一异常处理机制，向前端返回状态为200包含异常提示信息的结果（之因此返回200，是由于业务异常属于用户输入致使的，服务正常工做，避免熔断计数和降级）；

四、采用JWT+Redis作身份认证和权限校验，JWT token在HTTP Header中传递，Redis中存放注销后的token，解决用户注销后Token未过时的问题。 而且在网关上增长拦截器，对用户Token作过半刷新；

五、对数据库作了拆分，微服务访问本身的数据库。 数据源配置存在配置中心集中管理，可是不作热更新，须要微服务重启后才能生效。
 

How,微服务怎么测试？

开发伴随着测试，没有通过测试的代码等因而无效代码。微服务的测试与单体应用不一样，先后端、服务间都是Rest接口，若是A服务依赖了服务B，而服务B尚未开发完成怎么办？

公司客户营销项目时，微服务之间有依赖关系，为了避免受依赖服务的制约，在双方商定好Rest接口后，由服务提供方开发Mock服务，供消费方使用， Mock服务一样注册到注册中心。

开发人员使用Postman自测本身开发的服务。

版本发布人员专人负责每日构建，利用Jekins+Maven+SonaQube自动执行单元测试和代码检查。

开发后期，测试人员利用LoadRunner和Jmeter作压力测试。
 

How,微服务怎么发布？

在该银行公司客户营销项目建设过程当中，使用咱们的Devops平台，对微服务作每日构建和自动发布。

Devops平台在开发测试环境上搭建一套，为不一样项目组开通租户便可使用。Devops持续集成的技术栈使用的是Jenkins+Maven+Nexus+SonarQube。在Devops前端页面上建立自动部署计划，利用Ansible脚本，将打出的部署包自动部署在目标机器上，自动启动。

前端项目自动发布在Nginx，后端微服务打包成Fatjar发布到目标服务器上，利用Spring Boot内置容器Tomcat启动。

#目前这套环境仅在开发测试环境上使用。
 

How,微服务怎么监控？

公司客户营销项目利用平台提供的日志中心（ELK技术栈）作日志集中收集和分析。 平台自动记录全局流水号、请求流水号和响应流水号到日志文件，Filebeat与微服务部署在一块儿，收集到的日志首先发送到Kafka集群，Logstash从Kafka获取日志记录，通过过滤、加工（补充了几个索引字段，如类型）后发送到ElasticSearch，最后从Kibana上呈现。

采用开源软件Skywalking实现微服务调用链路跟踪、服务进程JVM、线程和负载的监控。平台提供了管理监控页面，从ElasticSearch中获取监控信息，在Governor页面呈现。

对于项目中自定义的一些业务监控，项目组自行组装消息发送到ＭＱ，利用该银行自有的业务监控平台，集中展现。

4.总结

微服务架构是当前互联网公司广泛采用的技术架构，且正在快速地延伸到互联网金融行业。微服务架构技术优点明显，但技术门槛较高，咱们的新一代微服务开发平台整合一系列优秀开源技术，造成一套微服务架构落地的最佳实践，帮助某银行安全快速地实现了技术架构的一次转型升级。



关于做者：田健，现任普元架构师，长期致力于IT技术研究、产品设计与开发、架构咨询等工做，前后主导北京银行数据治理平台、国家开发银行分布式服务框架、邮储银行统一开发平台等项目的设计和开发工做。

 

 

关于EAWorld：微服务，DevOps，数据治理，移动架构原创技术分享