记录某金融机构老项目重构升级为微服务过程1

如何从EJB架构拆分微服务

这个非常有趣的过程，整个过程耗时大致接近半年时光，需要考虑到重构升级保留原来的业务线，而且还要考虑后续的维护成本，保留现有的数据库表结构，以减少数据后续的迁移工作，只从现有的ESB体系的老系统中剥离升级为微服务架构，本文大致从现有的ESB架构的体系中的EJB项目升级springcloud的完整过程，这个介绍体系后续持续更新。

EJB架构升级为SpringCloud

我们原来的EJB的金融系统的老项目已经使用很多年，对这个业务线以及设计的表结构，还有这个架构里面涉及到的方方面面的工具类，使用的模板套路都非常熟悉，如果在现有的老系统新增业务线也能支撑业务的扩展以及揽客的要求，但是随着公司提出的开源节流，对于开发从业者的成本控制，以及项目迭代的周期要求逐渐提高，原来的EJB架构的瀑布流模式的开发明显更高成本，现在分析EJB项目里面的各个组件的功能，梳理出来，接口层API，防腐层，业务层，分发层，以及页面使用vue3作为渲染数据的架构，实现前后台分离。

1. 全新的界面设计 ，使用vue3的组件，界面明显清晰，得到快速响应的效果，而且基于事件驱动，调用后端接口实现局部数据的刷新渲染，提高用户体验，这里简单介绍VUE3的使用，具体还是后端的服务切分以及如何减少数据迁移成本展开叙述。
2. EJB原来是使用sessionBean实现业务数据的流转，而且业务高度耦合，特别是通过EJB存根对象调用存储层的接口就明显的非常冗余，代码结构非常的混乱，而且新手上手成本非常高，能让开发先需要了解各个组件的使用套路才能更好的专注业务逻辑代码的编写；
3. 增加了 抽象存储层 ，升级的老系统最重要是抽象出一个单独的公共的微服务，仓储层，这个服务主要是为了减少后续的数据迁移成本，继续保留现有的数据库表结构的一个设计，原老系统使用了大量的PROCEDURE，复杂的表关联逻辑，即使拆分了微服务，这部分的逻辑都不能马上可以拆分合理的业务逻辑，所以保留现有的procedure是非常明智的办法，保留这些核心的逻辑，都抽象到一个单独的微服务，其他的微服务就可以通过feign进行调用，但是这里要注意，这里的仓储层已经是链路的最后一个节点，不能调用其他的微服务，但是其他业务层可以互相调用而且最后调用的链路是这个仓储层，所以这里的设计需要并发的访问处理，并且需要设计缓存层对热点数据进行减少磁盘的冲击，仓储层只要设计API模块，负责提供远程微服务的调用入口，以及JDBCExcute的封装，实现调用procedure。这个微服务没有负责的代码层面的逻辑，核心的逻辑都是原来老系统的procedure进行封装好，保留继续使用即可。
4. 全新的 service层的设计 从老系统剥离的MVC三层架构升级为多个微服务，而且链路要短，关联表要少，上手容易，维护容易，方便新业务线的新增改造等，围绕这些触发点，新增的微服务service层设计就非常重要，这里就通过剥离原来controller的分发后端的逻辑，原来通过EJB调用暴露的接口API，改为抽象的仓储层API接口调用，这里就简化了升级的设计难度从原MVC升级多个微服务之间的调用，简单容易理解，几个例子，原来jsp通过form表单提交后端的数据，使用的是formBean接收，这里的Bean肯定是无状态的Bean，只负责提交到后端的controller进行接收做业务处理，比如数据的类型转换，格式转换，外接口的调用返回当前业务线数据查procedure的参数等，无非就是数据的过滤转换，以及外接口的返回参数的处理，一并组装新的VO作为参数查核心的业务脚本；
5. 举个简单的业务线作为本次记录的收尾，汇款功能，相信所有的金融机构都有这个功能，这个功能点，具体的表结构，核心的主表肯定有USER表，PRAM参数表，RATE汇率表，ACCOUT账户信息表，REMITTANCE汇款表等等这些核心表构成，这里的核心表账户表属于常用的逻辑，可以封装为accountUtil，提出抽象的VO 提供多个模块使用，包括一些常用的负责处理逻辑，关联逻辑，都可以体现在这个工具包下，另外页面的API接口的剥离设计，这里可以分2种常用的方案，进行API的分割，比如第一种，一个Form表单分多个tab没有tab都有单独的信息展示，而且这些都来自一个大表的其中一些核心数据，还有其他关联表的数据，这里就可以通过多个tab划分多个API进行调用，这样的好处就是前端的设计容易保留原来的业务功能，新系统上手难度低，用户保留熟悉感，能快速上手完成汇款交易，但是这里同样也有缺点就是加大了后端切分的业务量，原来的一个tab是一个大表关联其他表返回的完整的FormBean进行返回页面，现在是一个tab进行切割，导致这里的Bean需要重新设计，而且原来的service层的代码逻辑都需要改变，特别是组装VO查询procedure的逻辑，当剥离多个API接口后，查询核心逻辑分开，然后重新组新的response对象返回，其实相当于重构了原来MVC里面的controller的业务代码，对后端开发耗时非常大而且粒度非常大，不容易分离抽象通用的代码块，另外一种方式就是通过粒度更细的方式进行升级构造，比如，页面如果多个字段，而且有些字段需要通过ajx局部刷新请求后台的这类就非常适合抽象成API进行单独的设计，另外还有初始化页面的dropdown的数据，等都非常适合这类型的单独设计为新的API接口，这个设计思路也有弊端就是后端的接口压力非常大，需求额外新增缓存来进行防护，增加了维护成本，所以这两种各有利弊；

图片:

带尺寸的图片:

居中的图片:

居中并且带尺寸的图片:
公式展示 $\Gamma (n)=(n-1)!\forall n\in \mathbb{N}$ 是通过欧拉积分

$$\Gamma (z)={\int }_0^{\infty }{t}^{z-1}{e}^{-t}dt.$$

后续有新的体会再续作，反正微服务升级改造也比较简单，但是需要对老系统的原来业务非常清晰，组件的使用非常清楚才能更好的把我新的微服务的功能设计