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