曾经参与的，服务再拆分和转发

曾经参与的，服务再拆分和转发

1.为什么要做服务再拆分

第一篇就说到我们后台是微服务架构，我们的服务有十几个，一年多来都是这么沿用的，但其中也存在问题，就是有些服务业务比较混乱，比如用户服务中有非用户模块，于是每次修改这些非用户模块时，都要发布用户服务，但用户服务是比较核心的模块，有的时候不和我们版本基线走，就造成了一些崴脚的局面。另一方面这也违背领域驱动模型DDD的原则，服务边界不清会导致服务混乱，耦合不当的问题，于是在今年3月初，经过我的建议和同事间的讨论，主管同意我们做服务拆分。

思路：我们都知道，如果一个业务从一个服务迁移到了另一个服务，那么前端路由势必会变，但是必须兼容前端，否则前端也要修改，但这其实是后端的改造，对前端应该是透明的。于是我们架构同事在zuul新增了转发规则：如果一个请求在请求变化记录表中有，就转发到新的服务

2.实施过程

2.1 服务划分

上面说到为了使服务更合理，粒度更准确，我们对一些业务模块进行了再细分。比如我负责的经费模块从用户模块迁移到一个新的服务，funding。其它要拆分的业务模块也是一样，有的是迁移到新的

2.2 建立新服务模块

2.3 如果要换库，就建立新的库。准备脚本迁移表

开发和测试环境自己建，生产环境运维去建

2.4 准备数据迁移脚本，将原表的数据insert into到新表

注意：必须保证开发、测试、各线上环境数据表结构一模一样，否则可能出现不可预期的问题

2.5 加新服务的配置文件，如果不是新服务就不用加

2.6 修改与原服务相关的业务，注意修改表名或文件路径

2.7 记录原服务对应业务的路由到请求变化记录表中

这一篇说到我们用的是Swagger管理Api，还有导出功能，于是我稍微改造了下这里的导出，按要求输出我要的url格式，转换为insert into语句插入到请求变化记录表中。

设置转发规则

这是至关重要的一点，过程大概是这样：

将请求变化记录表初始化redis中

在zuul中转发

读取redis中转发信息

根据当前请求转发

转发并设置缓存

RequestContext设置新的ServiceId，dest表示请求url

思考与回顾：

为什么把请求变化记录表初始化Redis中？

因为请求变化记录表一般不会变，如果每次请求来了还要去查这个表，显然不合理，查缓存是符合要求的。

通过设置Zuul的RequestContext进行转发，学习了。希望后面能够应用。