《實施微服務(wù)需要哪些基礎(chǔ)框架和技術(shù)熱點》要點：
本文介紹了實施微服務(wù)需要哪些基礎(chǔ)框架和技術(shù)熱點，希望對您有用。如果有疑問，可以聯(lián)系我們。

引 言

微服務(wù)(MicroServices)架構(gòu)是當(dāng)前互聯(lián)網(wǎng)業(yè)界的一個技術(shù)熱點,圈里有不少同行朋友當(dāng)前有計劃在各自公司開展微服務(wù)化體系建設(shè),他們都有相同的疑問：一個微服務(wù)架構(gòu)有哪些技術(shù)關(guān)注點(technical concerns)?需要哪些基礎(chǔ)框架或組件來支持微服務(wù)架構(gòu)?這些框架或組件該如何選型?筆者之前在兩家大型互聯(lián)網(wǎng)公司參與和主導(dǎo)過大型服務(wù)化體系和框架建設(shè),同時在這塊也投入了很多時間去學(xué)習(xí)和研究,有一些經(jīng)驗和學(xué)習(xí)心得,可以和大家一起分享.

服務(wù)注冊、發(fā)現(xiàn)、負(fù)載均衡和健康檢查

和單塊(Monolithic)架構(gòu)不同,微服務(wù)架構(gòu)是由一系列職責(zé)單一的細(xì)粒度服務(wù)構(gòu)成的分布式網(wǎng)狀結(jié)構(gòu),服務(wù)之間通過輕量機制進(jìn)行通信,這時候必然引入一個服務(wù)注冊發(fā)現(xiàn)問題,也就是說服務(wù)提供方要注冊通告服務(wù)地址,服務(wù)的調(diào)用方要能發(fā)現(xiàn)目標(biāo)服務(wù),同時服務(wù)提供方一般以集群方式提供服務(wù),也就引入了負(fù)載均衡和健康檢查問題.根據(jù)負(fù)載均衡LB所在位置的不同,目前主要的服務(wù)注冊、發(fā)現(xiàn)和負(fù)載均衡方案有三種：

第一種是集中式LB方案,如下圖1,在服務(wù)消費者和服務(wù)提供者之間有一個獨立的LB,LB通常是專門的硬件設(shè)備如F5,或者基于軟件如LVS,HAproxy等實現(xiàn).LB上有所有服務(wù)的地址映射表,通常由運維配置注冊,當(dāng)服務(wù)消費方調(diào)用某個目標(biāo)服務(wù)時,它向LB發(fā)起請求,由LB以某種策略(比如Round-Robin)做負(fù)載均衡后將請求轉(zhuǎn)發(fā)到目標(biāo)服務(wù).LB一般具備健康檢查能力,能自動摘除不健康的服務(wù)實例.服務(wù)消費方如何發(fā)現(xiàn)LB呢?通常的做法是通過DNS,運維人員為服務(wù)配置一個DNS域名,這個域名指向LB.

和單塊(Monolithic)架構(gòu)不同,微服務(wù)架構(gòu)是由一系列職責(zé)單一的細(xì)粒度服務(wù)構(gòu)成的分布式網(wǎng)狀結(jié)構(gòu),服務(wù)之間通過輕量機制進(jìn)行通信,這時候必然引入一個服務(wù)注冊發(fā)現(xiàn)問題,也就是說服務(wù)提供方要注冊通告服務(wù)地址,服務(wù)的調(diào)用方要能發(fā)現(xiàn)目標(biāo)服務(wù),同時服務(wù)提供方一般以集群方式提供服務(wù),也就引入了負(fù)載均衡和健康檢查問題.根據(jù)負(fù)載均衡LB所在位置的不同,目前主要的服務(wù)注冊、發(fā)現(xiàn)和負(fù)載均衡方案有三種：

第一種是集中式LB方案,如下圖1,在服務(wù)消費者和服務(wù)提供者之間有一個獨立的LB,LB通常是專門的硬件設(shè)備如F5,或者基于軟件如LVS,HAproxy等實現(xiàn).LB上有所有服務(wù)的地址映射表,通常由運維配置注冊,當(dāng)服務(wù)消費方調(diào)用某個目標(biāo)服務(wù)時,它向LB發(fā)起請求,由LB以某種策略(比如Round-Robin)做負(fù)載均衡后將請求轉(zhuǎn)發(fā)到目標(biāo)服務(wù).LB一般具備健康檢查能力,能自動摘除不健康的服務(wù)實例.服務(wù)消費方如何發(fā)現(xiàn)LB呢?通常的做法是通過DNS,運維人員為服務(wù)配置一個DNS域名,這個域名指向LB.

［圖1］集中式LB方案

集中式LB方案實現(xiàn)簡單,在LB上也容易做集中式的訪問控制,這一方案目前還是業(yè)界主流.集中式LB的主要問題是單點問題,所有服務(wù)調(diào)用流量都經(jīng)過LB,當(dāng)服務(wù)數(shù)量和調(diào)用量大的時候,LB容易成為瓶頸,且一旦LB發(fā)生故障對整個系統(tǒng)的影響是災(zāi)難性的.另外,LB在服務(wù)消費方和服務(wù)提供方之間增加了一跳(hop),有一定性能開銷.

第二種是進(jìn)程內(nèi)LB方案,針對集中式LB的不足,進(jìn)程內(nèi)LB方案將LB的功能以庫的形式集成到服務(wù)消費方進(jìn)程里頭,該方案也被稱為軟負(fù)載(Soft Load Balancing)或者客戶端負(fù)載方案,下圖Fig 2展示了這種方案的工作原理.這一方案需要一個服務(wù)注冊表(Service Registry)配合支持服務(wù)自注冊和自發(fā)現(xiàn),服務(wù)提供方啟動時,首先將服務(wù)地址注冊到服務(wù)注冊表(同時定期報心跳到服務(wù)注冊表以表明服務(wù)的存活狀態(tài),相當(dāng)于健康檢查),服務(wù)消費方要訪問某個服務(wù)時,它通過內(nèi)置的LB組件向服務(wù)注冊表查詢(同時緩存并定期刷新)目標(biāo)服務(wù)地址列表,然后以某種負(fù)載均衡策略選擇一個目標(biāo)服務(wù)地址,最后向目標(biāo)服務(wù)發(fā)起請求.這一方案對服務(wù)注冊表的可用性(Availability)要求很高,一般采用能滿足高可用分布式一致的組件(例如Zookeeper, Consul, Etcd等)來實現(xiàn).

［圖2］進(jìn)程內(nèi)LB方案

進(jìn)程內(nèi)LB方案是一種分布式方案,LB和服務(wù)發(fā)現(xiàn)能力被分散到每一個服務(wù)消費者的進(jìn)程內(nèi)部,同時服務(wù)消費方和服務(wù)提供方之間是直接調(diào)用,沒有額外開銷,性能比較好.但是,該方案以客戶庫(Client Library)的方式集成到服務(wù)調(diào)用方進(jìn)程里頭,如果企業(yè)內(nèi)有多種不同的語言棧,就要配合開發(fā)多種不同的客戶端,有一定的研發(fā)和維護(hù)成本.另外,一旦客戶端跟隨服務(wù)調(diào)用方發(fā)布到生產(chǎn)環(huán)境中,后續(xù)如果要對客戶庫進(jìn)行升級,勢必要求服務(wù)調(diào)用方修改代碼并重新發(fā)布,所以該方案的升級推廣有不小的阻力.

進(jìn)程內(nèi)LB的案例是Netflix的開源服務(wù)框架,對應(yīng)的組件分別是：Eureka服務(wù)注冊表,Karyon服務(wù)端框架支持服務(wù)自注冊和健康檢查,Ribbon客戶端框架支持服務(wù)自發(fā)現(xiàn)和軟路由.另外,阿里開源的服務(wù)框架Dubbo也是采用類似機制.

第三種是主機獨立LB進(jìn)程方案,該方案是針對第二種方案的不足而提出的一種折中方案,原理和第二種方案基本類似,不同之處是,他將LB和服務(wù)發(fā)現(xiàn)功能從進(jìn)程內(nèi)移出來,變成主機上的一個獨立進(jìn)程,主機上的一個或者多個服務(wù)要訪問目標(biāo)服務(wù)時,他們都通過同一主機上的獨立LB進(jìn)程做服務(wù)發(fā)現(xiàn)和負(fù)載均衡,見下圖Fig 3.

［圖3］主機獨立LB進(jìn)程方案

該方案也是一種分布式方案,沒有單點問題,一個LB進(jìn)程掛了只影響該主機上的服務(wù)調(diào)用方,服務(wù)調(diào)用方和LB之間是進(jìn)程內(nèi)調(diào)用,性能好,同時,該方案還簡化了服務(wù)調(diào)用方,不需要為不同語言開發(fā)客戶庫,LB的升級不需要服務(wù)調(diào)用方改代碼.該方案的不足是部署較復(fù)雜,環(huán)節(jié)多,出錯調(diào)試排查問題不方便.

該方案的典型案例是Airbnb的SmartStack服務(wù)發(fā)現(xiàn)框架,對應(yīng)組件分別是：Zookeeper作為服務(wù)注冊表,Nerve獨立進(jìn)程負(fù)責(zé)服務(wù)注冊和健康檢查,Synapse/HAproxy獨立進(jìn)程負(fù)責(zé)服務(wù)發(fā)現(xiàn)和負(fù)載均衡.Google最新推出的基于容器的PaaS平臺Kubernetes,其內(nèi)部服務(wù)發(fā)現(xiàn)采用類似的機制.

服務(wù)前端路由

微服務(wù)除了內(nèi)部相互之間調(diào)用和通信之外,最終要以某種方式暴露出去,才能讓外界系統(tǒng)(例如客戶的瀏覽器、移動設(shè)備等等)訪問到,這就涉及服務(wù)的前端路由,對應(yīng)的組件是服務(wù)網(wǎng)關(guān)(Service Gateway),見圖 4,網(wǎng)關(guān)是連接企業(yè)內(nèi)部和外部系統(tǒng)的一道門,有如下關(guān)鍵作用：

• 服務(wù)反向路由,網(wǎng)關(guān)要負(fù)責(zé)將外部請求反向路由到內(nèi)部具體的微服務(wù),這樣雖然企業(yè)內(nèi)部是復(fù)雜的分布式微服務(wù)結(jié)構(gòu),但是外部系統(tǒng)從網(wǎng)關(guān)上看到的就像是一個統(tǒng)一的完整服務(wù),網(wǎng)關(guān)屏蔽了后臺服務(wù)的復(fù)雜性,同時也屏蔽了后臺服務(wù)的升級和變化.
• 安全認(rèn)證和防爬蟲,所有外部請求必須經(jīng)過網(wǎng)關(guān),網(wǎng)關(guān)可以集中對訪問進(jìn)行安全控制,比如用戶認(rèn)證和授權(quán),同時還可以分析訪問模式實現(xiàn)防爬蟲功能,網(wǎng)關(guān)是連接企業(yè)內(nèi)外系統(tǒng)的安全之門.
• 限流和容錯,在流量高峰期,網(wǎng)關(guān)可以限制流量,保護(hù)后臺系統(tǒng)不被大流量沖垮,在內(nèi)部系統(tǒng)出現(xiàn)故障時,網(wǎng)關(guān)可以集中做容錯,保持外部良好的用戶體驗.
• 監(jiān)控,網(wǎng)關(guān)可以集中監(jiān)控訪問量,調(diào)用延遲,錯誤計數(shù)和訪問模式,為后端的性能優(yōu)化或者擴容提供數(shù)據(jù)支持.
• 日志,網(wǎng)關(guān)可以收集所有的訪問日志,進(jìn)入后臺系統(tǒng)做進(jìn)一步分析.

［圖4］ 服務(wù)網(wǎng)關(guān)

除以上基本能力外,網(wǎng)關(guān)還可以實現(xiàn)線上引流,線上壓測,線上調(diào)試(Surgical debugging),金絲雀測試(Canary Testing),數(shù)據(jù)中心雙活(Active-Active HA)等高級功能.

網(wǎng)關(guān)通常工作在7層,有一定的計算邏輯,一般以集群方式部署,前置LB進(jìn)行負(fù)載均衡.

開源的網(wǎng)關(guān)組件有Netflix的Zuul,特點是動態(tài)可熱部署的過濾器(filter)機制,其它如HAproxy,Nginx等都可以擴展作為網(wǎng)關(guān)使用.

在介紹過服務(wù)注冊表和網(wǎng)關(guān)等組件之后,我們可以通過一個簡化的微服務(wù)架構(gòu)圖(Fig 5)來更加直觀地展示整個微服務(wù)體系內(nèi)的服務(wù)注冊發(fā)現(xiàn)和路由機制,該圖假定采用進(jìn)程內(nèi)LB服務(wù)發(fā)現(xiàn)和負(fù)載均衡機制.在下圖Fig 5的微服務(wù)架構(gòu)中,服務(wù)簡化為兩層,后端通用服務(wù)(也稱中間層服務(wù)Middle Tier Service)和前端服務(wù)(也稱邊緣服務(wù)Edge Service,前端服務(wù)的作用是對后端服務(wù)做必要的聚合和裁剪后暴露給外部不同的設(shè)備,如PC,Pad或者Phone).后端服務(wù)啟動時會將地址信息注冊到服務(wù)注冊表,前端服務(wù)通過查詢服務(wù)注冊表就可以發(fā)現(xiàn)然后調(diào)用后端服務(wù)；前端服務(wù)啟動時也會將地址信息注冊到服務(wù)注冊表,這樣網(wǎng)關(guān)通過查詢服務(wù)注冊表就可以將請求路由到目標(biāo)前端服務(wù),這樣整個微服務(wù)體系的服務(wù)自注冊自發(fā)現(xiàn)和軟路由就通過服務(wù)注冊表和網(wǎng)關(guān)串聯(lián)起來了.如果以面向?qū)ο笤O(shè)計模式的視角來看,網(wǎng)關(guān)類似Proxy代理或者Fa?ade門面模式,而服務(wù)注冊表和服務(wù)自注冊自發(fā)現(xiàn)類似IoC依賴注入模式,微服務(wù)可以理解為基于網(wǎng)關(guān)代理和注冊表IoC構(gòu)建的分布式系統(tǒng).

［圖5］簡化的微服務(wù)架構(gòu)圖

服務(wù)容錯

當(dāng)企業(yè)微服務(wù)化以后,服務(wù)之間會有錯綜復(fù)雜的依賴關(guān)系,例如,一個前端請求一般會依賴于多個后端服務(wù),技術(shù)上稱為1 -> N扇出(見圖Fig 6).在實際生產(chǎn)環(huán)境中,服務(wù)往往不是百分百可靠,服務(wù)可能會出錯或者產(chǎn)生延遲,如果一個應(yīng)用不能對其依賴的故障進(jìn)行容錯和隔離,那么該應(yīng)用本身就處在被拖垮的風(fēng)險中.在一個高流量的網(wǎng)站中,某個單一后端一旦發(fā)生延遲,可能在數(shù)秒內(nèi)導(dǎo)致所有應(yīng)用資源(線程,隊列等)被耗盡,造成所謂的雪崩效應(yīng)(Cascading Failure,見圖 7),嚴(yán)重時可致整個網(wǎng)站癱瘓.

［圖6］服務(wù)依賴

［圖7］高峰期單個服務(wù)延遲致雪崩效應(yīng)

經(jīng)過多年的探索和實踐,業(yè)界在分布式服務(wù)容錯一塊探索出了一套有效的容錯模式和最佳實踐,主要包括：

• 電路熔斷器模式(Circuit Breaker Patten), 該模式的原理類似于家里的電路熔斷器,如果家里的電路發(fā)生短路,熔斷器能夠主動熔斷電路,以避免災(zāi)難性損失.在分布式系統(tǒng)中應(yīng)用電路熔斷器模式后,當(dāng)目標(biāo)服務(wù)慢或者大量超時,調(diào)用方能夠主動熔斷,以防止服務(wù)被進(jìn)一步拖垮；如果情況又好轉(zhuǎn)了,電路又能自動恢復(fù),這就是所謂的彈性容錯,系統(tǒng)有自恢復(fù)能力.下圖Fig 8是一個典型的具備彈性恢復(fù)能力的電路保護(hù)器狀態(tài)圖,正常狀態(tài)下,電路處于關(guān)閉狀態(tài)(Closed),如果調(diào)用持續(xù)出錯或者超時,電路被打開進(jìn)入熔斷狀態(tài)(Open),后續(xù)一段時間內(nèi)的所有調(diào)用都會被拒絕(Fail Fast),一段時間以后,保護(hù)器會嘗試進(jìn)入半熔斷狀態(tài)(Half-Open),允許少量請求進(jìn)來嘗試,如果調(diào)用仍然失敗,則回到熔斷狀態(tài),如果調(diào)用成功,則回到電路閉合狀態(tài).

［圖8］彈性電路保護(hù)狀態(tài)圖

 

• 艙壁隔離模式(Bulkhead Isolation Pattern),顧名思義,該模式像艙壁一樣對資源或失敗單元進(jìn)行隔離,如果一個船艙破了進(jìn)水,只損失一個船艙,其它船艙可以不受影響 .線程隔離(Thread Isolation)就是艙壁隔離模式的一個例子,假定一個應(yīng)用程序A調(diào)用了Svc1/Svc2/Svc3三個服務(wù),且部署A的容器一共有120個工作線程,采用線程隔離機制,可以給對Svc1/Svc2/Svc3的調(diào)用各分配40個線程,當(dāng)Svc2慢了,給Svc2分配的40個線程因慢而阻塞并最終耗盡,線程隔離可以保證給Svc1/Svc3分配的80個線程可以不受影響,如果沒有這種隔離機制,當(dāng)Svc2慢的時候,120個工作線程會很快全部被對Svc2的調(diào)用吃光,整個應(yīng)用程序會全部慢下來.
• 限流(Rate Limiting/Load Shedder),服務(wù)總有容量限制,沒有限流機制的服務(wù)很容易在突發(fā)流量(秒殺,雙十一)時被沖垮.限流通常指對服務(wù)限定并發(fā)訪問量,比如單位時間只允許100個并發(fā)調(diào)用,對超過這個限制的請求要拒絕并回退.
• 回退(fallback),在熔斷或者限流發(fā)生的時候,應(yīng)用程序的后續(xù)處理邏輯是什么?回退是系統(tǒng)的彈性恢復(fù)能力,常見的處理策略有,直接拋出異常,也稱快速失敗(Fail Fast),也可以返回空值或缺省值,還可以返回備份數(shù)據(jù),如果主服務(wù)熔斷了,可以從備份服務(wù)獲取數(shù)據(jù).

Netflix將上述容錯模式和最佳實踐集成到一個稱為Hystrix的開源組件中,凡是需要容錯的依賴點(服務(wù),緩存,數(shù)據(jù)庫訪問等),開發(fā)人員只需要將調(diào)用封裝在Hystrix Command里頭,則相關(guān)調(diào)用就自動置于Hystrix的彈性容錯保護(hù)之下.Hystrix組件已經(jīng)在Netflix經(jīng)過多年運維驗證,是Netflix微服務(wù)平臺穩(wěn)定性和彈性的基石,正逐漸被社區(qū)接受為標(biāo)準(zhǔn)容錯組件.

服務(wù)框架

微服務(wù)化以后,為了讓業(yè)務(wù)開發(fā)人員專注于業(yè)務(wù)邏輯實現(xiàn),避免冗余和重復(fù)勞動,規(guī)范研發(fā)提升效率,必然要將一些公共關(guān)注點推到框架層面.服務(wù)框架(Fig 9)主要封裝公共關(guān)注點邏輯,包括：

 

［圖9］服務(wù)框架

• 服務(wù)注冊、發(fā)現(xiàn)、負(fù)載均衡和健康檢查,假定采用進(jìn)程內(nèi)LB方案,那么服務(wù)自注冊一般統(tǒng)一做在服務(wù)器端框架中,健康檢查邏輯由具體業(yè)務(wù)服務(wù)定制,框架層提供調(diào)用健康檢查邏輯的機制,服務(wù)發(fā)現(xiàn)和負(fù)載均衡則集成在服務(wù)客戶端框架中.
• 監(jiān)控日志,框架一方面要記錄重要的框架層日志、metrics和調(diào)用鏈數(shù)據(jù),還要將日志、metrics等接口暴露出來,讓業(yè)務(wù)層能根據(jù)需要記錄業(yè)務(wù)日志數(shù)據(jù).在運行環(huán)境中,所有日志數(shù)據(jù)一般集中落地到企業(yè)后臺日志系統(tǒng),做進(jìn)一步分析和處理.
• REST/RPC和序列化,框架層要支持將業(yè)務(wù)邏輯以HTTP/REST或者RPC方式暴露出來,HTTP/REST是當(dāng)前主流API暴露方式,在性能要求高的場合則可采用Binary/RPC方式.針對當(dāng)前多樣化的設(shè)備類型(瀏覽器、普通PC、無線設(shè)備等),框架層要支持可定制的序列化機制,例如,對瀏覽器,框架支持輸出Ajax友好的JSON消息格式,而對無線設(shè)備上的Native App,框架支持輸出性能高的Binary消息格式.
• 配置,除了支持普通配置文件方式的配置,框架層還可集成動態(tài)運行時配置,能夠在運行時針對不同環(huán)境動態(tài)調(diào)整服務(wù)的參數(shù)和配置.
• 限流和容錯,框架集成限流容錯組件,能夠在運行時自動限流和容錯,保護(hù)服務(wù),如果進(jìn)一步和動態(tài)配置相結(jié)合,還可以實現(xiàn)動態(tài)限流和熔斷.
• 管理接口,框架集成管理接口,一方面可以在線查看框架和服務(wù)內(nèi)部狀態(tài),同時還可以動態(tài)調(diào)整內(nèi)部狀態(tài),對調(diào)試、監(jiān)控和管理能提供快速反饋.Spring Boot微框架的Actuator模塊就是一個強大的管理接口.
• 統(tǒng)一錯誤處理,對于框架層和服務(wù)的內(nèi)部異常,如果框架層能夠統(tǒng)一處理并記錄日志,對服務(wù)監(jiān)控和快速問題定位有很大幫助.
• 安全,安全和訪問控制邏輯可以在框架層統(tǒng)一進(jìn)行封裝,可做成插件形式,具體業(yè)務(wù)服務(wù)根據(jù)需要加載相關(guān)安全插件.
• 文檔自動生成,文檔的書寫和同步一直是一個痛點,框架層如果能支持文檔的自動生成和同步,會給使用API的開發(fā)和測試人員帶來極大便利.Swagger是一種流行Restful API的文檔方案.

當(dāng)前業(yè)界比較成熟的微服務(wù)框架有Netflix的Karyon/Ribbon,Spring的Spring Boot/Cloud,阿里的Dubbo等.

運行期配置管理

服務(wù)一般有很多依賴配置,例如訪問數(shù)據(jù)庫有連接字符串配置,連接池大小和連接超時配置,這些配置在不同環(huán)境(開發(fā)/測試/生產(chǎn))一般不同,比如生產(chǎn)環(huán)境需要配連接池,而開發(fā)測試環(huán)境可能不配,另外有些參數(shù)配置在運行期可能還要動態(tài)調(diào)整,例如,運行時根據(jù)流量狀況動態(tài)調(diào)整限流和熔斷閥值.目前比較常見的做法是搭建一個運行時配置中心支持微服務(wù)的動態(tài)配置,簡化架構(gòu)如下圖：

［圖10］服務(wù)配置中心

動態(tài)配置存放在集中的配置服務(wù)器上,用戶通過管理界面配置和調(diào)整服務(wù)配置,具體服務(wù)通過定期拉(Scheduled Pull)的方式或者服務(wù)器推(Server-side Push)的方式更新動態(tài)配置,拉方式比較可靠,但會有延遲同時有無效網(wǎng)絡(luò)開銷(假設(shè)配置不常更新),服務(wù)器推方式能及時更新配置,但是實現(xiàn)較復(fù)雜,一般在服務(wù)和配置服務(wù)器之間要建立長連接.配置中心還要解決配置的版本控制和審計問題,對于大規(guī)模服務(wù)化環(huán)境,配置中心還要考慮分布式和高可用問題.

配置中心比較成熟的開源方案有百度的Disconf,360的QConf,Spring的Cloud Config和阿里的Diamond等.

Netflix的微服務(wù)框架

Netflix是一家成功實踐微服務(wù)架構(gòu)的互聯(lián)網(wǎng)公司,幾年前,Netflix就把它的幾乎整個微服務(wù)框架棧開源貢獻(xiàn)給了社區(qū),這些框架和組件包括：

• Eureka:　服務(wù)注冊發(fā)現(xiàn)框架
• Zuul:　服務(wù)網(wǎng)關(guān)
• Karyon:　服務(wù)端框架
• Ribbon:　客戶端框架
• Hystrix: 服務(wù)容錯組件
• Archaius: 服務(wù)配置組件
• Servo: Metrics組件
• Blitz4j: 日志組件

下圖11展示了基于這些組件構(gòu)建的一個微服務(wù)框架體系,來自recipes-rss.

［圖11］基于Netflix開源組件的微服務(wù)框架

Netflix的開源框架組件已經(jīng)在Netflix的大規(guī)模分布式微服務(wù)環(huán)境中經(jīng)過多年的生產(chǎn)實戰(zhàn)驗證,正逐步被社區(qū)接受為構(gòu)造微服務(wù)框架的標(biāo)準(zhǔn)組件.Pivotal去年推出的Spring Cloud開源產(chǎn)品,主要是基于對Netflix開源組件的進(jìn)一步封裝,方便Spring開發(fā)人員構(gòu)建微服務(wù)基礎(chǔ)框架.對于一些打算構(gòu)建微服務(wù)框架體系的公司來說,充分利用或參考借鑒Netflix的開源微服務(wù)組件(或Spring Cloud),在此基礎(chǔ)上進(jìn)行必要的企業(yè)定制,無疑是通向微服務(wù)架構(gòu)的捷徑.

文章來自微信公眾號：DevOps

 

轉(zhuǎn)載請注明本頁網(wǎng)址：
http://www.snjht.com/jiaocheng/4159.html