本文主要是介绍曾经参与的，服务再拆分和转发，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
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进行转发，学习了。希望后面能够应用。
这篇关于曾经参与的，服务再拆分和转发的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
