一、前言

2014年可以認(rèn)為是微服務(wù)1.0的元年，當(dāng)年有幾個標(biāo)志性事件，一是Martin Fowler在其博客上發(fā)表了“Microservices”一文，正式提出微服務(wù)架構(gòu)風(fēng)格；二是Netflix微服務(wù)架構(gòu)經(jīng)過多年大規(guī)模生產(chǎn)驗證，最終抽象落地形成一整套開源的微服務(wù)基礎(chǔ)組件，統(tǒng)稱NetflixOSS，Netflix的成功經(jīng)驗開始被業(yè)界認(rèn)可并推崇；三是Pivotal將NetflixOSS開源微服務(wù)組件集成到其Spring體系，推出Spring Cloud微服務(wù)開發(fā)技術(shù)棧。

一晃三年過去，微服務(wù)技術(shù)生態(tài)又發(fā)生了巨大變化，容器，PaaS，Cloud Native，gRPC，ServiceMesh，Serverless等新技術(shù)新理念你方唱罷我登場，不知不覺我們又來到了微服務(wù)2.0時代。

基于近年在微服務(wù)基礎(chǔ)架構(gòu)方面的實戰(zhàn)經(jīng)驗和平時的學(xué)習(xí)積累，我想總結(jié)并提出一些構(gòu)建微服務(wù)2.0技術(shù)棧的選型思路，供各位在一線實戰(zhàn)的架構(gòu)師、工程師參考借鑒。對于一些暫時還沒有成熟開源產(chǎn)品的微服務(wù)支撐模塊，我也會給出一些定制自研的設(shè)計思路。

二、選型準(zhǔn)側(cè)

對于技術(shù)選型，我個人有很多標(biāo)準(zhǔn)，其中下面三項是最重要的:

1. 生產(chǎn)級

我們選擇的技術(shù)棧是要解決實際業(yè)務(wù)問題和上生產(chǎn)抗流量的（選擇不慎可能造成生產(chǎn)級事故），而不是簡單做個POC或者Demo展示，所以生產(chǎn)級（Production Ready），可運(yùn)維（Ops Ready），可治理，成熟穩(wěn)定的技術(shù)才是我們的首選；

2. 一線互聯(lián)網(wǎng)公司落地產(chǎn)品

我們會盡量采用在一線互聯(lián)網(wǎng)公司落地并且開源的，且在社區(qū)內(nèi)形成良好口碑的產(chǎn)品，它們已經(jīng)在這些公司經(jīng)過流量沖擊，坑已經(jīng)基本被填平，且被社區(qū)接受形成一個良好的社區(qū)生態(tài)（本文附錄部分會給出所有推薦使用或參考的開源項目的github鏈接。）。

3. 開源社區(qū)活躍度

Github上的stars的數(shù)量是一個重要指標(biāo)，同時會參考其代碼和文檔更新頻率（尤其是近年），這些指標(biāo)直接反應(yīng)開源產(chǎn)品的社區(qū)活躍度或者說生命力。

另外，對于不同業(yè)務(wù)體量和團(tuán)隊規(guī)模的公司，技術(shù)選型標(biāo)準(zhǔn)往往是不同的，創(chuàng)業(yè)公司的技術(shù)選型和BAT級別公司的技術(shù)選型標(biāo)準(zhǔn)可能完全不同。

本文主要針對日流量千萬以上，研發(fā)團(tuán)隊規(guī)模不少于50人的公司，如果小于這個規(guī)模我建議認(rèn)真評估是否真的需要采用微服務(wù)架構(gòu)。考慮到Java語言在國內(nèi)的流行度和我個人的背景經(jīng)驗，本文主要針對采用Java技術(shù)棧的企業(yè)。

本文也假定自建微服務(wù)基礎(chǔ)架構(gòu)，有些產(chǎn)品其實有對應(yīng)的云服務(wù)可以直接使用，自建和采用云服務(wù)各有利弊，架構(gòu)師需要根據(jù)場景上下文綜合權(quán)衡。

---

三、微服務(wù)基礎(chǔ)架構(gòu)核心關(guān)注點

下面腦圖中芒果色標(biāo)注的七個模塊，我認(rèn)為是構(gòu)建微服務(wù)2.0技術(shù)棧的核心模塊，本文后面的選型會分別基于這些模塊展開。對于每個模塊我也列出一些核心架構(gòu)關(guān)注點，在選擇具體產(chǎn)品時，需要盡可能覆蓋到這些關(guān)注點。

下圖是在參考過華為技術(shù)專家王磊的《微服務(wù)的設(shè)計與生態(tài)系統(tǒng)》[附錄12.46]的基礎(chǔ)上，結(jié)合作者自身的實踐調(diào)整而來，我想同時分享給一線架構(gòu)師或者工程師參考，其中粉紅色標(biāo)注的模塊是和微服務(wù)關(guān)系最密切的模塊，大家在做技術(shù)選型時，可以同時對照這個體系。

---

四、服務(wù)框架選型

服務(wù)框架是一個比較成熟的領(lǐng)域，有太多可選項。Spring Boot/Cloud[附錄12.1]由于Spring社區(qū)的影響力和Netflix的背書，目前可以認(rèn)為是構(gòu)建Java微服務(wù)的一個社區(qū)標(biāo)準(zhǔn)，Spring Boot目前在github上有超過20k星。

基于Spring的框架本質(zhì)上可以認(rèn)為是一種RESTful框架（不是RPC框架），序列化協(xié)議主要采用基于文本的JSON，通訊協(xié)議一般基于HTTP。RESTful框架天然支持跨語言，任何語言只要有HTTP客戶端都可以接入調(diào)用，但是客戶端一般需要自己解析payload。目前Spring框架也支持Swagger契約編程模型，能夠基于契約生成各種語言的強(qiáng)類型客戶端，極大方便不同語言棧的應(yīng)用接入，但是因為RESTful框架和Swagger規(guī)范的弱契約特性，生成的各種語言客戶端的互操作性還是有不少坑的。

Dubbo[附錄12.2]是阿里多年構(gòu)建生產(chǎn)級分布式微服務(wù)的技術(shù)結(jié)晶，服務(wù)治理能力非常豐富，在國內(nèi)技術(shù)社區(qū)具有很大影響力，目前github上有超過16k星。Dubbo本質(zhì)上是一套基于Java的RPC框架，當(dāng)當(dāng)Dubbox擴(kuò)展了Dubbo支持RESTful接口暴露能力。

Dubbo主要面向Java 技術(shù)棧，跨語言支持不足是它的一個弱項，另外因為治理能力太豐富，以至于這個框架比較重，完全用好這個框架的門檻比較高，但是如果你的企業(yè)基本上投資在Java技術(shù)棧上，選Dubbo可以讓你在服務(wù)框架一塊站在較高的起點上，不管是性能還是企業(yè)級的服務(wù)治理能力，Dubbo都做的很出色。新浪微博開源的Motan（github 4k stars）也不錯，功能和Dubbo類似，可以認(rèn)為是一個輕量裁剪版的Dubbo。

gRPC[附錄12.3]是谷歌近年新推的一套RPC框架，基于protobuf的強(qiáng)契約編程模型，能自動生成各種語言客戶端，且保證互操作。支持HTTP2是gRPC的一大亮點，通訊層性能比HTTP有很大改進(jìn)。Protobuf是在社區(qū)具有悠久歷史和良好口碑的高性能序列化協(xié)議，加上Google公司的背書和社區(qū)影響力，目前gRPC也比較火，github上有超過13.4k星。

目前看gRPC更適合內(nèi)部服務(wù)相互調(diào)用場景，對外暴露HTTP RESTful接口可以實現(xiàn)，但是比較麻煩（需要gRPC Gateway配合），所以對于對外暴露API場景可能還需要引入第二套HTTP RESTful框架作為補(bǔ)充?？傮w上gRPC這個東西還比較新，社區(qū)對于HTTP2帶來的好處還未形成一致認(rèn)同，建議謹(jǐn)慎投入，可以做一些試點。

---

五、運(yùn)行時支撐服務(wù)選型

運(yùn)行時支撐服務(wù)主要包括服務(wù)注冊中心，服務(wù)路由網(wǎng)關(guān)和集中式配置中心三個產(chǎn)品。

服務(wù)注冊中心，如果采用Spring Cloud體系，則選擇Eureka[附錄12.4]是最佳搭配，Eureka在Netflix經(jīng)過大規(guī)模生產(chǎn)驗證，支持跨數(shù)據(jù)中心，客戶端配合Ribbon可以實現(xiàn)靈活的客戶端軟負(fù)載，Eureka目前在github上有超過4.7k星；Consul[附錄12.5]也是不錯選擇，天然支持跨數(shù)據(jù)中心，還支持KV模型存儲和靈活健康檢查能力，目前在github上有超過11k星。

服務(wù)網(wǎng)關(guān)也是一個比較成熟的領(lǐng)域，有很多可選項。如果采用Spring Cloud體系，則選擇Zuul[附錄12.6]是最佳搭配，Zuul在Netflix經(jīng)過大規(guī)模生產(chǎn)驗證，支持靈活的動態(tài)過濾器腳本機(jī)制，異步性能不足（基于Netty的異步Zuul遲遲未能推出正式版）。Zuul網(wǎng)關(guān)目前在github上有超過3.7k星。

基于Nginx/OpenResty的API網(wǎng)關(guān)Kong[附錄12.7]目前在github上比較火，有超過14.1k星。因為采用Nginx內(nèi)核，Kong的異步性能較強(qiáng)，另外基于lua的插件機(jī)制比較靈活，社區(qū)插件也比較豐富，從安全到限流熔斷都有，還有不少開源的管理界面，能夠集中管理Kong集群。

配置中心，Spring Cloud自帶Spring Cloud Config[附錄12.8]（github 0.75k stars），個人認(rèn)為算不上生產(chǎn)級，很多治理能力缺失，小規(guī)模場景可以試用。個人比較推薦攜程的Apollo[附錄12.9]配置中心，在攜程經(jīng)過生產(chǎn)級驗證，具備高可用，配置實時生效（推拉結(jié)合），配置審計和版本化，多環(huán)境多集群支持等生產(chǎn)級特性，建議中大規(guī)模需要對配置集中進(jìn)行治理的企業(yè)采用。Apollo目前在github上有超過3.4k星。

---

六、服務(wù)監(jiān)控選型

主要包括日志監(jiān)控，調(diào)用鏈監(jiān)控，Metrics監(jiān)控，健康檢查和告警通知等產(chǎn)品。

ELK目前可以認(rèn)為是日志監(jiān)控的標(biāo)配，功能完善開箱即用，Elasticsearch[附錄12.10]目前在github上有超過28.4k星。Elastalert[附錄12.11] (github 4k stars)是Yelp開源的針對ELK的告警通知模塊。

調(diào)用鏈監(jiān)控目前社區(qū)主流是點評CAT[附錄12.12]（github 4.3k stars），Twitter之前開源現(xiàn)在由OpenZipkin社區(qū)維護(hù)的Zipkin[附錄12.13]（github 7.5k stars）和Naver開源的Pinpoint[附錄12.14]（github 5.3k stars）。

個人比較推薦點評開源的CAT，在點評和國內(nèi)多家互聯(lián)網(wǎng)公司有落地案例，生產(chǎn)級特性和治理能力較完善，另外CAT自帶告警模塊。下面是我之前對三款產(chǎn)品的評估表，供參考。

Metrics監(jiān)控主要依賴于時間序列數(shù)據(jù)庫(TSDB)，目前較成熟的產(chǎn)品是StumbleUpon公司開源的基于HBase的OpenTSDB[附錄12.15]（基于Cassandra的KariosDB[附錄12.16]也是一個選擇，github 1.1k stars，它基本上是OpenTSDB針對Cassandra的一個改造版），OpenTSDB具有分布式能力可以橫向擴(kuò)展，但是相對較重，適用于中大規(guī)模企業(yè)，OpenTSDB目前在github上有近2.9k星。

OpenTSDB 本身不提供告警模塊，Argus[附錄12.17]（github 0.29k星）是Salesforce開源的基于OpenTSDB的統(tǒng)一監(jiān)控告警平臺，支持豐富的告警函數(shù)和靈活的告警配置，可以作為OpenTSDB的告警補(bǔ)充。近年也出現(xiàn)一些輕量級的TSDB，如InfluxDB[附錄12.18]（github 12.4k stars）和Prometheus[附錄12.19]（github 14.3k stars），這些產(chǎn)品函數(shù)報表能力豐富，自帶告警模塊，但是分布式能力不足，適用于中小規(guī)模企業(yè)。Grafana[附錄12.20]（github 19.9k stars）是Metrics報表展示的社區(qū)標(biāo)配。

社區(qū)還有一些通用的健康檢查和告警產(chǎn)品，例如Sensu[附錄12.21]（github 2.7k stars），能夠?qū)Ω鞣N服務(wù)（例如spring boot暴露的健康檢查端點，時間序列數(shù)據(jù)庫中的metrics，ELK中的錯誤日志等）定制靈活的健康檢查(check)，然后用戶可以針對check結(jié)果設(shè)置靈活的告警通知策略。

Sensu在Yelp等公司有落地案例。其它類似產(chǎn)品還有Esty開源的411[附錄12.22]（github 0.74k星）和Zalando的ZMon[附錄12.23] (github 0.15k星)，它們是分別在Esty和Zalando落地的產(chǎn)品，但是定制check和告警配置的使用門檻比較高，社區(qū)不熱，建議有定制自研能力的團(tuán)隊試用。ZMon后臺采用KairosDB存儲，如果企業(yè)已經(jīng)采用KariosDB作為時間序列數(shù)據(jù)庫，則可以考慮ZMon作為告警通知模塊。

---

七、服務(wù)容錯選型

針對Java技術(shù)棧，Netflix的Hystrix[附錄12.24]（github 12.4k stars）把熔斷、隔離、限流和降級等能力封裝成組件，任何依賴調(diào)用（數(shù)據(jù)庫，服務(wù)，緩存）都可以封裝在Hystrix Command之內(nèi)，封裝后自動具備容錯能力。Hystrix起源于Netflix的彈性工程項目，經(jīng)過Netflix大規(guī)模生產(chǎn)驗證，目前是容錯組件的社區(qū)標(biāo)準(zhǔn)，github上有超12k星。其它語言棧也有類似Hystrix的簡化版本組件。

Hystrix一般需要在應(yīng)用端或者框架內(nèi)埋點，有一定的使用門檻。對于采用集中式反向代理（邊界和內(nèi)部）做服務(wù)路由的公司，則可以集中在反向代理上做熔斷限流，例如采用nginx[附錄12.25]（github 5.1k stars）或者Kong[附錄12.7]（github 11.4k stars）這類反向代理，它們都有插件支持靈活的限流容錯配置。Zuul網(wǎng)關(guān)也可以集成Hystrix實現(xiàn)網(wǎng)關(guān)層集中式限流容錯。集中式反向代理需要有一定的研發(fā)和運(yùn)維能力，但是可以對限流容錯進(jìn)行集中治理，可以簡化客戶端。

---

八、后臺服務(wù)選型

后臺服務(wù)主要包括消息系統(tǒng)，分布式緩存，分布式數(shù)據(jù)訪問層和任務(wù)調(diào)度系統(tǒng)。后臺服務(wù)是一個相對比較成熟的領(lǐng)域，很多開源產(chǎn)品基本可以開箱即用。

消息系統(tǒng)，對于日志等可靠性要求不高的場景，則Apache頂級項目Kafka[附錄12.26]（github 7.2k stars）是社區(qū)標(biāo)配。對于可靠性要求較高的業(yè)務(wù)場景，kafka其實也是可以勝任，但企業(yè)需要根據(jù)具體場景，對 Kafka的監(jiān)控和治理能力進(jìn)行適當(dāng)定制完善，Allegro公司開源的hermes[附錄12.27]（github 0.3k stars）是一個可參考項目，它在Kafka基礎(chǔ)上封裝了適合業(yè)務(wù)場景的企業(yè)級治理能力。

阿里開源的RocketMQ[附錄12.28]（github 3.5k星）也是一個不錯選擇，具備更多適用于業(yè)務(wù)場景的特性，目前也是Apache頂級項目。RabbitMQ[附錄12.29]（github 3.6k星）是老牌經(jīng)典的MQ，隊列特性和文檔都很豐富，性能和分布式能力稍弱，中小規(guī)模場景可選。

對于緩存治理，如果傾向于采用客戶端直連模式（個人認(rèn)為緩存直連更簡單輕量），則SohuTv開源的cachecloud[附錄12.30]（github 2.5k stars）是一款不錯的Redis緩存治理平臺，提供諸如監(jiān)控統(tǒng)計，一鍵開啟，自動故障轉(zhuǎn)移，在線伸縮，自動化運(yùn)維等生產(chǎn)級治理能力，另外其文檔也比較豐富。如果傾向采用中間層Proxy模式，則Twitter開源的twemproxy[附錄12.31]（github 7.5k stars）和CodisLab開源的codis[附錄12.32]（github 6.9k stars）是社區(qū)比較熱的選項。

對于分布式數(shù)據(jù)訪問層，如果采用Java技術(shù)棧，則當(dāng)當(dāng)開源的shardingjdbc[附錄12.33]（github 3.5k stars）是一個不錯的選項，分庫分表邏輯做在客戶端jdbc driver中，客戶端直連數(shù)據(jù)庫比較簡單輕量，建議中小規(guī)模場景采用。如果傾向采用數(shù)據(jù)庫訪問中間層proxy模式，則從阿里Cobar演化出來的社區(qū)開源分庫分表中間件MyCAT[附錄12.34]（github 3.6k stars）是一個不錯選擇 。proxy模式運(yùn)維成本較高，建議中大規(guī)模場景，有一定框架自研和運(yùn)維能力的團(tuán)隊采用。

任務(wù)調(diào)度系統(tǒng)，個人推薦徐雪里開源的xxl-job[附錄12.35]（github 3.4k stars），部署簡單輕量，大部分場景夠用。當(dāng)當(dāng)開源的elastic-job[附錄12.36]（github 3.2k stars）也是一個不錯選擇，相比xxl-job功能更強(qiáng)一些也更復(fù)雜。

---

九、服務(wù)安全選型

對于微服務(wù)安全認(rèn)證授權(quán)機(jī)制一塊，目前業(yè)界雖然有OAuth和OpenID connect等標(biāo)準(zhǔn)協(xié)議，但是各家具體實現(xiàn)的做法都不太一樣，企業(yè)一般有很多特殊的定制需求，整個社區(qū)還沒有形成通用生產(chǎn)級開箱即用的產(chǎn)品。

有一些開源授權(quán)服務(wù)器產(chǎn)品，比較知名的如Apereo CAS[附錄12.37]（github 3.6k stars），JBoss開源的keycloak[附錄12.38]（github 1.9 stars），spring cloud security[附錄12.39]等，大都是opinionated（一家觀點和做法）的產(chǎn)品，同時因支持太多協(xié)議造成產(chǎn)品復(fù)雜，也缺乏足夠靈活性。個人建議基于OAuth和OpenID connect標(biāo)準(zhǔn)，在參考一些開源產(chǎn)品的基礎(chǔ)上（例如Mitre開源的OpenID-Connect-Java-Spring-Server[附錄12.40]，github 0.62k stars），定制自研輕量級授權(quán)服務(wù)器。Wso2提出了一種微服務(wù)安全的參考方案[附錄12.45]，建議參考，該方案的關(guān)鍵步驟如下：

使用支持OAuth 2.0和OpenID Connect標(biāo)準(zhǔn)協(xié)議的授權(quán)服務(wù)器（個人建議定制自研）；

使用API網(wǎng)關(guān)作為單一訪問入口，統(tǒng)一實現(xiàn)安全治理；

客戶在訪問微服務(wù)之前，先通過授權(quán)服務(wù)器登錄獲取access token，然后將access token和請求一起發(fā)送到網(wǎng)關(guān)；

網(wǎng)關(guān)獲取access token，通過授權(quán)服務(wù)器校驗token，同時做token轉(zhuǎn)換獲取JWT token。

網(wǎng)關(guān)將JWT Token和請求一起轉(zhuǎn)發(fā)到后臺微服務(wù)；

JWT中可以存儲用戶會話信息，該信息可以傳遞給后臺的微服務(wù)，也可以在微服務(wù)之間傳遞，用作認(rèn)證授權(quán)等用途；

每個微服務(wù)包含JWT客戶端，能夠解密JWT并獲取其中的用戶會話信息。

整個方案中，access token是一種by reference token，不包含用戶信息可以直接暴露在公網(wǎng)上；JWT token是一種by value token，可以包含用戶信息但不暴露在公網(wǎng)上。

---

十、服務(wù)部署平臺選型

容器已經(jīng)被社區(qū)接受為交付微服務(wù)的一種理想手段，可以實現(xiàn)不可變（immutable）發(fā)布模式。一個輕量級的基于容器的服務(wù)部署平臺主要包括容器資源調(diào)度，發(fā)布系統(tǒng)，鏡像治理，資源治理和IAM等模塊。

集群資源調(diào)度系統(tǒng)：屏蔽容器細(xì)節(jié)，將整個集群抽象成容器資源池，支持按需申請和釋放容器資源，物理機(jī)發(fā)生故障時能夠?qū)崿F(xiàn)自動故障遷移(fail over)。目前Google開源的kubernetes[附錄12.41]，在Google背書和社區(qū)的強(qiáng)力推動下，基本已經(jīng)形成市場領(lǐng)導(dǎo)者地位，github上有31.8k星，社區(qū)的活躍度已經(jīng)遠(yuǎn)遠(yuǎn)超過了mesos[附錄12.42]（github 3.5k stars）和swarm等競爭產(chǎn)品，所以容器資源調(diào)度建議首選k8s。當(dāng)然如果你的團(tuán)隊有足夠定制自研能力，想深度把控底層調(diào)度算法，也可以基于mesos做定制自研。

鏡像治理：基于docker registry，封裝一些輕量級的治理功能。vmware開源的harbor[附錄12.43] (github 3.5k stars)是目前社區(qū)比較成熟的企業(yè)級產(chǎn)品，在docker registry基礎(chǔ)上擴(kuò)展了權(quán)限控制，審計，鏡像同步，管理界面等治理能力，可以考慮采用。

資源治理：類似于CMDB思路，在容器云環(huán)境中，企業(yè)仍然需要對應(yīng)用app，組織org，容器配額和數(shù)量等相關(guān)信息進(jìn)行輕量級的治理。目前這塊還沒有生產(chǎn)級的開源產(chǎn)品，一般企業(yè)需要根據(jù)自己的場景定制自研。

發(fā)布平臺：面向用戶的發(fā)布管理控制臺，支持發(fā)布流程編排。它和其它子系統(tǒng)對接交互，實現(xiàn)基本的應(yīng)用發(fā)布能力，也實現(xiàn)如藍(lán)綠，金絲雀和灰度等高級發(fā)布機(jī)制。目前這塊生產(chǎn)級的開源產(chǎn)品很少，Netflix開源的spinnaker[附錄12.44]（github 4.2k stars）是一個，但是這個產(chǎn)品比較復(fù)雜重量（因為它既要支持適配對接各種CI系統(tǒng)，同時還要適配對接各種公有云和容器云，使得整個系統(tǒng)異常復(fù)雜），一般企業(yè)建議根據(jù)自己的場景定制自研輕量級的解決方案。

IAM：是identity & access management的簡稱，對發(fā)布平臺各個組件進(jìn)行身份認(rèn)證和安全訪問控制。社區(qū)有不少開源的IAM產(chǎn)品，比較知名的有Apereo CAS（github 3.6k stars），JBoss開源的keycloak（github 1.9 stars）等。但是這些產(chǎn)品一般都比較復(fù)雜重量，很多企業(yè)考慮到內(nèi)部各種系統(tǒng)靈活對接的需求，都會考慮定制自研輕量級的解決方案。

考慮到服務(wù)部署平臺目前還沒有端到端生產(chǎn)級解決方案，企業(yè)一般需要定制集成，下面給出一個可以參考的具備輕量級治理能努力的發(fā)布體系：

簡化發(fā)布流程如下：

應(yīng)用通過CI集成后生成鏡像，用戶將鏡像推到鏡像治理中心；

用戶在資產(chǎn)治理中心申請發(fā)布，填報應(yīng)用，發(fā)布和配額相關(guān)信息，然后等待審批通過；

發(fā)布審批通過，開發(fā)人員通過發(fā)布控制臺發(fā)布應(yīng)用；

發(fā)布系統(tǒng)通過查詢資產(chǎn)治理中心獲取發(fā)布規(guī)格信息；

發(fā)布系統(tǒng)向容器云發(fā)出啟動容器實例指令；

容器云從鏡像治理中心拉取鏡像并啟動容器；

容器內(nèi)服務(wù)啟動后自注冊到服務(wù)注冊中心，并保持定期心跳；

用戶通過發(fā)布系統(tǒng)調(diào)用服務(wù)注冊中心調(diào)撥流量，實現(xiàn)藍(lán)綠，金絲雀或灰度發(fā)布等機(jī)制；

網(wǎng)關(guān)和內(nèi)部微服務(wù)客戶端定期同步服務(wù)注冊中心上的服務(wù)路由表，將流量按負(fù)載均衡策略分發(fā)到新的服務(wù)實例上。

另外，持續(xù)交付流水線（CD Pipeline）也是微服務(wù)發(fā)布重要環(huán)節(jié)，這塊主要和研發(fā)流程相關(guān)，一般需要企業(yè)定制，下面是一個可供參考的流水線模型，在鏡像治理中心上封裝一些輕量級的治理流程，例如只有通過測試環(huán)境測試的鏡像才能升級發(fā)布到UAT環(huán)境，只有通過UAT環(huán)境測試的鏡像才能升級發(fā)布到生產(chǎn)環(huán)境，通過在流水線上設(shè)置一些質(zhì)量門，保障應(yīng)用高質(zhì)量交付到生產(chǎn)。

---

十一、寫在最后

注意，本文限于篇幅，對測試和CI等環(huán)節(jié)沒有涉及，但它們同樣是構(gòu)建微服務(wù)架構(gòu)的重要環(huán)節(jié)，也有眾多成熟的開源成熟產(chǎn)品可選。

技術(shù)選型雖然重要，但還只是微服務(wù)建設(shè)的一小部分工作，選型后的產(chǎn)品要在企業(yè)內(nèi)部真正落地，形成完整的微服務(wù)技術(shù)棧體系，則后續(xù)還有大量集成、定制、治理、運(yùn)維和推廣等工作。

本文僅限個人經(jīng)驗視角，選型思路僅供參考借鑒。每個企業(yè)的具體上下文（業(yè)務(wù)場景，團(tuán)隊組織，技術(shù)架構(gòu)等）各不相同，每個架構(gòu)師的背景經(jīng)驗也各不相同，大家要結(jié)合實際自己做出選型，沒有最好的技術(shù)棧，只有相對較合適的技術(shù)棧。另外，好的技術(shù)選型是相互借鑒甚至PK出來的，歡迎大家討論，給出自己的微服務(wù)2.0技術(shù)棧選型意見。

附錄

Spring Boot
https://github.com/spring-projects/spring-boot
Alibaba Dubbo
https://github.com/alibaba/dubbo
Google gRPC
https://github.com/grpc/grpc
NetflixOSS Eureka
https://github.com/Netflix/eureka
Hashicorp Consul
https://github.com/hashicorp/consul
NetflixOSS Zuul
https://github.com/Netflix/zuul
Kong
https://github.com/Kong/kong
Spring Cloud Config
https://github.com/spring-cloud/spring-cloud-config
CTrip Apollo
https://github.com/ctripcorp/apollo
ElasticSearch
https://github.com/elastic/elasticsearch
Yelp Elastalert
https://github.com/Yelp/elastalert
Dianping CAT
https://github.com/dianping/cat
Zipkin
https://github.com/openzipkin/zipkin
Naver Pinpoint
https://github.com/naver/pinpoint
OpenTSDB
https://github.com/OpenTSDB/opentsdb
KairosDB
https://github.com/kairosdb/kairosdb
Argus
https://github.com/salesforce/Argus
InfluxDB
https://github.com/influxdata/influxdb
Prometheus
https://github.com/prometheus/prometheus
Grafana
https://github.com/grafana/grafana
Sensu
https://github.com/sensu/sensu
Esty 411
https://github.com/etsy/411
Zalando ZMon
https://github.com/zalando/zmon
NetflixOSS Hystrix
https://github.com/Netflix/Hystrix
Nginx
https://github.com/nginx/nginx
Apache Kafka
https://github.com/apache/kafka
Allegro Hermes
https://github.com/allegro/hermes
Apache Rocketmq
https://github.com/apache/rocketmq
Rabbitmq
https://github.com/rabbitmq/rabbitmq-server
Sohutv CacheCloud
https://github.com/sohutv/cachecloud
Twitter twemproxy
https://github.com/twitter/twemproxy
CodisLab codis
https://github.com/CodisLabs/codis
Dangdang Sharding-jdbc
https://github.com/shardingjdbc/sharding-jdbc
MyCAT
https://github.com/MyCATApache/Mycat-Server
Xxl-job
https://github.com/xuxueli/xxl-job
Dangdang elastic-job
https://github.com/elasticjob/elastic-job-lite
Apereo CAS
https://github.com/apereo/cas
JBoss keycloak
https://github.com/keycloak/keycloak
Spring cloud security
https://github.com/spring-cloud/spring-cloud-security
OpenID-Connect-Java-Spring-Server
https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server
Google Kubernetes
https://github.com/kubernetes/kubernetes
Apache Mesos
https://github.com/apache/mesos
Vmware Harbor
https://github.com/vmware/harbor
Netflix Spinnaker
https://github.com/spinnaker/spinnaker
Microservices in Practice – Key Architecture Concepts of an MSA
https://wso2.com/whitepapers/microservices-in-practice-key-architectural-concepts-of-an-msa/
微服務(wù)的設(shè)計與生態(tài)系統(tǒng)
http://servicecomb.incubator.apache.org/assets/slides/20170619/MSAPrinciple&EcoSystem.pdf

總結(jié)

以上是生活随笔為你收集整理的微服务2.0技术栈选型手册，值得架构师借鉴的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。