一般而言中間件和框架的區(qū)別是，中間件是獨(dú)立運(yùn)行的用于處理某項(xiàng)專門業(yè)務(wù)的CS程序，會(huì)有配套的客戶端和服務(wù)端，框架雖然也是處理某個(gè)專門業(yè)務(wù)的但是它不是獨(dú)立程序，是寄宿在宿主程序進(jìn)程內(nèi)的一套類庫(kù)。

圖上綠色部分代表了框架，紅色部分代表了管理系統(tǒng)，紫色部分代表了中間件。本文會(huì)著重介紹管理系統(tǒng)和中間件部分。

配置管理

比較知名的分布式配置服務(wù)和管理系統(tǒng)有攜程的https://github.com/ctripcorp/apollo（上圖）以及https://github.com/knightliao/disconf。對(duì)于比較大型的互聯(lián)網(wǎng)項(xiàng)目來說，因?yàn)闃I(yè)務(wù)繁雜，需求多變，往往各種系統(tǒng)都會(huì)有大量的配置，覆蓋幾個(gè)方面：

· 針對(duì)系統(tǒng)內(nèi)部技術(shù)層面的各種配置，各種池的大小、 隊(duì)列的大小、日志級(jí)別、各種路徑、批次大小、處理間隔、重試次數(shù)、超時(shí)時(shí)間等。

· 針對(duì)業(yè)務(wù)運(yùn)營(yíng)層面的各種配置，活動(dòng)的周期獎(jiǎng)勵(lì)、黑白名單、彈窗、廣告位等。

· 針對(duì)運(yùn)維和發(fā)布層面的配置，灰度名單、注冊(cè)中心地址、數(shù)據(jù)庫(kù)地址、緩存地址、MQ地址等。

因?yàn)橐恍┗A(chǔ)組件比如SOA框架和發(fā)布系統(tǒng)也會(huì)用到配置，這個(gè)時(shí)候就會(huì)可能會(huì)有雞生蛋的問題，這里我比較建議把配置系統(tǒng)作為最最底層的系統(tǒng)，其它服務(wù)都可以依賴配置系統(tǒng)。一般而言配置管理除了實(shí)現(xiàn)最基本的Key-Value的配置讀取和配置之外，還會(huì)有下面的一些特性和功能：

· 高性能。配置服務(wù)的壓力會(huì)是非常嚇人的，在一次服務(wù)調(diào)用中可能就會(huì)有幾十次的配置調(diào)用，如果服務(wù)的整體QPS在500那么配置服務(wù)的壓力可能在1萬的QPS，這樣的QPS不走緩存基本是不可能的。好在即使是1萬甚至是5萬的QPS也不算一個(gè)很夸張的無法解決的壓力。

· 高可用?，F(xiàn)在各種開源的配置服務(wù)是所謂的分布式配置服務(wù)，由可擴(kuò)展的配置服務(wù)集群來承擔(dān)負(fù)載均衡和高可用功能，配置服務(wù)一旦掛了可能會(huì)讓系統(tǒng)癱瘓。你可能會(huì)說配置服務(wù)一般本地會(huì)有緩存，會(huì)有本地的配置文件作為后備，會(huì)有默認(rèn)值，但是因?yàn)榕渲檬沁\(yùn)營(yíng)運(yùn)維在實(shí)時(shí)修改的，如果某個(gè)業(yè)務(wù)的配置沒有使用最新的配置走的是錯(cuò)誤的默認(rèn)值的話，系統(tǒng)會(huì)處于完全混亂的狀態(tài)，所以配置服務(wù)的穩(wěn)定性太重要了。

· 樹形的配置體系。如果只是把所有配置堆在一個(gè)列表里，加上項(xiàng)目和分類的話，當(dāng)配置多達(dá)幾千項(xiàng)的時(shí)候還是會(huì)有點(diǎn)多?？梢灾С謽湫蔚膶蛹?jí)配置，不拘泥于項(xiàng)目和分類這兩個(gè)條件。項(xiàng)目下可以有模塊，模塊下可以有分類，分類下可以有小類，根據(jù)自己的需求動(dòng)態(tài)構(gòu)建配置樹。

· 好用的客戶端。比如可以和SpringBoot以及@Value注解結(jié)合起來，非侵入整合配置系統(tǒng)，無需任何代碼的改動(dòng)。

· 毫秒級(jí)粒度的修改實(shí)時(shí)生效。可以使用長(zhǎng)連接推的方式實(shí)現(xiàn)，也可以實(shí)現(xiàn)緩存失效的方式實(shí)現(xiàn)。

· 配置的分層隔離。包括按照環(huán)境、集群和項(xiàng)目來提供多套配置相互獨(dú)立不影響，包括可以以層級(jí)的方式做配置繼承。

· 配置的權(quán)限控制。不同類型、環(huán)境、集群、項(xiàng)目的配置具有不同的管理權(quán)限，比如脫敏只讀、只讀、讀寫、導(dǎo)出。

· 配置的版本管理。配置的每一次修改都是一個(gè)版本，可以為單獨(dú)的配置或項(xiàng)目進(jìn)行直接版本回滾。

· 豐富的Value形式。配置的Value如果要保存列表的話，保存一個(gè)JSON閱讀和修改都不方便，可以直接提供List方式的Value，在后臺(tái)可以單獨(dú)增刪改里面的一項(xiàng)。在比如黑名單的引用上這種方式比較高效，否則更新一個(gè)名單每次都要修改整個(gè)黑名單。這個(gè)功能可以和Redis結(jié)合在一起進(jìn)行實(shí)現(xiàn)。Value除了支持字符串可以是JSON和XML形式，系統(tǒng)可以對(duì)格式進(jìn)行格式化，對(duì)格式進(jìn)行校驗(yàn)。Value也可以是非字符串類型的各種數(shù)字格式，系統(tǒng)也會(huì)根據(jù)類型進(jìn)行校驗(yàn)。

· 豐富的配置發(fā)布生效形式。比如可以自然生效、立即生效以及定時(shí)生效。定時(shí)生效的功能適合于在某個(gè)時(shí)間點(diǎn)需要開啟某個(gè)配置，比如用于面向用戶的推送、活動(dòng)業(yè)務(wù)。還有支持灰度自動(dòng)發(fā)布，以一定的時(shí)間間隔來對(duì)集群里的實(shí)例進(jìn)行發(fā)布，避免人工去定期逐一發(fā)布單臺(tái)的麻煩。

· 審核審計(jì)功能。配置的修改可以由管理員進(jìn)行審核（也就是修改和發(fā)布的權(quán)限支持分離），避免配置錯(cuò)誤修改。所有配置的修改記錄可以查詢到誰什么時(shí)候因?yàn)槭裁丛蛐薷牧耸裁磁渲?，事后可以審?jì)審查。

· 配置生效跟蹤和使用率跟蹤?？梢钥吹矫恳粋€(gè)配置項(xiàng)現(xiàn)在哪些客戶端在使用，生效的值的版本是哪個(gè)。通過這個(gè)功能還可以排查現(xiàn)在系統(tǒng)中過去一段時(shí)間從沒有用過的配置，刪除無用的配置。

· 動(dòng)態(tài)配置。在API設(shè)計(jì)的時(shí)候我們引入上下文的概念，通過傳入一個(gè)Map字典作為上下文，比如某個(gè)配置按照不同的用戶類型、城市需要有不同的值，這個(gè)邏輯我們可以不需要在代碼里面手工編寫，直接通過在后臺(tái)配置上下文的匹配策略來動(dòng)態(tài)讀取到不同的配置值。

· 本地快照。對(duì)配置進(jìn)行快照本地保存，在出現(xiàn)故障無法連接服務(wù)端的時(shí)候使用本地的配置。

這里可以看到要實(shí)現(xiàn)一個(gè)功能完善的配置系統(tǒng)工作量還是相當(dāng)大的，一個(gè)優(yōu)秀的功能強(qiáng)大的配置系統(tǒng)可以節(jié)省很多開發(fā)的工作量，因?yàn)榭膳渲貌糠值墓δ芑揪褪怯膳渲孟到y(tǒng)直接實(shí)現(xiàn)了，無需在數(shù)據(jù)庫(kù)中在搞大量的XXConfig表（不夸張的說，很多業(yè)務(wù)系統(tǒng)40%的工作量在這個(gè)上面，不但需要做這些配置表還需要配以配置后臺(tái)）。

服務(wù)管理

微服務(wù)的建設(shè)中實(shí)現(xiàn)遠(yuǎn)程調(diào)用只是實(shí)現(xiàn)了20%的工作量（但是確實(shí)滿足了80%的需求）。服務(wù)管理治理這塊有大量的工作要做。這也就是實(shí)現(xiàn)自己RPC框架的好處，這是第一步，有了這第一步讓數(shù)據(jù)流過我們自己的框架以后我們接可以做更多的事情，比如：

· 調(diào)用鏈跟蹤。能否記錄整個(gè)調(diào)用的情況，并且查看這個(gè)調(diào)用鏈。下面一節(jié)會(huì)再說一下這點(diǎn)。

· 注冊(cè)管理。查看服務(wù)的注冊(cè)情況，服務(wù)手動(dòng)上線下線，集群切換，壓力分配干預(yù)。

· 配置管理。配置服務(wù)端客戶端線程池和隊(duì)列的配置，超時(shí)配置等等。當(dāng)然，這個(gè)也可以在配置系統(tǒng)中進(jìn)行。

· 運(yùn)維層面的管理。查看和管理方法熔斷，進(jìn)行并發(fā)限流配置，服務(wù)權(quán)限黑白名單配置，安全方面的配置（信息加密，日志脫敏等）。

· Service Store的概念。服務(wù)發(fā)布需要滿足一定要求，有文檔（比如可以通過注解方式在代碼注釋里提供），有信息（開發(fā)負(fù)責(zé)人、運(yùn)維負(fù)責(zé)人，服務(wù)類型，提供的能力），滿足要求后就可以以類似于蘋果App Store發(fā)布程序的方式發(fā)布服務(wù)，這樣我們就可以在統(tǒng)一的平臺(tái)上查看服務(wù)的維護(hù)信息和文檔。

· 版本控制調(diào)用統(tǒng)計(jì)。對(duì)服務(wù)進(jìn)行灰度升級(jí)，按版本路由，不同版本調(diào)用分析等等。類似于一些應(yīng)用統(tǒng)計(jì)平臺(tái)提供的功能（友盟、TalkingData）。

這里我想說的理念是，服務(wù)能調(diào)用通是第一步，隨著服務(wù)數(shù)量變多，部署方式的復(fù)雜化，依賴關(guān)系復(fù)雜化，版本的迭代，API的變更，開發(fā)人員和架構(gòu)師其實(shí)急需有一套地圖能夠?qū)Ψ?wù)能力的全貌進(jìn)行整體的了解，運(yùn)維也需要有系統(tǒng)能對(duì)服務(wù)進(jìn)行觀察和調(diào)配。服務(wù)治理的部分完全可以以iOS那套（開發(fā)符合時(shí)候需要符合標(biāo)準(zhǔn)+發(fā)布的時(shí)候需要有流程）方式來運(yùn)作。

全鏈路監(jiān)控

開源的實(shí)現(xiàn)有https://github.com/dianping/cat以及https://github.com/naver/pinpoint（上圖）等等。對(duì)于微服務(wù)比較多的（主流程涉及8+微服務(wù)）系統(tǒng)，如果沒有服務(wù)的全鏈路調(diào)用跟蹤那么排查故障以及性能問題就會(huì)很困難了。一般完善的全鏈路監(jiān)控體系不僅僅覆蓋微服務(wù)，而且功能也會(huì)更豐富，實(shí)現(xiàn)下面的功能：

· 以Log、Agent、Proxy或整合進(jìn)框架的方式實(shí)現(xiàn)，盡可能少的侵入的情況下實(shí)現(xiàn)數(shù)據(jù)的收集。而且確保數(shù)據(jù)的收集不會(huì)影響到主業(yè)務(wù)，收集服務(wù)端宕機(jī)的情況下業(yè)務(wù)不影響。

· 調(diào)用跟蹤。涉及到服務(wù)調(diào)用、緩存調(diào)用、數(shù)據(jù)庫(kù)調(diào)用，MQ調(diào)用，不僅僅可以以樹的形式呈現(xiàn)每次調(diào)用的類型、耗時(shí)、結(jié)果，還可以呈現(xiàn)完整的根，也就是對(duì)于網(wǎng)站請(qǐng)求呈現(xiàn)出請(qǐng)求的完整信息，對(duì)于Job任務(wù)呈現(xiàn)出Job的信息。

· JVM的信息（比如對(duì)于Java）。呈現(xiàn)每一個(gè)進(jìn)程JVM層次的GC、Threads、Memory、CPU的使用情況?？梢赃M(jìn)行遠(yuǎn)程Stack的查看和Heap的快照（沒有進(jìn)程的內(nèi)存信息，很多時(shí)候基于服務(wù)器層面粗粒度的資源使用情況的監(jiān)控，基本不可能分析出根本原因），并且可以設(shè)定策略進(jìn)行定期的快照。虛擬機(jī)的信息查看和調(diào)用跟蹤甚至可以通過快照進(jìn)行關(guān)聯(lián)，在出現(xiàn)問題的時(shí)候能夠了解當(dāng)時(shí)虛擬機(jī)的狀態(tài)對(duì)于排查問題是非常有好處的。

· 依賴關(guān)系一覽。有的時(shí)候我們做架構(gòu)方案，第一步就是梳理模塊和服務(wù)之間的依賴關(guān)系，只有這樣我們才能確定影響范圍重構(gòu)范圍，對(duì)于微服務(wù)做的比較復(fù)雜的項(xiàng)目來說，每個(gè)人可能只是關(guān)注自己服務(wù)的上下游，對(duì)于上游的上游和下游的下游完全不清楚，導(dǎo)致公司也沒有人可以說的清楚架構(gòu)的全貌。這個(gè)時(shí)候我們有全鏈路跟蹤系統(tǒng)的話，可以對(duì)通過分析過去的調(diào)用來繪制出一張依賴關(guān)系的架構(gòu)圖。這個(gè)圖如果對(duì)QPS做一些熱點(diǎn)的話，還可以幫助我們做一些運(yùn)維層面的容量規(guī)劃。

· 高級(jí)分析建議。比如在全鏈路壓測(cè)后定位分析瓶頸所在。定時(shí)分析所有組件的執(zhí)行性能，得出性能衰退的趨勢(shì)，提早進(jìn)行問題預(yù)警。分析JVM的線程和GC情況，輔助定位High CPU和Memory Leak的問題。退一萬步說，即使沒有這樣的自動(dòng)化的高級(jí)分析，有了調(diào)用跟蹤的圖和組件依賴關(guān)系圖，至少在出問題的時(shí)候我們?nèi)四芊治龀鰜碚厥隆?/p>

· Dashboard。非必須，只要數(shù)據(jù)收集足夠全面，如之前文章所示，我們可以用Grafana來進(jìn)行各種個(gè)性化的圖表配置。

數(shù)據(jù)訪問中間件

開源的實(shí)現(xiàn)有C實(shí)現(xiàn)的https://github.com/Qihoo360/Atlas以及Go實(shí)現(xiàn)的https://github.com/flike/kingshard 等。數(shù)據(jù)訪問中間件是獨(dú)立部署的數(shù)據(jù)庫(kù)的透明代理，本身需要是以集群方式支持高可用，背后還需要對(duì)接多套數(shù)據(jù)庫(kù)作為一個(gè)集群，一般而言會(huì)提供如下的功能：

· 最常用的功能就是讀寫分離。也包括負(fù)載均衡和故障轉(zhuǎn)移的功能，自動(dòng)在多個(gè)從庫(kù)做負(fù)載均衡，通過可用性探測(cè)，在主庫(kù)出現(xiàn)故障的時(shí)候配合數(shù)據(jù)庫(kù)的高可用和復(fù)制做主庫(kù)的切換。

· 隨著數(shù)據(jù)量的增多需要分片功能。分片也就是Sharding，把數(shù)據(jù)按照一定的維度均勻分散到不同的表，然后把表分布在多個(gè)物理數(shù)據(jù)庫(kù)中，實(shí)現(xiàn)壓力的分散。這里寫入的Sharding一般而言沒有太多的差異，但是讀取方面因?yàn)樯婕暗綒w并匯總的過程，如果要實(shí)現(xiàn)復(fù)雜功能的話還是比較麻煩的。由于分片的維度往往可能有多個(gè)，這方面可以采用多寫多個(gè)維度的底層表來實(shí)現(xiàn)也可以采用維度索引表方式來實(shí)現(xiàn)。

· 其它一些運(yùn)維方面的功能。比如客戶端權(quán)限控制，黑白名單，限流，超時(shí)熔斷，和調(diào)用鏈搭配起來的調(diào)用跟蹤，全量操作的審計(jì)搜索，數(shù)據(jù)遷移輔助等等。

更高級(jí)的話可以實(shí)現(xiàn)SQL的優(yōu)化功能。隨時(shí)進(jìn)行SQL的Profiler，然后達(dá)到一定閾值后提供索引優(yōu)化建議。類似https://github.com/Meituan-Dianping/SQLAdvisor。

· 其它。極少的代理實(shí)現(xiàn)了分布式事務(wù)的功能（XA）。還可以實(shí)現(xiàn)代理層面的分布式悲觀鎖的功能。其實(shí)細(xì)想一下，SQL因?yàn)椴⒉皇侵苯尤拥綌?shù)據(jù)庫(kù)執(zhí)行，這里的可能性就太多了，想干啥都可以。

實(shí)現(xiàn)上一般需要做下面幾件事情：

· 有一個(gè)高性能的網(wǎng)絡(luò)模型，一般基于高性能的網(wǎng)絡(luò)框架實(shí)現(xiàn)，畢竟Proxy的網(wǎng)絡(luò)方面的性能不能成為瓶頸。

· 有一個(gè)MySQL協(xié)議的解析器，開源實(shí)現(xiàn)很多，拿過來直接用即可。

· 有一個(gè)SQL語法的解析器，Sharding以及讀寫分離免不了需要解析SQL，一般流程為SQL解析、查詢優(yōu)化、SQL路由、SQL重寫，在把SQL提交到多臺(tái)數(shù)據(jù)庫(kù)執(zhí)行后進(jìn)行結(jié)果歸并。

· Proxy本身最好是無狀態(tài)節(jié)點(diǎn)，以集群方式實(shí)現(xiàn)高可用。

這些功能除了Proxy方式的實(shí)現(xiàn)還有和數(shù)據(jù)訪問標(biāo)準(zhǔn)結(jié)合起來的實(shí)現(xiàn)，比如改寫JDBC的框架方式實(shí)現(xiàn)，兩種實(shí)現(xiàn)方式各有優(yōu)缺點(diǎn)?？蚣芊绞降膶?shí)現(xiàn)不局限于數(shù)據(jù)庫(kù)類型，性能略高，Proxy方式的實(shí)現(xiàn)支持任意的語言更透明，功能也可以做的更強(qiáng)大一些。最近還出現(xiàn)了邊車Sidecard方式實(shí)現(xiàn)的理念，類似于ServiceMesh的概念，網(wǎng)上有一些資料，但是這種方式到目前為止還沒看到成熟的實(shí)現(xiàn)。

分布式緩存中間件

類似于數(shù)據(jù)庫(kù)的Proxy，這里是以緩存服務(wù)作為后端，提供一些集群化的功能。比如以Redis為后端的開源的實(shí)現(xiàn)有https://github.com/CodisLabs/codis以及餓了么的https://github.com/eleme/corvus 等等。其實(shí)不采用Proxy方式做，開發(fā)一個(gè)緩存客戶端在框架層面做也是完全可以的，但是之前也說了這兩種方式各有優(yōu)劣。代理方式的話更透明，如果有Java、Python、Go都需要鏈接Redis，我們無需開發(fā)多套客戶端了。一般實(shí)現(xiàn)下面的功能：

· 分布式。這是最基本的，通過各種算法把Key分散到各個(gè)節(jié)點(diǎn)，提供一定的容量規(guī)劃和容量報(bào)警功能。

· 高可用。配合Redis的一些高可用方案實(shí)現(xiàn)一定程度的高可用。

· 運(yùn)維方面的功能。比如客戶端權(quán)限控制，黑白名單，限流，超時(shí)熔斷，全量操作的審計(jì)搜索，數(shù)據(jù)遷移輔助等等。

· 跟蹤和問題分析。配合全鏈路監(jiān)控實(shí)現(xiàn)一體化的緩存訪問跟蹤。以及更智能的分析使用的情況，結(jié)合緩存的命中率，Value的大小，壓力平衡性提供一些優(yōu)化建議和報(bào)警，盡早發(fā)現(xiàn)問題，緩存的崩盤往往是有前兆的。

· 完善的管理后臺(tái)，可以一覽集群的用量、性能，以及做容量規(guī)劃和遷移方案。

如果Redis集群特別大的話的確是有一套的自己的Proxy體系會(huì)更方便，小型項(xiàng)目一般用不到。

任務(wù)（Job）管理

之前有提高過，Job是我認(rèn)為的互聯(lián)網(wǎng)架構(gòu)體系中三馬車的三分之一，扮演了重要的角色。開源實(shí)現(xiàn)有http://elasticjob.io/。Job的管理的實(shí)現(xiàn)有兩種方式，一種是類似于框架的方式，也就是Job的進(jìn)程是一直啟動(dòng)著的，由框架在合適的時(shí)候調(diào)用方法去執(zhí)行。一種是類似于外部服務(wù)的方式，也就是Job的進(jìn)程是按需要在合適的機(jī)器啟動(dòng)的。在本文一開始的圖中，我畫了一個(gè)任務(wù)調(diào)度的中間件，對(duì)于后一種方式的實(shí)現(xiàn)，我們需要有一套中間件或獨(dú)立的服務(wù)來復(fù)雜Job進(jìn)程的拉起。整個(gè)過程如下：

· 找一些機(jī)器加入集群作為我們的底層服務(wù)器資源。

· Job編譯后打包部署到統(tǒng)一的地方。Job可以是各個(gè)語言實(shí)現(xiàn)的，這沒有關(guān)系?？梢允锹愠绦颍部梢允褂肈ocker來實(shí)現(xiàn)。

· 在允許Job前我們需要對(duì)資源進(jìn)行分配，估算一下Job大概需要怎么樣的資源，然后根據(jù)執(zhí)行頻次統(tǒng)一計(jì)算得出一個(gè)合適的資源分配。

· 由中間件根據(jù)每一個(gè)Job的時(shí)間配置在合適的時(shí)候把進(jìn)程（或Docker）拉起執(zhí)行，執(zhí)行前根據(jù)當(dāng)前的情況計(jì)算分配一個(gè)合適的機(jī)器，完成后釋放資源，下一次執(zhí)行不一定在同一臺(tái)機(jī)器執(zhí)行。

這樣的中間件是更底層的一套服務(wù)，一般而言任務(wù)框架會(huì)提供如下的功能：

· 分布式。Job不會(huì)受限于單機(jī)，可以由集群來提供運(yùn)行支持，可以隨著壓力的上升進(jìn)行集群擴(kuò)容，任何一臺(tái)機(jī)器的宕機(jī)不會(huì)成為問題。如果我們采用中間件方式的話，這個(gè)功能由底層的中間件來支持了。

· API層面提供豐富的Job執(zhí)行方式。比如任務(wù)式的Job，拉數(shù)據(jù)和處理分開的Job。拉數(shù)據(jù)和處理分開的話，我們可以對(duì)數(shù)據(jù)的處理進(jìn)行分片執(zhí)行，實(shí)現(xiàn)類似Map-Reduce的效果。

· 執(zhí)行依賴。我們可以配置Job的依賴關(guān)系實(shí)現(xiàn)自動(dòng)化的Job執(zhí)行流程分析。業(yè)務(wù)只管實(shí)現(xiàn)拆散的業(yè)務(wù)Job，Job的編排通過規(guī)則由框架分析出來。

· 整合到全鏈路監(jiān)控體系的監(jiān)控跟蹤。

· 豐富的管理后臺(tái)，提供統(tǒng)一的執(zhí)行時(shí)間、數(shù)據(jù)取量配置，提供Job執(zhí)行狀態(tài)和依賴分析一覽，查看執(zhí)行歷史，運(yùn)行、暫停、停止Job等等管理功能。

發(fā)布管理

發(fā)布管理其實(shí)和開發(fā)沒有太大的關(guān)聯(lián)，但是我覺得這也是整個(gè)體系閉環(huán)中的一個(gè)環(huán)節(jié)。發(fā)布管理可以使用Jenkins等開源實(shí)現(xiàn)，在后期可能還是需要有自己的發(fā)布系統(tǒng)。可以基于Jenkins再包一層，也可以如最開始的圖所示，直接基于通用的任務(wù)調(diào)度中間件實(shí)現(xiàn)底層的部署。一般而言，發(fā)布管理有下面的功能：

· 豐富的任務(wù)類型和插件，支持各種語言程序的構(gòu)建和發(fā)布。有最基本的發(fā)布、回滾、重啟、停止功能。

· 支持項(xiàng)目的依賴關(guān)系設(shè)置，實(shí)現(xiàn)自動(dòng)化的依賴路徑上的程序自動(dòng)發(fā)布。

· 一些運(yùn)維層面的控制。比如和CMDB結(jié)合做權(quán)限控制，做發(fā)布窗口控制。

· 用于集群的發(fā)布流程。比如可以一覽集群的分組，設(shè)置自動(dòng)的灰度發(fā)布方案。

· 適合自己公司的發(fā)布流程。比如在流程控制上，我們是Dev環(huán)境到QA到Stage到Live。其中，QA環(huán)境經(jīng)過QA的確認(rèn)后可以進(jìn)入Stage環(huán)境，經(jīng)過開發(fā)主管的確認(rèn)后可以到Stage環(huán)境，經(jīng)過產(chǎn)品經(jīng)理的確認(rèn)后可以進(jìn)入Live環(huán)境進(jìn)行發(fā)布。在發(fā)布系統(tǒng)上我們可以結(jié)合OA做好這個(gè)流程的控制。

· 在構(gòu)建的時(shí)候，集成單元測(cè)試，集成編碼規(guī)范檢查等等，在后臺(tái)可以方便的看到每一次發(fā)布的代碼變更，測(cè)試執(zhí)行情況以及代碼規(guī)范違例。

Jenkins等系統(tǒng)在對(duì)于1和2做的比較好，對(duì)于和公司層面其它系統(tǒng)的結(jié)合無能力為，往往處于這個(gè)原因我們需要在Jenkins之上包裝出來自己的發(fā)布系統(tǒng)。

總結(jié)一下，之所以標(biāo)題說不斷耕耘的基礎(chǔ)中間件，是指中間件也好框架也好，往往也需要一個(gè)小團(tuán)隊(duì)來獨(dú)立維護(hù)，而且功能是不斷迭代增加，這套體系如果結(jié)合的好，就不僅僅是實(shí)現(xiàn)功能這個(gè)最基本的標(biāo)準(zhǔn)了，而是：

· 運(yùn)維自動(dòng)化API化和AI化的很重要的構(gòu)成。把控是因?yàn)槲覀冋莆樟藬?shù)據(jù)流，數(shù)據(jù)都是從我們的中間件穿越過去到達(dá)底層的服務(wù)、數(shù)據(jù)庫(kù)、緩存，有了把控就有了自動(dòng)化的可能，有了智能監(jiān)控一體化報(bào)警的可能。

· 也因?yàn)閿?shù)據(jù)流的經(jīng)過，通過對(duì)數(shù)據(jù)進(jìn)行分析，我們可以給到開發(fā)很多建議，我們可以在這上面做很多標(biāo)準(zhǔn)。這些事情都可以由框架架構(gòu)團(tuán)隊(duì)默默去做，不需要業(yè)務(wù)研發(fā)的配合。

· 因?yàn)榈讓訑?shù)據(jù)源的屏蔽，加上服務(wù)框架一起，我們實(shí)現(xiàn)的是業(yè)務(wù)系統(tǒng)被框架包圍而不是業(yè)務(wù)系統(tǒng)在使用框架和中間件這么一個(gè)形態(tài)，那么對(duì)于公司層面的一些大型架構(gòu)改造，比如多活架構(gòu)，我們可以實(shí)現(xiàn)業(yè)務(wù)系統(tǒng)的改造最小。數(shù)據(jù)+服務(wù)+流程都已經(jīng)被中間件所包圍和感知，業(yè)務(wù)系統(tǒng)只是在實(shí)現(xiàn)業(yè)務(wù)功能而已，我們可以在業(yè)務(wù)系統(tǒng)無感知的情況下對(duì)數(shù)據(jù)做動(dòng)態(tài)路由，對(duì)服務(wù)做動(dòng)態(tài)調(diào)用，對(duì)流程做動(dòng)態(tài)控制。如下圖，是不是有點(diǎn)Mesh的意思？

本文很多地方基于思考和YY，開源組件要實(shí)現(xiàn)這個(gè)理念需要有大量的修改和整合，很多大公司內(nèi)部都一定程度做了這些事情，但是也因?yàn)榭蚣艿母鞣N粘連依賴無法徹底開源，這塊工作要做好需要大量的時(shí)間精力，真的需要不斷耕耘和沉淀才能發(fā)展出適合自己公司技術(shù)棧的各種中間件和管理系統(tǒng)體系。