資料膨脹的時候，必然放大細節，
一、背景簡介
在專案研發的程序中，對于資料存盤能力的依賴無處不在，專案初期，相比系統層面的組件選型與框架設計，由于資料體量不大，在存盤管理方面通常容易被輕視，當專案發展進入到中后期階段，系統的復雜性很大程度來源于資料層面；
從常規的微服務架構體系來看，對于系統中的資料存盤可以劃分如下幾個模塊：組件庫、應用庫、業務庫、公共庫、中間件資料、第三方；不同的場景下對資料存盤能力的要求和依賴程度也各不相同；
組件庫：微服務架構下，諸多基礎的框架組件都依賴資料的持久化存盤，以此來確保服務能力的穩定可控，避免例外情況下的資料丟失問題；
應用庫：作為系統中的應用層，需要對請求的動作有記錄和識別能力，并且存盤諸多攔截和過濾的規則資訊，用來維護下層業務服務的安全穩定；
業務庫：做為系統中最核心的資料資產，對業務資料的存盤和管理有極高的要求，并且要對資料的變化有一定的評估能力，提前做好資料膨脹的情況下系統測驗和拆分方案，保障業務的穩定和持續發展；
公共庫：系統中大部分業務都可能會依賴的能力，對于公共庫和與之相應的服務來說，其吞吐量和并發能力，要支撐所有依賴業務的同時并發；
中間件：常見的中間件比如：快取、訊息佇列、任務調度、搜索引擎等，都有資料存盤的性質，只是在實作方式上會有差異；
第三方：大部分系統都或多或少的依賴一些第三方倉庫，比如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服務協調多個倉庫實作流程自動化；
對于倉庫存盤的各種版本打包檔案，微服務架構下存在不同服務依賴同一服務不同版本的情況，另外不排除新老版本的介面存在邏輯沖突問題，此時可能需要版本回滾，重新依賴原有的分支包，再尋求問題的解決方案；關于代碼工程涉及的相關存盤基本都是使用第三方的云端倉庫，在管理維護方面比較簡單；
十一、參考原始碼
應用倉庫：
https://gitee.com/cicadasmile/butte-flyer-parent
組件封裝：
https://gitee.com/cicadasmile/butte-frame-parent
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/499560.html
標籤：Java