一、背景簡介

在項目研發的過程中，對于數據存儲能力的依賴無處不在，項目初期，相比系統層面的組件選型與框架設計，由于數據體量不大，在存儲管理方面通常容易被輕視，當項目發展進入到中后期階段，系統的復雜性很大程度來源于數據層面；

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

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

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

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

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

中間件：常見的中間件比如：緩存、消息隊列、任務調度、搜索引擎等，都有數據存儲的性質，只是在實現方式上會有差異；

第三方：大部分系統都或多或少的依賴一些第三方倉庫，比如Git代碼倉庫、Maven包倉庫、Docker鏡像倉庫、行為埋點數據、OSS文件服務等；

二、框架組件

微服務架構的常用組件中，例如GateWay路由網關、Nacos注冊配置中心、Seata事務管理器等，都需要數據存儲機制；

路由網關：通常在網關庫中維護各個服務的路由地址和規則策略，以及黑白名單和流量管理等數據，雖然體量并不大，鑒于網關服務需要支撐流量的高并發，所以對數據的讀性能有要求，盡量降低請求在網關層的耗時；

注冊配置：統籌管理各個服務的配置數據，動態維護服務的注冊狀態，對存儲的穩定性和數據安全有極高要求，要確保各個環境是隔離開的，并且不能暴露生產環境的配置信息；

事務管理：Seata組件提供高性能和易用的分布式事務管理能力，常規的事務調度過程需要依賴幾張關鍵的記錄表，通常需要進行分布式事務管理的接口，基本都是處理服務中的核心業務，既要保證穩定性也要支持高并發；

三、應用管理

應用層相對處于系統的上層，比如常見的門面服務，管理服務，控制中心等，通常在相應的庫中存儲請求記錄，特定的過濾和攔截策略，異常響應日志，頁面的展示管理等；

通常來說由控制中心進行統一的管理和維護應用庫的配置數據，在各自的應用服務中直接查詢即可；從而避免重復實現各種基礎功能，同時將系統級的管理都放在控制中心服務，確保數據修改的入口單一，以便更好的監控動作日志；

四、業務數據

作為系統最核心的數據資產，業務數據的精準維護一直都是核心事項，除了提供必要業務流程的數據存儲，還要支持數據的動態查詢分析，并且會隨著業務發展，數據的結構和體量也會不斷產生變化；

分庫分表：業務過度復雜的時候，會考慮庫的拆分，從而保證各個業務塊的相對穩定性；當某些表的數據量龐大時，會采用分表的方式，避免該表的處理時間過長從而影響整體性能；業務的庫表拆分并且基于微服務管理，是當下主流的架構模式；

數據維護：隨著業務的發展，數據體量和結構會隨之膨脹，從而引發質量問題，所以在日常開發中很多版本都會進行數據維護，比如：數據清洗、數據遷移、結構拆分等，從而更好的管理數據保證業務的持續性；

微服務架構下數據的動態維護是一個比較復雜的流程，要保證在處理過程中不停機，需要依賴中間的調度服務去完成數據的維護過程，在此期間應用服務優先從舊服務和庫中讀取未處理的數據，新數據入庫和查詢走新的服務，直到整個維護流程結束，再根據預設好的標識關閉舊服務請求并且下線即可；

五、緩存管理

通常緩存可以有效解決數據查詢時出現的性能問題，比如訪問量大變動不頻繁的熱點數據，或者流程中經常加載的常量配置，另外也會基于Redis做加鎖機制，一般采用鍵值對的方式管理數據讀寫；

值得注意的是，通常Redis庫與業務庫是具有一定的對應關系，例如訂單業務庫對應訂單緩存庫，并且不建議訂單業務庫數據主體被寫入其他緩存中，統一通過訂單服務的接口訪問即可，保證各個微服務的數據獨立性；

六、搜索引擎

當業務量大的時候，很難執行數據整體的條件檢索機制，比如常見的核心業務數據、系統產生的日志或者動作埋點數據；需要引入搜索引擎的能力，這就涉及到業務庫數據向ElasticSearch組件同步的過程；

不同的業務場景中，通常采用不同的數據同步策略；針對即時性高的業務數據，通常數據入庫后執行寫入；日志數據量大且流程解耦較高，自然存在一定的延時；分析類的數據則基于定時任務拉取即可；不管什么數據路徑，都要重點關注業務庫和索引之間的數據結構和一致性問題；

七、消息隊列

消息隊列作為流程解耦的常用組件，對消息數據的生產和消費需要一定的監控手段，復雜的流程一旦中斷，需要進行二次重試的話，則需要調度各種參數和消息內容結構，來保證流程的最終完整性；

通常來說消息隊列處理的業務復雜性都很高，所以比較考驗流程設計的合理性，如果不統一管理消息的生產和消費的路徑，在微服務的架構下基于MQ做流程的分段解耦，如果出現流程中斷或者系統異常的情況，都很難對相關邏輯做二次調度；

八、日志信息

日志作為系統中的基礎組件，記錄的相關數據在日常開發維護的過程中十分重要，從數據的整體來看大致分為系統運行日志，通?；贓LK的方式，另外就是業務日志，需要具備業務語義，通常采用AOP切面模式進行定制開發；

由于日志數據的體量很大，業務日志一般會存放在單獨的庫內，并且同步到搜索引擎中，對于系統運行日志則按照時段或者文件大小的策略直接寫入搜索引擎；值得注意的是存放日志數據的ES也需要獨立部署，避免與核心的業務數據放在一起，當流量突然增長時產生的日志數據會非常大；

九、文件管理

文件管理是系統中的復雜模塊，由于涉及IO流很容易引發內存問題，所以文件服務基本都會獨立部署，鑒于文件數據丟失很難找回的情況，通常會把文件存儲到OSS云端，在文件服務中會記錄各個文件的地址和描述以及業務應用場景；

由于文件的類型多種多樣，比如：PDF、Excel、Word、Csv、Xml等等，其數據處理的手段也各不相同，如果文件過大還需要切割分塊，同時文件管理的過程需要很多約定的規則，比較常見的就是大小限制，命名信息，類型與編碼等；

十、持續集成

代碼工程在版本的交付中，會產生多個分支和打包文件，持續集成的過程也涉及多個文件倉庫的維護管理，比如：Git代碼倉庫、Maven私有制品倉庫、Docker鏡像倉庫、腳本文件倉庫等；通過Jenkins服務協調多個倉庫實現流程自動化；

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

十一、參考源碼

應用倉庫：
https://gitee.com/cicadasmile/butte-flyer-parent

組件封裝：
https://gitee.com/cicadasmile/butte-frame-parent