基礎資料為車金融各業務系統提供資料支撐，為實現這一巨集偉目標，我們研發團隊見證了一個從零開始，一路篳路藍縷以啟山林的歷程。讓我們開始瞭解那段歷程，回憶那段崢嶸歲月。作為見證這段歷程的我，譜寫一篇文章回憶那段春秋往事。

一、序言

最近推出《金融產品中心的前世今生》
《GPS稽核系統的前世今生》後，藉著興致使然，再推出此新作。整篇文章共計4400餘字，全是地鐵旅程中手機碼字，實屬不易。文筆不佳，敬請原諒。感謝讀者能夠認真閱讀完畢，相信你從中不少收穫和啟迪。感謝讀者的關注，我將後續繼續推出此係列文章。

（本文寫於2020年11月11日~2020年11月14日，定稿於2020年11月13日，插圖新增於2020年11月14日-週六，歷時4天，順義-大望路地鐵途中）

CSDN部落格系列專輯連載：重構之路

二、導讀

基礎資料平臺從零到誕生，前後經歷將近一年載的時間，為了推進這個專案的成立，自然背後離不開老闆的大力支援，以及我們金融產品團隊小夥伴的辛勤付出和不懈努力。

基礎資料平臺，作為車金融業務線一個上游的應用服務，對下游相關業務系統提供基礎資料資料的管理和服務。從業務上講，為整個辦單到放款整個業務流程環節提供基礎資料支援（譬如資料字典，行政編碼，經銷商單位和門店）。

此外，為了滿足公司業務的發展規模，支撐未來的業務增長，從專案立項之初，就從技術架構和應用服務效能，做出了大量的研發設計工作，取得了不錯的成果。

三、紛亂時代

入職之初，我所在的信貸團隊有一個老系統，提供給運營人員的功能管理包括基礎資料平臺相關功能的一部分，早期這些跟業務系統緊密聯絡的資料字典，行政編碼，經銷商單位和門店，由於並沒有一個統一的系統應用提供介面服務，而且各業務系統公用一個資料庫，因此都是自己去查詢資料為業務邏輯支援。

這些業務系統，諸如早期已經拆分的收單系統，合同系統，稽核系統等，儘管屬於不同的小組負責人，但是我們會經常發現查詢資料字典或經銷商單位門店的業務邏輯程式碼隨處可見，屢見不鮮。

畢竟雖然不屬於同一個應用，但是公用同一個資料庫，既然沒有一個應用服務提供介面。其實他們這種所為造成了系統後期業務拆分，留下一個詬病。倘若沒有這個詬病，也就不會有基礎資料平臺的誕生。歷史的需要，恰逢英雄的誕生。歷史的偶然，造就輝煌的時代。而我當然毛遂自薦，為團隊著想，願意抗下這個艱鉅任務。

在重構的過程中，由於金融產品跟資料字典和經銷商單位門店緊密聯絡，鑑於此，為了考慮今後系統架構和業務系統的定位清晰，我帶領團隊準備去統一搭建一個基礎資料平臺，提供給產品運營團隊使用；同時搭建一個基礎資料服務提供介面服務於不僅僅信貸團隊，並同時為車金融業務線整個團隊提供支援。

可以發現運營平臺和應用服務模組都共用同一個資料庫，運營平臺各業務系統直連資料庫。

四、重構歷程

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和吞吐量。

具體詳見文章：基於google guava和redis的一二級快取設計實現

快取的第一次載入，設計成第一次被外部呼叫時才進行初始化。或許讀者會發問，介面第一次被呼叫時，耗時肯定比較高。你說的沒錯，但目前這個耗時起碼能夠滿足業務的發展規模。我們也可以在設計中，選擇定時去檢查一級快取不在的情況下進行初始化載入，但這種目前設計實現其實沒必要，只會增加系統設計的複雜性，我們選擇簡約設計從而實現業務目標，其所謂“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 조엔