基础数据为车金融各业务系统提供数据支撑，为实现这一宏伟目标，我们研发团队见证了一个从零开始，一路筚路蓝缕以启山林的历程。让我们开始了解那段历程，回忆那段峥嵘岁月。作为见证这段历程的我，谱写一篇文章回忆那段春秋往事。
一、序言
最近推出《金融产品中心的前世今生》
《GPS审核系统的前世今生》后，借着兴致使然，再推出此新作。整篇文章共计4400余字，全是地铁旅程中手机码字，实属不易。文笔不佳，敬请原谅。感谢读者能够认真阅读完毕，相信你从中不少收获和启迪。感谢读者的关注，我将后续继续推出此系列文章。
二、导读
基础数据平台从零到诞生，前后经历将近一年载的时间，为了推进这个项目的成立，自然背后离不开老板的大力支持，以及我们金融产品团队小伙伴的辛勤付出和不懈努力。
基础数据平台，作为车金融业务线一个上游的应用服务，对下游相关业务系统提供基础数据数据的管理和服务。从业务上讲，为整个办单到放款整个业务流程环节提供基础数据支持（譬如数据字典，行政编码，经销商单位和门店）。此外，为了满足公司业务的发展规模，支撑未来的业务增长，从项目立项之初，就从技术架构和应用服务性能，做出了大量的研发设计工作，取得了不错的成果。
三、纷乱时代
入职之初，我所在的信贷团队有一个老系统，提供给运营人员的功能管理包括基础数据平台相关功能的一部分，早期这些跟业务系统紧密联系的数据字典，行政编码，经销商单位和门店，由于并没有一个统一的系统应用提供接口服务，而且各业务系统公用一个数据库，因此都是自己去查询数据为业务逻辑支持。
这些业务系统，诸如早期已经拆分的收单系统，合同系统，审核系统等，尽管属于不同的小组负责人，但是我们会经常发现查询数据字典或经销商单位门店的业务逻辑代码随处可见，屡见不鲜。
毕竟虽然不属于同一个应用，但是公用同一个数据库，既然没有一个应用服务提供接口。其实他们这种所为造成了系统后期业务拆分，留下一个诟病。倘若没有这个诟病，也就不会有基础数据平台的诞生。历史的需要，恰逢英雄的诞生。历史的偶然，造就辉煌的时代。而我当然毛遂自荐，为团队着想，愿意抗下这个艰巨任务。
在重构的过程中，由于金融产品跟数据字典和经销商单位门店紧密联系，鉴于此，为了考虑今后系统架构和业务系统的定位清晰，我带领团队准备去统一搭建一个基础数据平台，提供给产品运营团队使用；同时搭建一个基础数据服务提供接口服务于不仅仅信贷团队，并同时为车金融业务线整个团队提供支持。
可以发现运营平台和应用服务模块都共用同一个数据库，运营平台各业务系统直连数据库。
四、重构历程
2018年下半年，时间自入职已过去半载。这期间，车金融业务线如雨后春笋般应运而生一批重构出来的新系统，譬如审核系统（poseidon）、收单系统(car-yulv)、金融产品系统(car-heil和car-product)、GPS审核系统(gps-web和gps-provider)、合同系统(doraemon)、贷后系统(car-afterloan)等等。然而这些业务系统面临的现状是，他们发现自己的业务场景都跟基础数据有相关联系。这时候相关业务系统，有的自己拆分出来自己的数据库，有的依然公用原来的那个数据库。而老系统也因为他们必需，所以开辟一些新接口提供这些有自己独立数据库的业务系统以便提供基础数据支持。
时光在需求迭代中不断流逝，业务的发展使得技术和产品也需要不断适应业务的规模发展和政策环境，不断自我创新。转眼间到了APP端第一次重构，当时重构团队内部有个响亮的代号“办单超人（后来又改称为‘办单侠’）”，由于需要提供APP端数据字典，因此这时候金融产品中心（这个时候依赖依然原来那个庞大的数据库）承担了这些接口服务职能，从而提供给辛巴系统服务。
后来考虑到金融产品中心需要进行拆库，但是拆库后，像数据字典，经销商单位门店是数据库冗余相关表，还是把这块独立出来一个服务调用其接口服务呢？
我经过深思熟虑，提出两种技术解决方案：
- 1、基于神州专车开源的项目DataLink实现数据源表同步。
- 2、搭建一个基础数据服务，基于原库提供基础数据接口服务。
第一种技术方案，在我的老东家神州专车其实是轻车熟路。这种技术解决方案的场景应用于各业务线内部相关系统依赖其他业务系统的基础表前提下，譬如司机系统依赖车型表，当时的技术方案就是，由架构团队通过数据同步平台实现数据源间同步。
或许你会提问，倘若依赖的数据库表字段定义变更怎么办？这个问题，架构组中间件团队设计之初自然考虑这个问题。平台支持全量表字段同步和按需指定字段同步两种选择方案，各业务系统可以选择其中一种方案以满足自己的场景需要。
我们又会意识到数据既然同步，肯定考虑数据一致性问题，比如延迟同步的时间差有多大。因此，倘若你想到这个问题，自然是因为本身业务对数据时时同步的苛刻要求，坦白讲，平台可以扩充增多的节点（worker）支撑业务规模的需要。起码这种延迟时间很小，可以忽略不计。
平台提供的这种数据同步特性，可以解决很多团队的数据依赖问题。通过这个平台，实现配置分离，可以解放更多的生产力，无需依赖的业务系统提供接口。
我们团队内部成员也赞成愿意尝试这种方案，毕竟车金融业务线当时调研过并没有实践应用，因此可以尝试一下。然而，出乎意料的是老板并不看好这个方案，他倾向于对方提供接口服务给业务方需要。
无奈，老板不赞成，咱也不能偷偷摸摸搞呗。后来其实我们忽略了一个重要的问题，这个数据同步平台配置提供数据源，所需数据库账户和密码，而当时DBA提供给各业务线的都是加密的密码，自然不会提供明文给业务线。后来，我们不得选择第二种方案，这也为基础数据平台的诞生奠定基础。
我们为了给各业务线提供基础数据服务，搭建了一个新的应用服务（car-transfer），最初我汉译称之为“传道士”，基础数据服务的主要宗旨就是提供业务方基础数据支持，所谓“授业传道者”是也。这个应用服务提供了最基本的数据查询，包括数据字典，经销商单位和门店，行政编码。
应用服务上线后，最先对接的自然是我们金融产品团队内部的业务系统，包括金融产品系统，GPS审核系统。然后我们又推广给信贷团队其他研发小组，先后对接了审核系统，提单系统，合同系统，贷后系统等。
五、架构设计
老板说过，既然基础服务为车金融业务线众多的业务系统提供接口服务，那么服务的稳定性则至关重要。鉴于此，我们为这一伟大目标在系统架构与设计中，通过研究取得了更多的创新设计成果。
吞吐量
服务的吞吐量，在分布式集群部署的前提下，我们可以增加服务器节点，以进而提升整体应用服务的吞吐量。如果考虑服务器成本的前提下，在苛刻的服务器成本预算下，我们则思考如何提升单节点的吞吐量，坦白讲，就是用一个节点，发挥多个节点的吞吐能力。
因此，基于单节点的前提下，我们在一些接口服务设计中，对于读多写少的场景下，通过增加一二级缓存（一级缓存本地缓存，二级缓存基于Redis分布式缓存），进而提高接口的QPS值。
一二级缓存的核心设计在于不同的业务模块，缓存管理是隔离的。每个独立的缓存模块，接口内部通过优先从一级缓存加载，一级缓存读不到，进而从二级缓存加载，二级缓存加载不到，最终从数据库读取加载，然后进而回调给一二级缓存。第二次接口调用时，在缓存周期不失效的前提下，就可以从一级缓存加载，以减少对数据库的频繁查询操作，充分利用缓存的性能进而提升服务的QPS和吞吐量。
缓存的第一次加载，设计成第一次被外部调用时才进行初始化。或许读者会发问，接口第一次被调用时，耗时肯定比较高。你说的没错，但目前这个耗时起码能够满足业务的发展规模。我们也可以在设计中，选择定时去检查一级缓存不在的情况下进行初始化加载，但这种目前设计实现其实没必要，只会增加系统设计的复杂性，我们选择简约设计从而实现业务目标，其所谓“Simple is perfect”是也。
有读者又会疑问，你们如何解决缓存的一致性问题。倘若你问道这个问题，我会告知你，这种情况下，如果数据库字段值变更，我们选择人工干预重置缓存。由于我们的数据很少变更，鉴于此，我们在基础数据平台提供了缓存管理功能，并提供了缓存模块的全量重置和指定数据重置两个纬度，以满足我们的业务场景需要。重置缓存简单讲，就是清空一二级缓存，重新从数据库加载刷新。
既然引入了缓存，我们也会考虑缓存击穿，缓存穿透，缓存雪崩这种严重问题，不过我可以告诉大家的，毕竟我们公司属于车金融行业，金融毕竟相比电商其他行业量级肯定很低。此外，我们的应用服务仅开放内网域名，况且我们的数据量不高，比如数据字典，当前的业务也就上万，所以是杞人忧天了。哈哈！
可用性
由于线上构建发布基于docker容器化，平台支持基于构建完成的应用服务镜像快速复制n个节点，因此这有利于我们可以快速摘除故障节点，重新创建一个新节点代替故障节点。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-T97T3Wlr-1605338279187)(images/7.png)]
平台提供的快速CI/CD构建，我们的服务恰好按照业务量部署了多个节点，通过nginx实现负载均衡。同时线上部署两个k8s集群，应用可以支持部署多个集群，有利于故障容灾和转移，所以服务不可用的几率几乎为零，除非这个k8s集群全部瘫痪，你想想这是可能的嘛。
六、推广大使
随着对接的业务系统越来越多，基础服务的目标定位也越来越清晰明确，它服务的宗旨就是提供给车金融各业务线支持，奠定基础数据服务的核心地位。
因此，我们团队下一步对接的工作重心就是APP的服务端应用-辛巴系统，毕竟APP上的一切功能都对接这个应用。我们跟辛巴团队，选择在需求迭代中，对接我们的这个应用服务（car-transfer）。就这样，我们就迈出了又一个新的里程碑，从信贷团队走向的辛巴研发团队，后来走向了薪资研发团队。
全部业务系统完成迁移对接后，我们的下一步工作目标就是，塑造基础数据平台的品牌形象，相关需求涉及的功能倘若可以服务多个业务系统，那我们欣然愿意该功能在基础数据平台做，是有必要的。伴随着它的名声在各团队传扬，我们实现了这一目标。
七、正定乾坤
伴随着车金融更多的研发团队的相关业务系统接入基础数据平台，我们后续又从老系统逐渐迁移其他相关接口服务，以丰富其功能从而壮大其力量。
我们完成从零开始搭建一个基础数据平台，其核心战略就是通过不断创新自我，保持我们金融产品团队的特色，确保我们的团队永葆青春绽放光芒。尽管后来老板想让我们团队交接出去这个基础数据服务，但作为见证其诞生又逐渐成长壮大的我，自然是不舍，更不愿意舍送他人。它就像我抚育的孩子一样，血溶于水，我期望在团队的带领下，可以永葆基础数据服务的光辉形象。
后来在金融产品，GPS审核系统陆续实现拆库后，我们也把基础数据服务依赖原老系统的相关业务表，拆分出一个新的数据库（car_transfer），最终实现完美的蜕变。
为了更好的宣传品牌形象，用油一个高大上的名字必不可少，我们当时带上金融产品平台一起奏上老板，赐了两个名字，所谓太初（基础数据平台），太极（金融产品平台）。然后又请我们的设计师，设计了LOGO，最终修成正佛，功成名就。
上述LOGO都是拜鹏大师（류패븡）给设计的，特别感谢。
八、尾语
基础数据平台，为车金融业务而生，为车金融业务发展而不断创新。一个系统应用的最大价值就是可以服务更多的业务系统，提供一个“超人”的能力。
我认为技术架构的本质在于为公司业务发展的实事求是之研究设计，而重构的本质是进一步提升系统的扩展性和伸缩性做出的不断努力尝试。
这篇文章背后讲述的故事和历程之所以成功，离不开背后团队以及老板其他团队的支持，这里对此表示感谢。
为了不透露他们的名字，这里选择以韩语标注名字，以铭记他们的大力支持。
鸣谢人员
| 团队 | 人员 |
|---|---|
| 金融产品团队 | 반강강 상영욱 조 신 리해토 장 진 |
| 收单系统 | 추정짐 후 월 |
| 审核系统 | 롱석서 강 평 이효동 명초롱 |
| 合同系统 | 장서교 |
| 贷后系统 | 이해회 강팅팅 |
| 辛巴团队 | 덩효롱 양흐욱 양 루 |
| 订单中心 | 엄방새 장신량 조격평 |
| 薪资团队 | 후레레 란용신 |
| 交互设计 | 잔 민 류패븡 |
| 运营团队 | 류효환 강임민 |
| 前端团队 | 상매립 우대명 |
| 产品团队 | 서군임 우효빈 |
| 其他 | Kevin 조엔 |
324
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
