一个外包系统的重构过程

背景

2017年正直互联网金融崛起之时，由于那时候监管不规范，互联网金融公司如雨后春笋般崛起，我也是这时入职了一家互联网金融创业公司（一个大集团的全资子公司）。入职之前可能因为公司没有技术团队来开发一套完整的贷款系统，因此外包了系统给一个外包公司（这里就不说是哪家了），整个项目软件技术偏老，JDK当时还是用的1.7，外包系统可能大家都懂的，它们为了批量生产，基本都是有一个自有框架，然后在其框架上做开发。维护过外包系统的人可能都知道，那是一个非常痛苦的，就拿我接手的这个项目来说吧，我主要列几点。

• 数据库表冗余严重：数据库的表就有200多张表，仔细看了一下，大部分的表都是其为了方便开发各类金融项目整合的一个很庞大的系统，我们的系统可能只用到其中很少的一部分。表中很多冗余预留字段，要让一个新人短期内接手开发，几乎是不可能
• 前后端分层混乱：大量的jsp页面有sql语句，导致代码调试困难
• 严重的事务问题：系统中由于开发人员水平参差不齐和为了追求进度导致很多业务逻辑没有理清，比如将调用第三方系统的代码放进了本地事务中，导致本地事务异常回滚时，第三方无法回滚。当时是因为这个出了一个线上事故，因为生成还款计划问题，导致本地事务回滚，引发了一次用户疯狂提现却不减额度
• 维护困难：当时几乎每一个新人加入团队，每天下午培训一小时，起码要培训一个月才能上手开发，排查问题困难

出于这些原因，核心团队立志要将这个庞然大物重构，由于当时流行微服务，因此决定采用微服务的方式拆分。因为大家这个时候经验都不丰富，技术团队几乎没有任何积累。做起来，真的困难重重。我们重构主要分为3个阶段，第一阶段，稳定系统；第二阶段，自动化发布；第三阶段，微服务化

稳定系统阶段

由于创业公司，想拆分成两个团队来重构基本不现实。第一，外包项目交付时间不久，要想这个时候重构很难得到老板支持；第二，人手不足，第三线上问题频发。我们认为要想重构，必须要稳定线上服务

日志优化

由于该外包系统中，日志没有区分，全都打印出来，单台