前言

去年我参与了 OFS 项目智己部分的上线，并随着智己服务上线，一同对项目进行了重构拆分，将原本功能较为复杂的奥迪服务拆分成了多个互相独立的，耦合度较低的微服务。降低了项目总体的复杂度，有便于日后业务的进一步开展，也让我收获了许多。

在这里总结一下围绕这次重构的方案选择的讨论，最后确定的方案，以及对我的启示。

总体架构

对外界整车厂来说，这次重构是透明的。

重构前

重构前，ordercenter 是一个单独的服务，和客户中心及审贷中心通过 MQ 交互。此时只有 奥迪一家整车厂与我们对接，由于截止日期等原因，此时所有主要的和客户交互的贷前业务逻辑都放在了这个服务中。

方案

组长给我们提了要重构及大致的方向后，让我们自己尝试给一份方案，我的方案思路大致如下：

• 后续上线服务与之前服务共库，我们的业务性能未遇到瓶颈，不需要分库额外增加复杂度及运维成本
• 分离一个公共服务，提供不分辨整车厂来源的服务
• 整车厂对应服务处理相应验证鉴权工作，与对应整车厂的交互，同时业务逻辑只要能做到隔离不同整车厂业务相关的来源数据及其相关业务逻辑即可，将其他请求直接做一份转发，至公共服务，由公共服务进行后续多态处理
• 公共服务可以做到尽可能的代码复用
• 不同整车厂对应服务尽可能的小
• 原有的审贷等服务对于来源系统不敏感，保持不变

组长也同意我方案的大致观点，但做了一部分修改

• 新增一个对应 MQ 处理的服务，处理了原来服务内部一部分复杂又比较独立的 MQ 转发，状态变化相关的内容，这部分服务无关且比较繁琐，独立出来很合适
• 不同整车厂对应服务尽可能的大
• 公共服务只保留一部分不太可能在未来变化的业务逻辑，尽量让这公共服务保持不变

重构后

总结

到现在为止，这次重构已经成功完成，并且之后还接入了飞凡。在应对后续的业务变更时，体现出了良好的可扩展性，可以快速的应对需求的变化，完成开发任务，改动点影响相对较小。

• 由于业务的剧烈变动，如果当时根据我的方案，公共服务的负担可能会很重，业务逻辑会变得很深很复杂，会产生很多废弃的无人维护的老代码。
• 整车厂对应的服务很有可能切不干净，仍然会侵入公共服务，公共服务仍然会沾染整车厂相关内容，这会让原来的抽象变得很鸡肋，却没有办法。

但还要提一点

• 公共服务到最后还是没能完全无视来源系统提供服务，有些微小的部分仍然需要分辨来源做不同的处理，只能做了一下多态。这也印证了我方案的不足，公共服务很难保持不分辨整车厂来源