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

一晃三年過去，微服務技術生態(tài)又發(fā)生了巨大變化，容器，PaaS，Cloud Native，gRPC，ServiceMesh，Serverless等新技術新理念你方唱罷我登場，不知不覺我們又來到了微服務2.0時代?；诮暝谖⒎栈A架構方面的實戰(zhàn)經(jīng)驗和平時的學習積累，我想總結并提出一些構建微服務2.0技術棧的選型思路，供各位在一線實戰(zhàn)的架構師、工程師參考借鑒。對于一些暫時還沒有成熟開源產(chǎn)品的微服務支撐模塊，我也會給出一些定制自研的設計思路。

二、選型準側

對于技術選型，我個人有很多標準，其中下面三項是最重要的:

1. 生產(chǎn)級

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

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)。

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

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

另外，對于不同業(yè)務體量和團隊規(guī)模的公司，技術選型標準往往是不同的，創(chuàng)業(yè)公司的技術選型和BAT級別公司的技術選型標準可能完全不同。本文主要針對日流量千萬以上，研發(fā)團隊規(guī)模不少于50人的公司，如果小于這個規(guī)模我建議認真評估是否真的需要采用微服務架構?？紤]到Java語言在國內(nèi)的流行度和我個人的背景經(jīng)驗，本文主要針對采用Java技術棧的企業(yè)。本文也假定自建微服務基礎架構，有些產(chǎn)品其實有對應的云服務可以直接使用，自建和采用云服務各有利弊，架構師需要根據(jù)場景上下文綜合權衡。

三、微服務基礎架構核心關注點

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

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

四、服務框架選型

服務框架是一個比較成熟的領域，有太多可選項。Spring Boot/Cloud由于Spring社區(qū)的影響力和Netflix的背書，目前可以認為是構建Java微服務的一個社區(qū)標準，Spring Boot目前在github上有超過20k星?；赟pring的框架本質(zhì)上可以認為是一種RESTful框架（不是RPC框架），序列化協(xié)議主要采用基于文本的JSON，通訊協(xié)議一般基于HTTP。RESTful框架天然支持跨語言，任何語言只要有HTTP客戶端都可以接入調(diào)用，但是客戶端一般需要自己解析payload。目前Spring框架也支持Swagger契約編程模型，能夠基于契約生成各種語言的強類型客戶端，極大方便不同語言棧的應用接入，但是因為RESTful框架和Swagger規(guī)范的弱契約特性，生成的各種語言客戶端的互操作性還是有不少坑的。

Dubbo[附錄12.2]是阿里多年構建生產(chǎn)級分布式微服務的技術結晶，服務治理能力非常豐富，在國內(nèi)技術社區(qū)具有很大影響力，目前github上有超過16k星。Dubbo本質(zhì)上是一套基于Java的RPC框架，當當Dubbox擴展了Dubbo支持RESTful接口暴露能力。Dubbo主要面向Java 技術棧，跨語言支持不足是它的一個弱項，另外因為治理能力太豐富，以至于這個框架比較重，完全用好這個框架的門檻比較高，但是如果你的企業(yè)基本上投資在Java技術棧上，選Dubbo可以讓你在服務框架一塊站在較高的起點上，不管是性能還是企業(yè)級的服務治理能力，Dubbo都做的很出色。新浪微博開源的Motan（github 4k stars）也不錯，功能和Dubbo類似，可以認為是一個輕量裁剪版的Dubbo。

gRPC是谷歌近年新推的一套RPC框架，基于protobuf的強契約編程模型，能自動生成各種語言客戶端，且保證互操作。支持HTTP2是gRPC的一大亮點，通訊層性能比HTTP有很大改進。Protobuf是在社區(qū)具有悠久歷史和良好口碑的高性能序列化協(xié)議，加上Google公司的背書和社區(qū)影響力，目前gRPC也比較火，github上有超過13.4k星。目前看gRPC更適合內(nèi)部服務相互調(diào)用場景，對外暴露HTTP RESTful接口可以實現(xiàn)，但是比較麻煩（需要gRPC Gateway配合），所以對于對外暴露API場景可能還需要引入第二套HTTP RESTful框架作為補充?？傮w上gRPC這個東西還比較新，社區(qū)對于HTTP2帶來的好處還未形成一致認同，建議謹慎投入，可以做一些試點。

五、運行時支撐服務選型

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

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

服務網(wǎng)關也是一個比較成熟的領域，有很多可選項。如果采用Spring Cloud體系，則選擇Zuul是最佳搭配，Zuul在Netflix經(jīng)過大規(guī)模生產(chǎn)驗證，支持靈活的動態(tài)過濾器腳本機制，異步性能不足（基于Netty的異步Zuul遲遲未能推出正式版）。Zuul網(wǎng)關目前在github上有超過3.7k星?；贜ginx/OpenResty的API網(wǎng)關Kong目前在github上比較火，有超過14.1k星。因為采用Nginx內(nèi)核，Kong的異步性能較強，另外基于lua的插件機制比較靈活，社區(qū)插件也比較豐富，從安全到限流熔斷都有，還有不少開源的管理界面，能夠集中管理Kong集群。

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

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

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

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

調(diào)用鏈監(jiān)控目前社區(qū)主流是點評CAT（github 4.3k stars），Twitter之前開源現(xiàn)在由OpenZipkin社區(qū)維護的Zipkin（github 7.5k stars）和Naver開源的Pinpoint（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（基于Cassandra的KariosDB也是一個選擇，github 1.1k stars，它基本上是OpenTSDB針對Cassandra的一個改造版），OpenTSDB具有分布式能力可以橫向擴展，但是相對較重，適用于中大規(guī)模企業(yè)，OpenTSDB目前在github上有近2.9k星。OpenTSDB 本身不提供告警模塊，Argus（github 0.29k星）是Salesforce開源的基于OpenTSDB的統(tǒng)一監(jiān)控告警平臺，支持豐富的告警函數(shù)和靈活的告警配置，可以作為OpenTSDB的告警補充。近年也出現(xiàn)一些輕量級的TSDB，如InfluxDB（github 12.4k stars）和Prometheus（github 14.3k stars），這些產(chǎn)品函數(shù)報表能力豐富，自帶告警模塊，但是分布式能力不足，適用于中小規(guī)模企業(yè)。Grafana（github 19.9k stars）是Metrics報表展示的社區(qū)標配。

社區(qū)還有一些通用的健康檢查和告警產(chǎn)品，例如Sensu（github 2.7k stars），能夠對各種服務（例如spring boot暴露的健康檢查端點，時間序列數(shù)據(jù)庫中的metrics，ELK中的錯誤日志等）定制靈活的健康檢查(check)，然后用戶可以針對check結果設置靈活的告警通知策略。Sensu在Yelp等公司有落地案例。其它類似產(chǎn)品還有Esty開源的411（github 0.74k星）和Zalando的ZMon(github 0.15k星)，它們是分別在Esty和Zalando落地的產(chǎn)品，但是定制check和告警配置的使用門檻比較高，社區(qū)不熱，建議有定制自研能力的團隊試用。ZMon后臺采用KairosDB存儲，如果企業(yè)已經(jīng)采用KariosDB作為時間序列數(shù)據(jù)庫，則可以考慮ZMon作為告警通知模塊。

七、服務容錯選型

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

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

八、后臺服務選型

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

消息系統(tǒng)，對于日志等可靠性要求不高的場景，則Apache頂級項目Kafka（github 7.2k stars）是社區(qū)標配。對于可靠性要求較高的業(yè)務場景，kafka其實也是可以勝任，但企業(yè)需要根據(jù)具體場景，對 Kafka的監(jiān)控和治理能力進行適當定制完善，Allegro公司開源的hermes（github 0.3k stars）是一個可參考項目，它在Kafka基礎上封裝了適合業(yè)務場景的企業(yè)級治理能力。阿里開源的RocketMQ（github 3.5k星）也是一個不錯選擇，具備更多適用于業(yè)務場景的特性，目前也是Apache頂級項目。RabbitMQ（github 3.6k星）是老牌經(jīng)典的MQ，隊列特性和文檔都很豐富，性能和分布式能力稍弱，中小規(guī)模場景可選。

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

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

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

九、服務安全選型

對于微服務安全認證授權機制一塊，目前業(yè)界雖然有OAuth和OpenID connect等標準協(xié)議，但是各家具體實現(xiàn)的做法都不太一樣，企業(yè)一般有很多特殊的定制需求，整個社區(qū)還沒有形成通用生產(chǎn)級開箱即用的產(chǎn)品。有一些開源授權服務器產(chǎn)品，比較知名的如Apereo CAS（github 3.6k stars），JBoss開源的keycloakgithub 1.9 stars），spring cloud security等，大都是opinionated（一家觀點和做法）的產(chǎn)品，同時因支持太多協(xié)議造成產(chǎn)品復雜，也缺乏足夠靈活性。個人建議基于OAuth和OpenID connect標準，在參考一些開源產(chǎn)品的基礎上（例如Mitre開源的OpenID-Connect-Java-Spring-Server，github 0.62k stars），定制自研輕量級授權服務器。Wso2提出了一種微服務安全的參考方案，建議參考，該方案的關鍵步驟如下：

使用支持OAuth 2.0和OpenID Connect標準協(xié)議的授權服務器（個人建議定制自研）；

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

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

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

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

JWT中可以存儲用戶會話信息，該信息可以傳遞給后臺的微服務，也可以在微服務之間傳遞，用作認證授權等用途；

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

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

十、服務部署平臺選型

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

十一、寫在最后

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

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

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