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