一、背景簡介

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

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

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

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

業(yè)務庫：做為系統(tǒng)中最核心的數(shù)據(jù)資產(chǎn)，對業(yè)務數(shù)據(jù)的存儲和管理有極高的要求，并且要對數(shù)據(jù)的變化有一定的評估能力，提前做好數(shù)據(jù)膨脹的情況下系統(tǒng)測試和拆分方案，保障業(yè)務的穩(wěn)定和持續(xù)發(fā)展；

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

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

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

二、框架組件

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

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

注冊配置：統(tǒng)籌管理各個服務的配置數(shù)據(jù)，動態(tài)維護服務的注冊狀態(tài)，對存儲的穩(wěn)定性和數(shù)據(jù)安全有極高要求，要確保各個環(huán)境是隔離開的，并且不能暴露生產(chǎn)環(huán)境的配置信息；

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

三、應用管理

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

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

四、業(yè)務數(shù)據(jù)

作為系統(tǒng)最核心的數(shù)據(jù)資產(chǎn)，業(yè)務數(shù)據(jù)的精準維護一直都是核心事項，除了提供必要業(yè)務流程的數(shù)據(jù)存儲，還要支持數(shù)據(jù)的動態(tài)查詢分析，并且會隨著業(yè)務發(fā)展，數(shù)據(jù)的結構和體量也會不斷產(chǎn)生變化；

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

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

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

五、緩存管理

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

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

六、搜索引擎

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

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

七、消息隊列

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

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

八、日志信息

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

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

九、文件管理

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

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

十、持續(xù)集成

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

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

十一、參考源碼

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

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