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

Posted 2021-04-14 EAWorld

引言：

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

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

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

目录：

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

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

3、基于平台应用实践

4、总结

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双节点配置，并可以进行多节点扩展，来达到服务的高可用高可靠。

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

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

1、部署流程的多样性

2、应用会被拆分成多个微服务，部署到多n个节点。如何做到微服务的持续发布，快速响应

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

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

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

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

1、滚动升级做灰度发布，对外接口保持不变

2、蓝绿切换，对外接口不变

3、API多版本，对外接口发生变化

3.基于平台应用实践

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

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

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

1、微服务业务功能简单，功能边界清晰，易于开发、理解和维护

2、每个服务可以由专门的开发团队开发，自由选择技术栈，如数据库、编程语言

3、服务间调用采用的API接口，只要接口不变，内部调整对其他微服务透明

4、微服务无状态部署，通过注册中心自动发现，可以新增或者移除服务实例按需弹性伸缩，横向扩展很容易

5、单个微服务十分轻量，启停速度很快，且便于持续自动化部署

6、每个微服务都是独立部署，技术栈选择自由，所以可以独立演进

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

1、开发测试阶段，因为涉及服务依赖，而依赖服务如果没有就绪，需要编写Mock或者挡板

2、微服务架构是天生的分布式架构，而分布式有它固有的复杂性，如网络延迟、分布式事务、容错等

3、微服务数量多，分散在众多节点上，对他们的运维监控成本大幅提升

4、虽然发布单个微服务很容易，但是一个微服务项目往往包含众多微服务实例，且服务依赖对服务启动顺序有要求，整个应用的发布相比单体应用反而要复杂

5、一个业务请求牵涉多个服务间调用，出现问题后，如果没有集中日志收集、调用链路跟踪，定位问题相比单体应用要困难的多

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

根据上述微服务架构的优点和要求，我们可以知道微服务架构并不是万能的，有它适合采用的系统，这些系统包括：

1、对于业务流程较为复杂，且业务会逐渐变得更加复杂的系统，单体应用将十分庞大，后期难以修改和维护，应考虑使用微服务架构。

2、为了满足业务需求，项目中引入了众多的技术栈，中间件，单体应用会给开发者带来很大的困扰，应考虑将应用拆分成多个独立部署的采用最优技术栈实施的微服务。

3、高并发的，有高可用和弹性伸缩需求的系统，往往是那些面向庞大数量互联网用户的平台类、交易类系统，应考虑利用微服务架构便于横向扩展和弹性伸缩的特性。

4、单体应用版本发布成本高，而单个微服务的变更和发布都很容易，那些有高频率版本发布需求的系统，应使用微服务架构。

5、没有数据实时强一致要求，可接受数据最终一致的系统，可使用微服务架构。

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

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

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

1、按照业务拆分

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

2、按照请求数拆分

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

3、常变与不变

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

4、避免过度拆分

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

5、避免分布式事务

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

How,微服务怎么开发？

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

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

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

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

1、前后端分离+Rest通信，前端采用Vue，后端采用Spring Boot，Rest+Json通信；

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

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

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

5、对数据库做了拆分，微服务访问自己的数据库。 数据源配置存在配置中心集中管理，但是不做热更新，需要微服务重启后才能生效。

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.总结

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

精选提问：

问1：Eureka不更新了，为什么还选这个？

答：Eureka 用的是1.x版本，2.x的版本不再开源，但是我们目前不需要他。

问2：选择Skywalking有做过选型评估吗？

答：Skywalking与Pinpoint做过技术选型，在功能上Skywalking更强，比如Skywalking可以做到方法级的调用链路跟踪，Pinpoint只能做到系统级。

问3：Devops平台与技术开发平台是如何有机结合的？

答：DevOps平台与技术开发平台并没有直接的关联关系。技术开发平台更多关注的是开发阶段，而DevOps是关注整个软件生命周期。DevOps平台可以使用技术开发平台的相关资源（比如使用源代码、相关文档等），将这些成果进行后续操作（比如源代码的的编译打包，进行持续发布等等）。

问4：不要logstash直接用Filebeat可以吗？

答：用Logstash是为了使用Logstash上丰富的插件，没有日志过滤需求的话，可以不使用。

问5：日志的索引和调用链监控的traceid是怎么关联的？

答：目前全局流水号记录在了日志里，业务调用链路里的所有微服务的日志统一发往同一个MQ队列，由Logstash生成索引日志名。

推荐阅读

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