本文作者：雲本開源系統架構師張志剛。張老師於2021年MongoDB中文社區長沙大會分享：MongoDB在金融行業的應用實踐。2021年MongoDB中文社區杭州大會將於7月3日（下週六）在杭州餘杭區舉辦，點擊鏈接即可瞭解詳情： https://sourl.cn/CWUgfP[/caption]
摘要
大數據時代背景下金融系統建設面臨重重挑戰，下邊我們分享基於MongoDB建設金融系統的案例。目前該項目已穩定運行4年，經受住了大數據量時的高性能、高可靠的考驗，也提升了金融系統的用戶體驗。
項目背景
在接到這個項目時，客戶主要面臨以下一些挑戰：歷史數據總量大，存儲成本高，且原系統隨着時間的推移，數據量也越來越多，查詢性能也越來越差，再加上計息日之後的查詢交易量暴增，已經無法滿足下游系統的使用，所以急需尋找一個成本低廉，性能高效穩定且能夠解決上述問題的系統建設方案。
爲了進一步挖掘存量數據的價值，分擔現有交易系統的查詢壓力，補足交易系統無法支持大時間跨度、大數據量及模糊查詢的短板，打通客戶360數據共享給交易系統的渠道，客戶迫切需要研發一套支持大數據量實時查詢、統計、分析服務的可彈性擴展，高可靠，高效率，全行統一的大數據共享系統。
面臨的主要挑戰
項目研發過程中，我們面臨的挑戰急需解決的主要問題是：
一、歷史存量數據量巨大。我們的金融客戶自成立以來，有近400億的客戶交易流水，數據總量高達55TiB，日均寫入數據量高達495282656條，日寫入數據文件大小300G左右，需向全省2400多個實體網點，提供面向客戶的“T+1”實時查詢服務。
二、系統需支持可彈性擴展數據量，每天都在增加計算能力和存儲容量，需彈性擴展。
三、系統需確保高可靠，大數據共享系統定位是向各類交易系統提供實時查詢服務，可靠性要求等同實時交易系統。
四、系統的響應速度必須足夠快，大數據共享系統服務的範圍廣，接入的渠道多，必須確保查詢速度足夠快。
五、系統需提供全文檢索及模糊查詢能力，業務人員的數據查詢需求廣泛，有時也不清晰，需提供引導式查詢服務能力。支持大數據量的全文檢索及模糊查詢能力。
技術選型
在技術選型的過程，我們結合客戶需求，最終選用MongoDB來滿足歷史數據查詢平臺，多查詢條件表結構低依賴性的需求。在下方的方案介紹部分，我們將一起看下爲什麼MongoDB可以滿足相關需求。
方案介紹
大數據共享系統的設計標準是可向全行所有系統提供“T+1”實時歷史數據查詢、統計及分析服務，該項目方案需研發設計的方案包括系統架構方案、多渠道集成方案、高可靠方案及高性能方案。具體方案介紹如下：
一、系統架構方案
本系統架構設計的目標是向全行所有交易系統的明細、統計查詢提供查詢服務，實現查詢服務的集中化、標準化管理和服務。因此，系統需要確保高可靠、高性能、可擴展能力，同時，要求既能提供前端設計服務，又能提供API接入服務，總體設計如下圖所示：
架構共分五層分別是數據存儲、業務管理、數據服務總線、報表開發及服務接入。其中數據存儲是採用了開源分佈式數據庫MongDB，實現了高可靠、可擴展，採用分佈式的微服務技術，研發的數據服務總線（DSB）實現了接口服務的統一化和標準化，以及高可靠和高性能，報表開發即功能業務，研發了自助查詢服務，是通過研發的敏捷報表前端，實現了前端報表設計服務，能支持業務系統的單點登錄集成。服務接入提供了統一、標準化的Https/Http、WebService的API服務。
二、可靠性方案
MongoDB採用分佈式部署方式，數據在多個節點中有副本，中間任何一個節點出現異常時，數據不丟失。MongoDB自帶HA方案，當主節點宕機後，通過選舉生成新的主節點。
ES採用多客戶機、多副本、多分片的部署方式，保證數據不丟失的同時提高數據載入效率。
微服務節點採用分佈式部署，負載均衡Nginx爲其作爲代理，任何一個節點出現異常時，其它服務節點可以繼續進行工作，負載均衡將新任務分配給其它服務節點繼續工作。
其它平臺功能提供運行監控，監控界面可以看到運行情況、使用情況、功能管理等，部份功能如數據加載過程出現異常時，通過連接短信平臺，即時通知到維護人員需要進行人工處理。
平臺管理數據採用PG數據庫存儲，節點間數據採取全量備份機制，Nginx實現負截均衡，PG服務器任何一個節點數據出現異常時，其他PG服務器可以繼續進行工作，並且負載均衡將新任務分配給其他服務器繼續工作。
三、高性能方案
性能優化原則：提高並行處理能力、減少不必要的數據處理、常用索引設置等。
MongoDB、PG、Elasticsearch採用分佈式部署，增加數據存取並行處理服務器數量，增加數據存取效率；
微服務框架基於負載均衡器，實現高負載高併發高轉發高可靠；
數據按日期分表，既保留歷史數據，又提高了了當前數據的查詢性能；
提供必要的預處理，處理工作分到系統空閒時間，減少查詢時重複處理，降低用戶等待時間。爲常用查詢條件映射字段構建索引，提高查詢性能。
技術創新
經過近一年的持續攻關，本項目從技術上和業務支撐上都有較多的突破創新,做到了六個“首次”：
一、首次使用開源分佈式數據庫MongDB服務聯機交易。經過近半年的生產環境考驗，在大數據量、高併發的環境下，達到了零故障。
二、首次使用微服務技術研發了分佈式的面向全行所有系統的數據服務總線（DSB，Data Services Bus）。在渠道接入開發過程中，開發效率顯著提高。
三、首次使用開源的ElasticSearch中間件實現了信貸業務全量數據的全文檢索。經過總結分析我行信貸業務全量數據，提煉出了近3000個核心關鍵詞及詞組，建立了信貸業務的詞庫，實現了全文檢索功能。
四、首次使用統計分析方法，持續提升用戶操作體驗。首次應用技術手段，落實以用戶爲中心的思想，實現了根據用戶操作習慣，自動動態調整前端界面排列。
五、首次實現了業務人員可在線自定義查詢。涉及查詢條件、計算方式等，業務人員更方面、快捷、精準的獲取數據，以便進行分析。
六、首次將近400億的歷史流水提供至全省所有網點，向客戶提供“T+1”歷史數據實時查詢，有效提升了客戶服務質量。
技術特點
該系統架構是採用了開源分佈式數據庫MongDB用於數據存儲、統計及分析，應用微服務技術，研發了數據服務總線（DSB），用於服務外部系統的數據查詢分析，並集成了Elasticsearch 實現全行的文本資料搜索引擎。技術特點分析如下：
一、可擴展。開源分佈式數據庫MongDB的存儲和計算能力可在線擴展，能保障業務連續性。
二、高可靠。經過實踐驗證，當集羣節點故障時，對業務無任何影響，恢復過程中，用戶無感知。並且，因DSB採用分佈式集羣的架構，不但能確保API的可靠性，性能也有足夠的保障。
三、高性能。在大數據量的實際情況下，性能足夠支持聯機交易查詢，生產實際情況達到了日均訪問量100W+，併發達到200的毫秒響應，並且，隨着數據量的持續增加，相比傳統小機加關係型數據庫的方案，性能優勢越發顯著。
四、接入高效。研發的微服務技術支持的DSB，後臺準備好數據後，前端只需按標準調用API即可，開發效率極高。
五、前端報表實現了動態調整。根據後臺記錄的用戶操作日誌，採用統計分析方法，根據用戶的操作習慣，實現了T+30的自動化調整前端查詢條件的動態自動排列。
運營情況
系統上線穩定運營已經4年了，單點集成技術接入了信貸管理系統，通過DSB接入了櫃面、智慧櫃檯、移動營銷終端、廳堂管理系統、票據管理系統、電子檔案系統和秒貸系統。截止當前，日均訪問量100W+，最高併發數達到了200。特別是櫃面和秒貸系統的接入，直接提供了聯機交易服務，根據實際運營情況監控顯示，前端響應效率達到了毫秒級，可靠性是零故障，這爲後續全系統接入奠定了堅實的基礎。
系統運行過程中，針對提供“T+1”數據服務的大數據量複雜查詢，實時監控響應效率，以及系統資源使用情況，並採用統計分析方法，分析用戶使用習慣日誌，優化查詢，響應效率顯著提升。同時，通過研發了面向全信貸業務數據的全文檢索功能，引導用戶精準定位所關注的數據，進一步提升了用戶獲取數據的效率，降低查詢過程中的工作量，用戶反響極好。
項目成效
項目上線已經4年了，不但獲得了用戶的認可，也經受住了大數據量時的高性能、高可靠的考驗。成效如下：
經濟效益方面：系統採用了8臺X86服務器，向全省提供了近400億數據的實時查詢，相比採用傳統的小機+關係型數據庫的方案，不但節省了硬件成本，還節省了數據庫的採購成本，具有極高的性價比。並且，由於採用了微服務接口，極大的節省了接入系統的服務接口開發成本。
社會效益方面：本系統在研發過程中特別強調了用戶體驗，特別是首次向用戶提供了信貸全量業務數據的全文搜索功能，性能高效，億級數據秒級響應，用戶反映很好，極大的提高了用戶使用系統開展業務分析的積極性。並且，研發了基於微服務架構的DSB（數據服務總線），極大的降低了其他系統接入時開發的工作量，技術人員反響積極。
小結
在整個項目研發過程中，爲了降低對其他需服務系統的影響，提高項目研發的質量，以及提高服務接入的效率和規範，積累的經驗有：
一、制定標準極其重要。標準包括微服務接口標準、數據存儲標準、項目開發標準、系統集成標準。各類標準的制定，極大的提高項目開發質量、接口開發效率和服務接入效率，有效的保障了項目能夠按時按質交付。
二、性能優化經驗需不斷積累。性能優化涉及到數據分片存儲策略設計、索引策略設計、數據庫數據CHUNK的持續監控、緩存策略設計、微服務接口策略設計等。索引設計應根據用戶的查詢訪問日誌記錄進行統計分析，進行索引字段調整；數據分佈不均時，響應性能下降明顯，需持續監控CHUNK；
三、項目過程管理不容懈怠。由於是第一次選用分佈式開源數據庫，並且數據量特別巨大，在項目研發過程中，碰到了很多的難題，各類標準制定、性能benchmark都是從0到1的過程，然而，我們始終堅持，提升用戶體驗爲核心，不斷持續優化系統操作體驗和性能，這是整個團隊對項目過程管理的嚴格把控不可或缺的。
隨着互聯網行業的蓬勃發展，各場景各類數據也越來越多，MongoDB是爲大數據而生的，提供sharding機制用於實現業務的水平擴展。應該說sharding提供了完善的業務數據和負載水平擴展的機制，對於物聯網、日誌系統、歷史數據系統和監控系統這類包含TB級海量數據的應用場景，使用MongoDB sharding是個不錯的選擇。
在生產環境中，sharding並不是必須的，並不是新業務起來的時候就馬上部署sharding集羣，只有當業務的數據量達到單個複製集無法支撐、或者業務的負載超過了複製集的服務能力的時候，才考慮部署sharding，畢竟相比複製集，sharding在部署和管理上都複雜很多。MongoDB複製集可以平滑升級到shard，所以當你真正需要sharding時，可以參考官方文檔（Convert a Replica Set to a Sharded Cluster）進行操作，文檔中提供了詳細的升級步驟。
目前開源數據庫衆多，大家可選的餘地很大，就會出現這樣的問題，這些數據庫哪個更好？其實這是一個僞命題，脫離了具體的業務場景來討論好壞是紙上談兵，沒有最好的，只有最合適的，誰也無法保證完全取代誰，各數據庫都在不停地完善自身。相信隨着社區的發展與產品的不斷迭代，MongoDB也會發展的越來越好。
總結起來，如果你的業務滿足一個或多個特點，那麼選擇MongoDB是個正確的決定：
- 無需要跨文檔或跨表的事務及複雜的join查詢支持 // 目前已經支持事務，join的支持也越來越好（考慮版本）。
- 敏捷迭代的業務，需求變動頻繁，數據模型無法確定。
- 存儲的數據格式靈活，不固定，或屬於半結構化數據。
- 業務併發訪問量大，需數千的QPS。
- TB級以上的海量數據存儲，且數據量不斷增加。
- 要求存儲的數據持久化、不丟失。
- 需要99.999%的數據高可用性，需要大量的地理位置查詢、文本查詢。
作者: 張志剛
廣州雲本開源軟件有限公司系統架構師
團隊介紹：
廣州雲本開源軟件有限公司，致力於爲客戶提供基於開源軟件的企業級服務，包括系統建設，軟件研發，開源軟件遠程支持服務、開源軟件使用治理、開源系統搶修、開源系統調優、開源系統巡檢、開源數據庫服務、開源架構設計、開源定製服務、開源主題培訓和開源技術規範文檔，解決企業在開源運維上所遇到的問題。
2021年MongoDB中文社區杭州大會就在下週六，諸多MongoDB技術分享和一手實踐乾貨在現場等你來！
~完～
添加小芒果微信（ID：mongingcom）進入中文用戶組技術交流羣。
MongoDB-全球領先的現代通用數據庫 點擊訪問MongoDB官網www.mongodb.com/zh[/caption]
Tapdata DaaS - 一站式實時數據融合平臺 (tapdata.net) 免費使用 Tapdata Cloud - 在線異構數據庫實時同步工具(cloud.tapdata.net)[/caption]