回顾那段公司的工作经历，经过两年多时间的洗礼，我觉得最大的收获就是遇到一位好老板，得以器重与栽培。自委以重任后，带领金融产品团队进行了一系列的系统重构和改造优化工作，重新塑造了一系列车金融相关业务核心系统，从而从根本上改善原来的糟糕面貌，根除了一系列诟病和问题，为业务长期发展奠定坚实基础。
温馨提示：全文共计4600余字，乃上班地铁途中码字编写，实属不易，感谢关注。起草于2020年11月16日，终稿于2020年12月5日。
导读
我自2017年9月4日从一家互联网出行行业S公司离职，然后加入这家互联网金融M公司，后来得益于团队人员变更的契机，新调过来一位新老板开始负责车金融业务线的研发工作。得益于其器重与栽培，从一名入职后端研发角色，开始组建金融产品团队。从最初的两人团队逐渐壮大后来的将近10人团队，从负责GPS审核和金融产品系统白手起家，进而负责基础数据平台、合同中心、贷后审核、请款进件等相关核心系统业务。
一个人在职业生涯中倘若不能遇到一位伯乐，我觉得自己的能力与才华就会被埋没。而我以自己工作生涯亲身体会，能够遇到一位好老板，实属不易。
商鞅倘若没有遇到秦孝公，何以进行著名的“商鞅变法”，而秦国正因为变法改革从此开始变得强大，为秦灭六国奠定坚实基础，进而统一六国，建立秦国。
我虽不及商鞅，但内心自认为尚有能力。而我经过多次思考，我自身的能力优势是什么，经过在M公司的洗礼和实践证明，我可以发挥自己的优势，更好地带领团队解决公司相关业务系统所面临的一系列诟病和痛点。
我不畏惧困难和挫折，喜欢沉迷于创新和研究之中。我徜徉于那漫长的地铁旅程中，或思索于睡觉前的那些灵魂时刻，灵感就会在那一瞬间不经意间迸发。
回忆这两年多的历程，那些刻骨铭心的岁月回忆，以及在峥嵘岁月的艰辛历程，如同昨日。我带着梦想出发，带着团队启程。然而，大半年过去了，再来回顾这段历程，我觉得有必要写一下期间所做的几件事儿。这些事情背后总有一段艰辛，但最终取得最终的胜利，所以我这里想跟各位小伙伴分享，希望给你们启迪或帮助。感谢你们的支持和关注，让我们从这里启程吧。
其一、存储过程改造
存储过程的改造，是车金融业务线发展所面临的必然选择。系统之所以重构，是因为它带给我们研发的痛苦至今依然刻骨铭心。不仅仅老板关注这件事，团队更是立下“军令状”，必须炸掉这座“碉堡”，才能保障大部队继续前进。
鉴于此，我们存储过程重构工作就是在这样的历史背景下开展的，老板赋予我们使命并对我们团队寄予厚望，我带领团队身肩其重任，开始部署执行规划和目标。
我带领一位小伙伴从第一个存储过程前置规则检验（又称之为RR规则）开始，是因为这个业务逻辑模块是整个重构工作的重点任务。这个存储过程源代码行数多达上万行，可见任务之艰辛，前所未有。此外，这个存储过程的业务逻辑是整个办单业务流程的关键点，是授信进入审核环节的关键节点。
存储过程重构工作，由于任务艰巨且业务逻辑复杂，这些代码随着业务迭代，没有人能够清晰的讲解所有的业务逻辑，同时对线上业务流程影响大。鉴于此，我们对整个重构工作从研发资源和时间安排，对大目标进行的任务拆解。
我带领小伙伴从业务逻辑梳理，然后到技术方案设计，最终我们基于Java语言搭建了一个SpringBoot应用，把这些存储过程通过分类拆解与业务逻辑合并，由于原存储过程调用，是运维通过在Linux服务器配置cron脚本跟数据库存储过程通信，因此我们这次重构后通过应用服务暴露几个rest api 接口提供给调度平台系统，以配置job执行调度。
经过几个月的时间，存储过程一个个画上对号并完成上线。这期间，最早一位小伙伴离职，后加入另一位小伙伴，最终完成这个使命。
其二、金融产品重构
金融产品重构，是响应XD团队内部SL同学“高呼前后端分离”的背景下而顺道逐渐开展的。整个重构工作在后续的进行与推进中，也是业务发展所面临的必然选择，从技术架构来讲，为了考虑业务模块的扩展性与伸缩性，最终完成金融产品重构的又一大“战役”。
金融产品重构的第一阶段，完成了老系统功能的拆分，实现了金融产品平台的独立部署与运营的目标。前端基于vue，服务端基于SpringBoot，从而实现前后端分离。
第二阶段，我们完成搭建了一个金融产品中心服务，致力于提供统一的金融方案获取与金融产品试算一体的服务能力。其主要职责，是完成改善金融产品费用计算散落于各个业务系统的局面，使得金融产品中心可以直接提供支持业务系统。该阶段目标的达成，为后续业务发展奠定了基础。
第三阶段，则基于金融产品现有的业务模型，通过与产品运营同学进行多次洽谈，为提高金融产品平台的运营效率所做的一系列平台优化工作，从功能设计、用户交互、业务模型三个方面进行开展。
三阶段中最重要的优化工作，基于现有的业务与未来的发展需要，在金融产品业务模型的基础上，进一步对模型进行重塑，重塑的目标能够支持业务在不同资方与地域城市的差异性运营。
金融产品平台在计算引擎设计上，进行了多方面的调研与技术方案设计工作，最终确定了扩展性强与伸缩性灵活的设计方案。金融方案构成的每个独立费用项单元可以支持灵活的进位方式与精度处理配置控制，然后通过调用计算引擎完成整个金融方案试算，从而实现产品运营角度的可视化配置与多元化运营。
在规则引擎设计方面，完成了前置规则与后置规则在金融产品平台的配置化目标。同时为了提高扩展性，基于xdiamond配置化的规则元数据定义，使得金融产品系统实现配置化既可以完成系统升级免发布部署。
同时，规则引擎支持四则运算、三元运算、逻辑运算的业务场景配置， 为了进一步降低运营成本，在交互设计与功能设计做出不少功能创新，以更友好的支持产品运营。
第四阶段，则完成金融产品的数据库拆分，使得其真正独立于原有的庞大的数据库，为系统服务的稳定性奠定基础。
其三、GPS审核系统重构
GPS审核系统从入职之初就由我开始负责需求迭代，在长期攀爬的过程中，深思做了研究与平衡，逐渐拆分出两个应用服务。在系统架构上，一个提供给GPS审核系统前端对接，即前后端分离；另一个则提供给车金融业务线的应用服务，以提供http或rpc协议接口服务。
GPS审核系统，完成了系统业务模块的拆分与维服务部署，实现对老系统的业务解耦和服务解耦。同时，在GPS审核系统交互设计上与GPS审核人员多次洽谈，并做了相关优化工作。
后续增加了领单与派单机制，提高了审核人员的审核效率，在功能交互上新增了任务队列与人员队列的监控面板，为GPS审核主管提供了可视化监控页面，手持一把利剑，以进而提高GPS审核团队效能。
我们研发团队通过自主创新，对整个GPS审核系统又进行了系统重构，重构目标是为了提高系统的可维护性和扩展性，譬如分布式锁的全局统一管理，GPS操作多场景的进一步抽象，派单流程的进一步流程优化等工作。
GPS审核系统在历史的推进中，又完成了数据库的拆分，实现真正的独立部署与运维，为系统的稳定性奠定基础。
其四、搭建基础数据平台
基础数据平台的搭建实现了车金融业务线基础数据的统一管理，为运营人员提供了一个平台抓手，支撑车金融业务运营发展。
基础数据服务则解放了各业务系统对基础数据依赖的场景下，由于没有一个基础数据服务的角色提供服务能力，它们面临需要自己去查询数据。因此，基础数据服务搭建后，改善了车金融业务线各业务系统所面临的窘境。
此外，为了支撑公司业务发展规模的增长，对系统服务从架构设计上，从系统接口性能做出了创新。引入了一二级缓存机制，进而提升接口服务的响应性能。
后续的数据库拆分，则进一步提高系统的稳定性，实现了基础数据平台的独立部署运营。同时，为了支撑业务的需要，提升平台的运营效能，主动承担一些需求场景，这种大无畏的精神使得我们团队的品牌形象在产品与运营团队得到立足。
其五、MySQL拆库
最初车金融业务线信贷团队的系统架构，庞大的业务系统的业务模块都是在一个数据库实现的。这个数据库大概有将近400张表，包含GPS审核、信审、贷后、金融产品、进件、放款、影像等诸多业务单元模块，还有一些随着业务迭代根本都用不到的数据库表残留下来。
伴随着业务系统应用的拆分，从业务规模的发展以及系统的扩展性和稳定性出发，相关团队小组进行了业务单元的数据库拆分。我带领金融产品团队，从金融产品、GPS审核、基础数据经过一年载时间完成拆分工作。
数据库拆分的主要宗旨，基于业务系统从业务领域模型进行拆分，数据库表拆分时，保持表结构不变，使得系统可以维持最小化的变动，只是一个数据源切换，即可完成拆分上线工作。同时也便于线上灰度方案的运行，以及紧急故障情况下的回滚。
数据库拆分后，各个业务系统就可以进一步对系统进行更深层次的重构或优化，以适应业务发展的需要。
其六、搭建天眼监控平台
天眼监控平台，是老板赋予团队使命的技术研发创新产物。从车金融业务线整体来看，金融产品团队负责业务系统大量涉及相关钱的计算、核对、流入、流出，因此为了实现立体化、多元化监控预警机制，我们基于业务场景搭建了天眼监控平台。
对于合同与贷后两个业务系统来讲，为了应对频繁的需求迭代，进一步提高测试流程覆盖率，我们自研了流量复现功能，以更好地提高我们需求上线后隐蔽的bug提前诊治与预警处理，同时不间断对线上的数据正确性与完整性做监控。
流量复现，从样本采集、特征定义、数据源对接、校验中心几个核心模块，完成整体功能设计。基于此功能，可以进一步对于需求上线后，辅助测试与研发，基于此平台功能进一步提升测试效率，提高测试质量，覆盖业务场景的多样性。
其七、搭建质量中心系统
质检中心系统是为了辅助合同系统和请款系统，对数据正确性与完整性实现诊治与预警。
由于合同系统和贷后系统出现几次线上故障，老板不得重视系统的设计是否合理，后续是否从根本上解决此问题。老板对我们金融产品团队寄予厚望，然后接手合同与贷后系统，并筹划技术方案实现以解决当前面临的问题。
鉴于此，我们团队通过认真研究当前系统存在的问题，并多次沟通相关技术实现方案。然后把目标拆分出两个系统（贷后与合同）各自的目标以及里程碑。同时，指定人员完成当前系统编码设计实现，把现有人力资源分为两个小组，每个小组一个成员一个实现质检中心模块设计，另一个实现业务系统对接质检中心。
最终，我们通过自研的质检中心系统，达成了我们最初的目标，并解决系统面临的问题。
其八、合同中心的重塑设计
合同中心在我入职之初，这个系统就已经成型了。最初由一位研发负责，合同模板的制定与样式布局控制，基于JSP实现。这种系统设计伴随着团队走过一段时间，直到团队人员变更，新老板到来，然后开始一轮新的架构设计与系统演进。
合同中心重构的第一版，实现基于xdiamond配置的doraemon从此诞生，它实现了合同模板字段的定义与取值逻辑配置。
它的诞生伴随着车金融走过很长一段时间，基于配置化的思想代表着系统设计的潮流，多少次曾经在一些地方看到对它的宣传和赞美。但是它的这种设计也同时容易致命，一旦出现故障，当你知道其实问题已经在线上运行了不知几天了，你知道问题产生的时候情报已经非常滞后了。
后来，老板也不得认识到这种继基于配置化的设计固然很好，但是它不利于产品人员接触，学习成本高，没有业务逻辑正确性的检查机制。这不得使我们又需要重新设计这个系统，基于用户交互的平台设计方案开始应运而生。
系统设计的主要核心是，通过配置合同要素的不同场景控制，实现合同在一些特定场景的支持。此外，合同定义必须保持一种合理维度，不可能把同一个合同在不同资方或不同金融方案的差异，在同一个合同中维护，否则这种场景的复杂性又造就了单一合同的复杂性。鉴于此，我们需要找到一个平衡点尽可能达到科学的合理均衡，既不会拆解更多的合同数据，同时也保持单一合同的科学性与简约性。
资方、地域城市、新车/二手车、车牌类型（公牌，私牌）构成划分同一合同在不同业务场景业务逻辑差异的特征依据。譬如，公牌与私牌租赁合同相关内容条文或取值不同，那我们就划分两个不同的合同，而不是在合同要素上配置条件路由，通过这样的设计，进一步提高合同系统平台的数据体量维持一个均衡。
尾语
从入职之初一名普通的后端研发到组建金融产品团队负责车金融相关核心系统，能够得到老板赏识与器重，这源于老板对我能力的肯定。
通过“借事修人”的人才培养理念，进一步使得我们金融产品团队屹立于车金融业务线，我们团队的使命与责任感伴随着我们进行一次次系统重构，重构不是推倒重来，更不是看着不爽需要按照自己的喜好重新设计，它是适应公司业务发展的必然选择。
这两年，能够加入这样一个公司平台，遇到一群靠谱的小伙伴共同合作，尽管此时的距离空间让我们分割多地，但是我们金融产品团队的奋斗历程将铭记我与团队成员的每一位心中。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
