有品：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