分散式系統中數據存儲方案實踐
數據膨脹的時候，必然放大細節。
一、背景簡介
在項目研發的過程中，對於數據存儲能力的依賴無處不在，項目初期，相比系統層面的組件選型與框架設計，由於數據體量不大，在存儲管理方面通常容易被輕視，當項目發展進入到中後期階段，系統的複雜性很大程度來源於數據層面；
從常規的微服務架構體系來看，對於系統中的數據存儲可以劃分如下幾個模組：組件庫、應用庫、業務庫、公共庫、中間件數據、第三方；不同的場景下對數據存儲能力的要求和依賴程度也各不相同；
組件庫：微服務架構下，諸多基礎的框架組件都依賴數據的持久化存儲，以此來確保服務能力的穩定可控，避免異常情況下的數據丟失問題；
應用庫：作為系統中的應用層，需要對請求的動作有記錄和識別能力，並且存儲諸多攔截和過濾的規則資訊，用來維護下層業務服務的安全穩定；
業務庫：做為系統中最核心的數據資產，對業務數據的存儲和管理有極高的要求，並且要對數據的變化有一定的評估能力，提前做好數據膨脹的情況下系統測試和拆分方案，保障業務的穩定和持續發展；
公共庫：系統中大部分業務都可能會依賴的能力，對於公共庫和與之相應的服務來說，其吞吐量和並發能力，要支撐所有依賴業務的同時並發；
中間件：常見的中間件比如：快取、消息隊列、任務調度、搜索引擎等，都有數據存儲的性質，只是在實現方式上會有差異；
第三方：大部分系統都或多或少的依賴一些第三方倉庫，比如Git程式碼倉庫、Maven包倉庫、Docker鏡像倉庫、行為埋點數據、OSS文件服務等；
二、框架組件
微服務架構的常用組件中，例如GateWay路由網關、Nacos註冊配置中心、Seata事務管理器等，都需要數據存儲機制；
路由網關：通常在網關庫中維護各個服務的路由地址和規則策略，以及黑白名單和流量管理等數據，雖然體量並不大，鑒於網關服務需要支撐流量的高並發，所以對數據的讀性能有要求，盡量降低請求在網關層的耗時；
註冊配置：統籌管理各個服務的配置數據，動態維護服務的註冊狀態，對存儲的穩定性和數據安全有極高要求，要確保各個環境是隔離開的，並且不能暴露生產環境的配置資訊；
事務管理：Seata組件提供高性能和易用的分散式事務管理能力，常規的事務調度過程需要依賴幾張關鍵的記錄表，通常需要進行分散式事務管理的介面，基本都是處理服務中的核心業務，既要保證穩定性也要支援高並發；
三、應用管理
應用層相對處於系統的上層，比如常見的門面服務，管理服務，控制中心等，通常在相應的庫中存儲請求記錄，特定的過濾和攔截策略，異常響應日誌，頁面的展示管理等；
通常來說由控制中心進行統一的管理和維護應用庫的配置數據，在各自的應用服務中直接查詢即可；從而避免重複實現各種基礎功能，同時將系統級的管理都放在控制中心服務，確保數據修改的入口單一，以便更好的監控動作日誌；
四、業務數據
作為系統最核心的數據資產，業務數據的精準維護一直都是核心事項，除了提供必要業務流程的數據存儲，還要支援數據的動態查詢分析，並且會隨著業務發展，數據的結構和體量也會不斷產生變化；
分庫分表：業務過度複雜的時候，會考慮庫的拆分，從而保證各個業務塊的相對穩定性；當某些表的數據量龐大時，會採用分表的方式，避免該表的處理時間過長從而影響整體性能；業務的庫表拆分並且基於微服務管理，是當下主流的架構模式；
數據維護：隨著業務的發展，數據體量和結構會隨之膨脹，從而引發品質問題，所以在日常開發中很多版本都會進行數據維護，比如：數據清洗、數據遷移、結構拆分等，從而更好的管理數據保證業務的持續性；
微服務架構下數據的動態維護是一個比較複雜的流程，要保證在處理過程中不停機，需要依賴中間的調度服務去完成數據的維護過程，在此期間應用服務優先從舊服務和庫中讀取未處理的數據，新數據入庫和查詢走新的服務，直到整個維護流程結束，再根據預設好的標識關閉舊服務請求並且下線即可；
五、快取管理
通常快取可以有效解決數據查詢時出現的性能問題，比如訪問量大變動不頻繁的熱點數據，或者流程中經常載入的常量配置，另外也會基於Redis做加鎖機制，一般採用鍵值對的方式管理數據讀寫；
值得注意的是，通常Redis庫與業務庫是具有一定的對應關係，例如訂單業務庫對應訂單快取庫，並且不建議訂單業務庫數據主體被寫入其他快取中，統一通過訂單服務的介面訪問即可，保證各個微服務的數據獨立性；
六、搜索引擎
當業務量大的時候，很難執行數據整體的條件檢索機制，比如常見的核心業務數據、系統產生的日誌或者動作埋點數據；需要引入搜索引擎的能力，這就涉及到業務庫數據向ElasticSearch組件同步的過程；
不同的業務場景中，通常採用不同的數據同步策略；針對即時性高的業務數據，通常數據入庫後執行寫入；日誌數據量大且流程解耦較高，自然存在一定的延時；分析類的數據則基於定時任務拉取即可；不管什麼數據路徑，都要重點關注業務庫和索引之間的數據結構和一致性問題；
七、消息隊列
消息隊列作為流程解耦的常用組件，對消息數據的生產和消費需要一定的監控手段，複雜的流程一旦中斷，需要進行二次重試的話，則需要調度各種參數和消息內容結構，來保證流程的最終完整性；
通常來說消息隊列處理的業務複雜性都很高，所以比較考驗流程設計的合理性，如果不統一管理消息的生產和消費的路徑，在微服務的架構下基於MQ做流程的分段解耦，如果出現流程中斷或者系統異常的情況，都很難對相關邏輯做二次調度；
八、日誌資訊
日誌作為系統中的基礎組件，記錄的相關數據在日常開發維護的過程中十分重要，從數據的整體來看大致分為系統運行日誌，通常基於ELK的方式，另外就是業務日誌，需要具備業務語義，通常採用AOP切面模式進行訂製開發；
由於日誌數據的體量很大，業務日誌一般會存放在單獨的庫內，並且同步到搜索引擎中，對於系統運行日誌則按照時段或者文件大小的策略直接寫入搜索引擎；值得注意的是存放日誌數據的ES也需要獨立部署，避免與核心的業務數據放在一起，當流量突然增長時產生的日誌數據會非常大；
九、文件管理
文件管理是系統中的複雜模組，由於涉及IO流很容易引發記憶體問題，所以文件服務基本都會獨立部署，鑒於文件數據丟失很難找回的情況，通常會把文件存儲到OSS雲端，在文件服務中會記錄各個文件的地址和描述以及業務應用場景；
由於文件的類型多種多樣，比如：PDF、Excel、Word、Csv、Xml等等，其數據處理的手段也各不相同，如果文件過大還需要切割分塊，同時文件管理的過程需要很多約定的規則，比較常見的就是大小限制，命名資訊，類型與編碼等；
十、持續集成
程式碼工程在版本的交付中，會產生多個分支和打包文件，持續集成的過程也涉及多個文件倉庫的維護管理，比如：Git程式碼倉庫、Maven私有製品倉庫、Docker鏡像倉庫、腳本文件倉庫等；通過Jenkins服務協調多個倉庫實現流程自動化；
對於倉庫存儲的各種版本打包文件，微服務架構下存在不同服務依賴同一服務不同版本的情況，另外不排除新老版本的介面存在邏輯衝突問題，此時可能需要版本回滾，重新依賴原有的分支包，再尋求問題的解決方案；關於程式碼工程涉及的相關存儲基本都是使用第三方的雲端倉庫，在管理維護方面比較簡單；
十一、參考源碼
應用倉庫：
//gitee.com/cicadasmile/butte-flyer-parent
組件封裝：
//gitee.com/cicadasmile/butte-frame-parent
