分散式系統中的資料儲存方案實踐

導讀	資料膨脹的時候，必然放大細節。

在專案研發的過程中，對於資料儲存能力的依賴無處不在，專案初期，相比系統層面的元件選型與框架設計，由於資料體量不大，在儲存管理方面通常容易被輕視，當專案發展進入到中後期階段，系統的複雜性很大程度來源於資料層面；

從常規的微服務架構體系來看，對於系統中的資料儲存可以劃分如下幾個模組：元件庫、應用庫、業務庫、公共庫、中介軟體資料、第三方；不同的場景下對資料儲存能力的要求和依賴程度也各不相同；

元件庫：微服務架構下，諸多基礎的框架元件都依賴資料的持久化儲存，以此來確保服務能力的穩定可控，避免異常情況下的資料丟失問題；

應用庫：作為系統中的應用層，需要對請求的動作有記錄和識別能力，並且儲存諸多攔截和過濾的規則資訊，用來維護下層業務服務的安全穩定；

業務庫：做為系統中最核心的資料資產，對業務資料的儲存和管理有極高的要求，並且要對資料的變化有一定的評估能力，提前做好資料膨脹的情況下系統測試和拆分方案，保障業務的穩定和持續發展；

公共庫：系統中大部分業務都可能會依賴的能力，對於公共庫和與之相應的服務來說，其吞吐量和併發能力，要支撐所有依賴業務的同時併發；

中介軟體：常見的中介軟體比如：快取、訊息佇列、任務排程、搜尋引擎等，都有資料儲存的性質，只是在實現方式上會有差異；

第三方：大部分系統都或多或少的依賴一些第三方倉庫，比如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服務協調多個倉庫實現流程自動化；

對於倉庫儲存的各種版本打包檔案，微服務架構下存在不同服務依賴同一服務不同版本的情況，另外不排除新老版本的介面存在邏輯衝突問題，此時可能需要版本回滾，重新依賴原有的分支包，再尋求問題的解決方案；關於程式碼工程涉及的相關儲存基本都是使用第三方的雲端倉庫，在管理維護方面比較簡單；

應用倉庫：
元件封裝：

原文來自：