我是如何完成GPS审核MySQL拆库的？

GPS拆库是我所在M这家公司负责MySQL拆库的第二个项目，该项目历经四个阶段（一期-查询类研发，二期-写入类研发，三期-灰度代码下线，四期-正式数据源切换），前后历经两个月最终上线告诫，但这个项目之所以划分四个阶段，从而也体现我总会把一件事情通过分解成各个小目标，各个突破，从而完成总体目标，小目标的背后也意味着风险的降低，研发难度的降低，测试范围的覆盖面减低。

1、总体概述

我所负责的GPS项目，其全称应该叫做GPS审核系统，它作为车金融在贷后环节审核业务流程的一部分，从辛巴销售端提交GPS设备商信息以及GPS安装影像件，然后到GPS审核系统，通过领单、审核，最终实现最后贷后放款。但是GPS这个应用涉及到主贷人信息、车辆信息、贷款信息、影像件信息等，则不属于我们拆库表的一部分，这也意味着相关业务逻辑就需要通过接口形式跟对接方交互，实现业务场景依赖的相关信息获取，以及业务流程环节数据的更新。其中，为了降低对GPS审核的影响，我们采取的灰度机制（即新建了一个新域名，应用也是新应用，通过观察灰度应用没有问题，然后让GPS审核人员核对数据，并试点挑取用户使用，没问题，并把灰度代码推送到正式环境）

2、项目背景

我们在2018年全年可以说一直在重构，并最终按照业务模块重构出一个个新应用，我们不再面临着原先维护一个臃肿的项目。但是，我们依然面临另外一个问题，那就是我们应用拆分了，但是大家依然公用一个MySQL数据库实例，这就意味着大家公用的表，一旦有慢查询，就会波及相关的依赖系统。鉴于此，我们为了后期业务的扩展，以及这种严重的表依赖，我们决定开拓我们数据库拆分，即根据业务模块把GPS审核相关表从原数据库实例拆出来。

3、拆库准则

我们在拆库研发启动前期，通过梳理了相关业务团队对于为了GPS拆库出来的表依赖整理，为了控制风险，我们采用表结构依然不变的前提下进行拆库。这样，就可以在数据源切换时，降低最小影响成本。

4、目标拆解

为了实现我们最终拆库，我们通过完成所有依赖接口的梳理，通过划分成查询、更新两个大类，因此我们一期实现了5个左右接口的查询类。我们在技术方案设计中，依然采用可以降级的灰度策略，即通过开关形式实现开启关闭新老接口的切换（开启时，则调用新接口；关闭时，保持原有查询）。

规划目标思维图：

4.1、一期目标

其中我们在涉及的接口，为了减少大量的开关判断逻辑以及代码污染（即我们不希望我们重构的代码减少对并行分支的冲突）我们决定采用代理设计模式（即原先查询的service方法，我们通过代理类，把相关开关切换以及新老即可切换委托给代理类）这样对于调用发，无非更换一个Proxy，对于方法的返回结果和参数依然维持不变。

一期开发比较简单，上线后测试也很容易，为了第一时间对于接口调用异常提醒研发人员，我们对于调用方法封装了一个client类，并接入方法的耗时切面，超时5秒阈值则钉钉报警。同时，对于调用接口采用RestTemplete封装，对于请求接口超时也做了相关设置，另外对于异常通过catch并发送钉钉报警。

这样一期目标上线后，没发现任何问题。

4.2、二期目标

二期目标就不像一期目标那么简单，因为涉及的接口10多个，而且我们审核的好几个查询列表包括数据导出都需要对接新接口。
通过梳理，我们对查询列表类也做了相关重构设计，即不再把查询接口都写到一个facade中，因为原先的代码冗余，另外就是该facade类职能太大，不符合单一原则，我们期望这次重构，通过引入模板方法+适配器模式，这样对于每个查询列表就是一个单一的类，而相关的重复代码则封装到抽象类中，对于新接口调用的接果，我们保持不让前端代码修改，这样就需要有个适配，因此我们采用适配器模式解决VO对新VO的转换，使得相关controller方法依然不需要进行相关修改。

其中二期我们依然面临着一个重要问题，就是如果基于我们自己的表，对于现有的数据通过查询是无法满足业务期望的，即审核人员会看到一些不应该出现在列表的数据，因此，我们又对数据进行了清洗，并对我们的主表又增加了一种流程状态，以应对其他业务流程退回场景的处理（即尽管我们GPS人工审核通过，或者在领单中、审批中、准备审批，都需要以主流程为主，相关对于贷前、贷后、复审退回的场景，都需要重置GPS审核状态）。

另外对于技术方案依然无法过滤完的数据，我们通过查询的结果，通过判断数据的状态，进行重置，这就保障我们的审核人员最终看到的数据是跟他们正常使用的一致。

二期目标，我们隔离了一个应用和域名环境，发布后我们研发走单子，并在灰度环境中审核单子，以验证流程通畅，然后我们并核对每个查询列表的数据是否跟正式环境每个菜单的数据一致。并一一验证每个功能业务逻辑，确保我们接入新接口的数据正确性。然后我们并找GPS审核人员，也一并参与核对数据，并试点人确保灰度环境没有问题，并逐步推送正式环境。

可以参考我的另外一篇文章，通过运用设计模式解决而且目标的：
https://blog.csdn.net/shichen2010/article/details/92387311

4.3、三期目标

二期目标研发和灰度周期比较长，前后也修复了几个bug，最终我们开启启动三期目标，即下线所有开关控制的业务逻辑，同时我们删掉了相关非未来GPS数据库实例的相关service、mapper、entity，以奠定四期切数据源准备。

4.4、四期目标

基于前几个阶段目标，将要迎来了我们最终胜利的时刻。上线前，我协同相关对接方，确定了技术方案，因为在切数据源的上线当晚，我们确保增量数据以及更新数据不会调用我们的接口，这就意味着，对接调用方，我们只能让服务下线，然后让DBA同步数据，研发核对数据无误后，并把上线的代码推送到生产环境，完成最终上线。

上线流程图：

5、总结

我之前的领导曾经告诉我一句话“用80%的时间思考，20%的时间去做”，因此我对于这次GPS拆库，把一个大目标拆解成阶段目标，并做好每次的灰度隔离，确保降低对生产用户的影响。认真和缜密的态度，最终换来最后的胜利的时刻。同时，我想告诫读者，设计模式真的很重要，尤其对于每次重构代码中，如果你学会运用了设计模式，那么你将收获颇多，不再是大众那种基于SpringMVC三层研发。