目錄
- 一、簡介
- 二、快取管理
- 三、訊息佇列
- 四、搜索引擎
- 五、定時任務
- 六、資料存盤
- 七、參考原始碼
有品：There is no silver bullet；
一、簡介
在微服務工程的技術選型中，會涉及到很多組件的集成，最常用包括：快取、訊息佇列、搜索、定時任務、存盤等幾個方面；
如果工程是單服務，對于集成組件的管理來說并不算復雜；但是在分布式的多服務系統中，隨著拆分的服務數量上升，統一管理各種組件的復雜度也會提高；
如上圖，是團隊內部維護的一份重要的系統清單：描述整個微服務體系中核心組件的依賴情況；【并不完整】
在整個工程內部拆分了幾十個服務，基于一份系統架構圖和一份組件依賴清單，如果熟悉微服務架構模式，可以非常快速的了解系統的基礎原理和結構；
復雜系統對于中間件的依賴很重，需要在實踐程序中不斷的積累和總結經驗，持續優化各種組件的應用策略；
對于組件來說，與專案工程的集成模式，核心的應用場景，以及在業務場景中的迭代優化，是研發需要重點關注的方面；
二、快取管理
【集成模式】
Redis作為最常見的快取選型，在與分布式工程集成時，其形式也存在很大的靈活度；
單服務：在分布式工程中，如果服務使用獨立的Redis組件，通常是該服務支持的業務場景比較獨特，比如高并發或者資料體量較大等；
分布式服務：微服務常見的集成方式，不同的服務使用同一個Redis的不同DB編號，其他服務必須通過該服務的介面訪問其快取資料；
快取中心：整個工程基于一個快取中心服務來管理，其適配的業務場景比較特殊，多個服務緊密協作，調度和處理相同的資料主體；
在實際的分布式系統中，通常是模式一和模式二兩種都采用，而模式三更多的是應對特殊的需求場景；
【應用方式】
雖然Redis可以極大的提升效率，但是在實際的應用中，涉及最多的就是資料快取和加鎖兩個核心能力，對于組件的API使用并不算復雜；
無論是在框架層面的淺封裝一層，還是圍繞Redis組件撰寫常用的工具方法，都可以很好的實作工程和Redis相關API之間的解耦；不同服務之間快取資料獲取，需要通過各個服務提供的介面進行查詢；
三、訊息佇列
【集成模式】
Kafka作為訊息佇列的常見技術選型，在與分布式工程集成時，在設計上會圍繞訊息生產和消費的基本模式；
服務內集成：在各個服務內部直接引入訊息組件，服務可能是訊息生產者也可能是消費者，當重度依賴訊息通信時，流程可維護性比較差；
訊息服務封裝：單獨封裝訊息生產和消費兩個服務，來統一調度和管理訊息通信，雖然提高了技術面的復雜度，但是極大降低了異步流程的管理難度；
在實際應用時，如果工程內對于訊息的使用并不高頻，通常是采用模式一的策略，建議做好流程注釋和檔案維護；如果訊息使用非常高頻，可以考慮模式二的策略，減輕組件維護的難度；
【應用方式】
生產和消費能力追求平衡，即便有偏差也只能是訊息的【消費】大于【生產】的效率，才能避免訊息堆積從而影響正常的業務流程；
實踐來看單純的基于MQ的重試機制，并不能穩定的解決分布式架構中復雜流程的中斷問題，需要圍繞訊息的存盤設計相應的調度策略，從而推動整個流程的完整執行，無論是向下推進還是向前回滾；
四、搜索引擎
【集成模式】
對于搜索引擎Elasticsearch來說，個人感覺在常規業務場景中是最容易出問題的組件，使用ES索引的資料模型，通常結構復雜并且資料體量偏大，還涉及到大量的檢索條件；
服務內管理索引和資料：通常是核心的業務場景，對資料的實時性要求極高，從常規的架構設計來考慮，雖然索引相關的結構和資料可能來自多個資料庫，但是其管理的介面會統一封裝在業務聯系最密切的服務內；
獨立組件管理索引資料：基于獨立的組件（常用Logstash）進行調度，動態地采集、轉換和傳輸資料，不受格式或復雜度的影響，資料往往以各種各樣的形式，或分散或集中地存在于很多系統中；
無論是模式一還是模式二，都是ES常用的集成策略，比如模式一對于核心資料模型的構建，常見于訂單或商品等，模式二的經典用法之一ELK日志采集等；
【應用方式】
以服務內部管理索引的方式來說，多數情況下索引的結構會不斷的擴展，結構更新必然也會引起資料和檢索條件的同步更新，如果是結構新增的方式更新，管理難度并不大，但是已有欄位的型別更新，還需要索引重建；
對于ES這種操作起來比較復雜的技術組件，建議是把各種常用的操作撰寫程式腳本來處理，并且開發相應的管理功能，用更加穩定可控的方式來管理索引的結構和資料調度；
五、定時任務
【集成模式】
Quartz任務調度組件，在分布式系統中并不算復雜，基于定時器去觸發各種任務執行即可；
服務內構建定時器：在一些簡單的相對獨立的服務中，可以在服務內配置定時器，去執行相應的任務流程，這種模式在復雜的分布式系統中很難維護；
獨立的任務調度服務：可以統一管理任務的調度策略和執行方式（比如同步或異步），同時對任務調度服務進行監控和維護，以此確保任務調度系統的穩定性和可靠性；
通常模式一只會在個別獨立的服務中采用，對于模式二來說，封裝獨立的任務調度服務，可以統一與其他服務進行集成或者通信，比如通過訊息服務及時通知失敗的任務等；
【應用方式】
在任務調度服務中，難免要和其他服務進行通信互動，從而觸發相關任務的執行，如果系統內部定時任務不多的話，可以采用feign介面的方式觸發，如果任務非常多，可以考慮直接構建Http請求的方式，避免服務頻繁的升級迭代；
在調度任務中可能存在資料體量比較大的場景，通常就是采用分片演算法加執行緒池并發處理的策略，但是前提也要優化好資料查詢和任務處理流程，從整體上提升任務的執行效率；
六、資料存盤
【集成模式】
以MySQL為代表的資料存盤是系統中最核心的一層，其集成的形式也是靈活多變，與存盤層相關的組件更是五花八門；
多服務共用資料庫：對于模式一來說，在相對簡單的系統中比較常用，或者服務和資料庫本身偏向通用的功能性質，可以采用這種策略；
服務和庫的拆分：模式二是分布式架構中最常用的設計，每個服務都具有自己相應的獨立資料庫，其他服務想要訪問必須通過呼叫相應服務提供的介面才可以；
多資料源模式：在一個服務內集成多個資料源，像模式三讀寫分離和模式四分庫分表，這是偏資料服務的業務場景中經常使用的模式；
對于系統中的資料源管理本身就是一件復雜的事情，需要兼顧各個方面，比如資料讀寫性能，資料安全，以及服務的穩定性等；
【應用方式】
在常規的微服務工程中，通常每個服務都會使用各自獨立的資料庫，在多資料源的集成模式中，常用的邏輯就是動態路由、讀寫分離、分庫分表等，如果邏輯簡單可以自定義封裝，如果邏輯復雜可以使用成熟的組件；
服務集成多資料源的模式中，存在一個比較明顯的復雜問題，如何在不停止服務的情況下，進行資料源的動態管理，此前實踐過的模式：提供不同資料源的適配服務來實作各自的策略，在完成資料源的動態調整后，停止其中舊服務即可，雖然流程偏重偏復雜，但是穩定可靠；
七、參考原始碼
編程檔案：
https://gitee.com/cicadasmile/butte-java-note
應用倉庫：
https://gitee.com/cicadasmile/butte-flyer-parent
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/555537.html
標籤：架構設計
下一篇：返回列表