微服務架構技術棧選型指南

一、前言

從 2014 年至今微服務技術生态又發生了巨大變化，容器、雲原生、ServiceMesh，Serverless  等新技術新理念層出不窮。在面對這些新技術我們如何運用他們建構我們的架構呢？本文将提供一個實踐方式給大家參考和借鑒。

二、選型準則

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

1.    生産級

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

2.    一線網際網路公司落地産品

我們會盡量采用在一線網際網路公司落地并且開源的，且在社群内形成良好口碑的産品，它們已經在這些公司經過流量沖擊，坑已經基本被填平，且被社群接受形成一個良好的社群生态（本文附錄部分會給出所有推薦使用或參考的開源項目的 GitHub 連結）。

3.    開源社群活躍度

GitHub 上的 stars 的數量是一個重要名額，同時會參考其代碼和文檔更新頻率（尤其是近年），這些名額直接反應開源産品的社群活躍度或者說生命力。

另外，對于不同業務體量和團隊規模的公司，技術選型标準往往是不同的，創業公司的技術選型和 BAT 級别公司的技術選型标準可能完全不同。本文主要針對日流量千萬以上，研發團隊規模不少于 50 人的公司，如果小于這個規模我建議認真評估是否真的需要采用微服務架構。考慮到 Java 語言在國内的流行度和我個人的背景經驗，本文主要針對采用 Java 技術棧的企業。本文也假定自建微服務基礎架構，有些産品其實有對應的雲服務可以直接使用，自建和采用雲服務各有利弊，架構師需要根據場景上下文綜合權衡。

三、微服務基礎架構關鍵點

下面腦圖中芒果色标注的七個子產品，我認為是建構微服務 2.0 技術棧的核心子產品，本文後面的選型會分别基于這些子產品展開。對于每個子產品我也列出一些核心架構關注點，在選擇具體産品時，需要盡可能覆寫到這些關注點。

下圖是我近期工作總結和參考的一個微服務技術體系，我想同時分享給一線架構師或者工程師參考，其中粉紅色标注的子產品是和微服務關系最密切的子產品，大家在做技術選型時，可以同時對照這個體系。

四、服務架構選型

服務架構是一個比較成熟的領域，有太多可選項。Spring Boot/Cloud[附錄 12.1] 由于 Spring 社群的影響力和 Netflix 的背書，目前可以認為是建構 Java 微服務的一個社群标準，Spring Boot 目前在 GitHub 上有超過 20k 星。

基于 Spring 的架構本質上可以認為是一種 RESTful 架構（不是 RPC 架構），序列化協定主要采用基于文本的 JSON，通訊協定一般基于 HTTP。RESTful 架構天然支援跨語言，任何語言隻要有 HTTP 用戶端都可以接入調用，但是用戶端一般需要自己解析 payload。目前 Spring 架構也支援 Swagger 契約程式設計模型，能夠基于契約生成各種語言的強類型用戶端，極大友善不同語言棧的應用接入，但是因為 RESTful 架構和 Swagger 規範的弱契約特性，生成的各種語言用戶端的互操作性還是有不少坑的。

Dubbo[附錄 12.2] 是阿裡多年建構生産級分布式微服務的技術結晶，服務治理能力非常豐富，在國内技術社群具有很大影響力，目前 github 上有超過 16k 星。Dubbo 本質上是一套基于 Java 的 RPC 架構，當當 Dubbox 擴充了 Dubbo 支援 RESTful 接口暴露能力。

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

gRPC[附錄 12.3] 是谷歌近年新推的一套 RPC 架構，基于 protobuf 的強契約程式設計模型，能自動生成各種語言用戶端，且保證互操作。支援 HTTP2 是 gRPC 的一大亮點，通訊層性能比 HTTP 有很大改進。Protobuf 是在社群具有悠久曆史和良好口碑的高性能序列化協定，加上 Google 公司的背書和社群影響力，目前 gRPC 也比較火，GitHub 上有超過 13.4k 星。

目前看 gRPC 更适合内部服務互相調用場景，對外暴露 RESTful 接口可以實作，但是比較麻煩（需要 gRPC Gateway 配合），是以對于對外暴露 API 場景可能還需要引入第二套 RESTful 架構作為補充。總體上 gRPC 這個東西還比較新，社群對于 HTTP2 帶來的好處還未形成一緻認同，建議謹慎投入，可以做一些試點。

五、運作時支撐服務選型

運作時支撐服務主要包括服務注冊中心，服務路由網關和集中式配置中心三個産品。

服務注冊中心，如果采用 Spring Cloud 體系，則選擇 Eureka[附錄 12.4] 是最佳搭配，Eureka 在 Netflix 經過大規模生産驗證，支援跨資料中心，用戶端配合 Ribbon 可以實作靈活的用戶端軟負載，Eureka 目前在 GitHub 上有超過 4.7k 星；Consul[附錄 12.5] 也是不錯選擇，天然支援跨資料中心，還支援 KV 模型存儲和靈活健康檢查能力，目前在 GitHub 上有超過 11k 星。

服務網關也是一個比較成熟的領域，有很多可選項。如果采用 Spring Cloud 體系，則選擇 Zuul[附錄 12.6] 是最佳搭配，Zuul 在 Netflix 經過大規模生産驗證，支援靈活的動态過濾器腳本機制，異步性能不足（基于 Netty 的異步 Zuul 遲遲未能推出正式版）。Zuul 網關目前在 github 上有超過 3.7k 星。基于 Nginx/OpenResty 的 API 網關 Kong[附錄 12.7] 目前在 github 上比較火，有超過 14.1k 星。因為采用 Nginx 核心，Kong 的異步性能較強，另外基于 lua 的插件機制比較靈活，社群插件也比較豐富，從安全到限流熔斷都有，還有不少開源的管理界面，能夠集中管理 Kong 叢集。

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

六、服務監控選型

主要包括日志監控，調用鍊監控，Metrics 監控，健康檢查和告警通知等産品。

ELK 目前可以認為是日志監控的标配，功能完善開箱即用，ElasticSearch[附錄 12.10] 目前在 GitHub 上有超過 28.4k 星。Elastalert[附錄 12.11] (GitHub 4k stars) 是 Yelp 開源的針對 ELK 的告警通知子產品。

調用鍊監控目前社群主流是點評 CAT[附錄 12.12]（GitHub 4.3k stars），Twitter 之前開源現在由 OpenZipkin 社群維護的 Zipkin[附錄 12.13]（GitHub 7.5k stars）和 Naver 開源的 Pinpoint[附錄 12.14]（GitHub 5.3k stars）。個人比較推薦點評開源的 CAT，在點評和國内多家網際網路公司有落地案例，生産級特性和治理能力較完善，另外 CAT 自帶告警子產品。下面是我之前對三款産品的評估表，供參考。

Metrics 監控主要依賴于時間序列資料庫 (TSDB)，目前較成熟的産品是 StumbleUpon 公司開源的基于 HBase 的 OpenTSDB[附錄 12.15]（基于 Cassandra 的 KariosDB[附錄 12.16] 也是一個選擇，GitHub 1.1k stars，它基本上是 OpenTSDB 針對 Cassandra 的一個改造版），OpenTSDB 具有分布式能力可以橫向擴充，但是相對較重，适用于中大規模企業，OpenTSDB 目前在 GitHub 上有近 2.9k 星。

OpenTSDB 本身不提供告警子產品，Argus[附錄 12.17]（GitHub 0.29k 星）是 Salesforce 開源的基于 OpenTSDB 的統一監控告警平台，支援豐富的告警函數和靈活的告警配置，可以作為 OpenTSDB 的告警補充。近年也出現一些輕量級的 TSDB，如 InfluxDB[附錄 12.18]（GitHub 12.4k stars）和 Prometheus[附錄 12.19]（GitHub 14.3k stars），這些産品函數報表能力豐富，自帶告警子產品，但是分布式能力不足，适用于中小規模企業。Grafana[附錄 12.20]（GitHub 19.9k stars）是 Metrics 報表展示的社群标配。

社群還有一些通用的健康檢查和告警産品，例如 Sensu[附錄 12.21]（GitHub 2.7k stars），能夠對各種服務（例如 Spring Boot 暴露的健康檢查端點，時間序列資料庫中的 metrics，ELK 中的錯誤日志等）定制靈活的健康檢查 (check)，然後使用者可以針對 check 結果設定靈活的告警通知政策。Sensu 在 Yelp 等公司有落地案例。其它類似産品還有 Esty 開源的 411[附錄 12.22]（GitHub 0.74k 星）和 Zalando 的 ZMon[附錄 12.23] (GitHub 0.15k 星)，它們是分别在 Esty 和 Zalando 落地的産品，但是定制 check 和告警配置的使用門檻比較高，社群不熱，建議有定制自研能力的團隊試用。ZMon 背景采用 KairosDB 存儲，如果企業已經采用 KariosDB 作為時間序列資料庫，則可以考慮 ZMon 作為告警通知子產品。

七、服務容錯選型

針對 Java 技術棧，Netflix 的 Hystrix[附錄 12.24]（github 12.4k stars）把熔斷、隔離、限流和降級等能力封裝成元件，任何依賴調用（資料庫，服務，緩存）都可以封裝在 Hystrix Command 之内，封裝後自動具備容錯能力。Hystrix 起源于 Netflix 的彈性工程項目，經過 Netflix 大規模生産驗證，目前是容錯元件的社群标準，GitHub 上有超 12k 星。其它語言棧也有類似 Hystrix 的簡化版本元件。

Hystrix 一般需要在應用端或者架構内埋點，有一定的使用門檻。對于采用集中式反向代理（邊界和内部）做服務路由的公司，則可以集中在反向代理上做熔斷限流，例如采用 Nginx[附錄 12.25]（GitHub 5.1k stars）或者 Kong[附錄 12.7]（GitHub 11.4k stars）這類反向代理，它們都插件支援靈活的限流容錯配置。Zuul 網關也可以內建 Hystrix 實作網關層集中式限流容錯。集中式反向代理需要有一定的研發和運維能力，但是可以對限流容錯進行集中治理，可以簡化用戶端。

八、背景服務選型

背景服務主要包括消息系統，分布式緩存，分布式資料通路層和任務排程系統。背景服務是一個相對比較成熟的領域，很多開源産品基本可以開箱即用。

消息系統，對于日志等可靠性要求不高的場景，則 Apache 頂級項目 Kafka[附錄 12.26]（GitHub 7.2k stars）是社群标配。對于可靠性要求較高的業務場景，Kafka 其實也是可以勝任，但企業需要根據具體場景，對 Kafka 的監控和治理能力進行适當定制完善，Allegro 公司開源的 hermes[附錄 12.27]（GitHub 0.3k stars）是一個可參考項目，它在 Kafka 基礎上封裝了适合業務場景的企業級治理能力。阿裡開源的 RocketMQ[附錄 12.28]（GitHub 3.5k 星）也是一個不錯選擇，具備更多适用于業務場景的特性，目前也是 Apache 頂級項目。RabbitMQ[附錄 12.29]（GitHub 3.6k 星）是老牌經典的 MQ，隊列特性和文檔都很豐富，性能和分布式能力稍弱，中小規模場景可選。

對于緩存治理，如果傾向于采用用戶端直連模式（個人認為緩存直連更簡單輕量），則 SohuTv 開源的 cachecloud[附錄 12.30]（GitHub 2.5k stars）是一款不錯的 Redis 緩存治理平台，提供諸如監控統計，一鍵開啟，自動故障轉移，線上伸縮，自動化運維等生産級治理能力，另外其文檔也比較豐富。如果傾向采用中間層 Proxy 模式，則 Twitter 開源的 twemproxy[附錄 12.31]（GitHub 7.5k stars）和 CodisLab 開源的 codis[附錄 12.32]（GitHub 6.9k stars）是社群比較熱的選項。

對于分布式資料通路層，如果采用 Java 技術棧，則當當開源的 shardingjdbc[附錄 12.33]（GitHub 3.5k stars）是一個不錯的選項，分庫分表邏輯做在用戶端 jdbc driver 中，用戶端直連資料庫比較簡單輕量，建議中小規模場景采用。如果傾向采用資料庫通路中間層 proxy 模式，則從阿裡 Cobar 演化出來的社群開源分庫分表中間件 MyCAT[附錄 12.34]（GitHub 3.6k stars）是一個不錯選擇 。proxy 模式運維成本較高，建議中大規模場景，有一定架構自研和運維能力的團隊采用。

任務排程系統，個人推薦徐雪裡開源的 xxl-job[附錄 12.35]（GitHub 3.4k stars），部署簡單輕量，大部分場景夠用。當當開源的 elastic-job[附錄 12.36]（GitHub 3.2k stars）也是一個不錯選擇，相比 xxl-job 功能更強一些也更複雜。

九、服務安全選型

對于微服務安全認證授權機制一塊，目前業界雖然有 OAuth 和 OpenID connect 等标準協定，但是各家具體實作的做法都不太一樣，企業一般有很多特殊的定制需求，整個社群還沒有形成通用生産級開箱即用的産品。有一些開源授權伺服器産品，比較知名的如 Apereo CAS[附錄 12.37]（GitHub 3.6k stars），JBoss 開源的 keycloak[附錄 12.38]（GitHub 1.9 stars），spring cloud security[附錄 12.39] 等，大都是 opinionated（一家觀點和做法）的産品，同時因支援太多協定造成産品複雜，也缺乏足夠靈活性。個人建議基于 OAuth 和 OpenID connect 标準，在參考一些開源産品的基礎上（例如 Mitre 開源的 OpenID-Connect-Java-Spring-Server[附錄 12.40]，GitHub 0.62k stars），定制自研輕量級授權伺服器。Wso2 提出了一種微服務安全的參考方案 [附錄 12.45]，建議參考，該方案的關鍵步驟如下：

1. 使用支援 OAuth 2.0 和 OpenID Connect 标準協定的授權伺服器（個人建議定制自研）；
2. 使用 API 網關作為單一通路入口，統一實作安全治理；
3. 客戶在通路微服務之前，先通過授權伺服器登入擷取 access token，然後将 access token 和請求一起發送到網關；
4. 網關擷取 access token，通過授權伺服器校驗 token，同時做 token 轉換擷取 JWT token。
5. 網關将 JWT Token 和請求一起轉發到背景微服務；
6. JWT 中可以存儲使用者會話資訊，該資訊可以傳遞給背景的微服務，也可以在微服務之間傳遞，用作認證授權等用途；
7. 每個微服務包含 JWT 用戶端，能夠解密 JWT 并擷取其中的使用者會話資訊。
8. 整個方案中，access token 是一種 by reference token，不包含使用者資訊可以直接暴露在公網上；JWT token 是一種 by value token，可以包含使用者資訊但不暴露在公網上。

十、服務部署平台選型

容器已經被社群接受為傳遞微服務的一種理想手段，可以實作不可變（immutable）釋出模式。一個輕量級的基于容器的服務部署平台主要包括容器資源排程，釋出系統，鏡像治理，資源治理和 IAM 等子產品。

叢集資源排程系統：屏蔽容器細節，将整個叢集抽象成容器資源池，支援按需申請和釋放容器資源，實體機發生故障時能夠實作自動故障遷移 (fail over)。目前 Google 開源的 Kubernetes[附錄 12.41]，在 Google 背書和社群的強力推動下，基本已經形成市場上司者地位，GitHub 上有 31.8k 星，社群的活躍度已經遠遠超過了 mesos[附錄 12.42]（GitHub 3.5k stars）和 swarm 等競争産品，是以容器資源排程建議首選 K8s。當然如果你的團隊有足夠定制自研能力，想深度把控底層排程算法，也可以基于 Mesos 做定制自研。

鏡像治理：基于 Docker Registry，封裝一些輕量級的治理功能。VMware 開源的 harbor[附錄 12.43] (GitHub 3.5k stars) 是目前社群比較成熟的企業級産品，在 Docker Registry 基礎上擴充了權限控制，審計，鏡像同步，管理界面等治理能力，可以考慮采用。

資源治理：類似于 CMDB 思路，在容器雲環境中，企業仍然需要對應用 app，組織 org，容器配額和數量等相關資訊進行輕量級的治理。目前這塊還沒有生産級的開源産品，一般企業需要根據自己的場景定制自研。

釋出平台：面向使用者的釋出管理控制台，支援釋出流程編排。它和其它子系統對接互動，實作基本的應用釋出能力，也實作如藍綠，金絲雀和灰階等進階釋出機制。目前這塊生産級的開源産品很少，Netflix 開源的 spinnaker[附錄 12.44]（github 4.2k stars）是一個，但是這個産品比較複雜重量（因為它既要支援适配對接各種 CI 系統，同時還要适配對接各種公有雲和容器雲，使得整個系統異常複雜），一般企業建議根據自己的場景定制自研輕量級的解決方案。

IAM：是 identity & access management 的簡稱，對釋出平台各個元件進行身份認證和安全通路控制。社群有不少開源的 IAM 産品，比較知名的有 Apereo CAS（GitHub 3.6k stars），JBoss 開源的 keycloak（GitHub 1.9 stars）等。但是這些産品一般都比較複雜重量，很多企業考慮到内部各種系統靈活對接的需求，都會考慮定制自研輕量級的解決方案。

考慮到服務部署平台目前還沒有端到端生産級解決方案，企業一般需要定制內建，下面給出一個可以參考的具備輕量級治理能力的釋出體系：

簡化釋出流程如下：

1. 應用通過 CI 內建後生成鏡像，使用者将鏡像推到鏡像治理中心；
2. 使用者在資産治理中心申請釋出，填報應用，釋出和配額相關資訊，然後等待審批通過；
3. 釋出審批通過，開發人員通過釋出控制台釋出應用；
4. 釋出系統通過查詢資産治理中心擷取釋出規格資訊；
5. 釋出系統向容器雲發出啟動容器執行個體指令；
6. 容器雲從鏡像治理中心拉取鏡像并啟動容器；
7. 容器内服務啟動後自注冊到服務注冊中心，并保持定期心跳；
8. 使用者通過釋出系統調用服務注冊中心調撥流量，實作藍綠，金絲雀或灰階釋出等機制；
9. 網關和内部微服務用戶端定期同步服務注冊中心上的服務路由表，将流量按負載均衡政策分發到新的服務執行個體上。

另外，持續傳遞流水線（CD Pipeline）也是微服務釋出重要環節，這塊主要和研發流程相關，一般需要企業定制，下面是一個可供參考的流水線模型，在鏡像治理中心上封裝一些輕量級的治理流程，例如隻有通過測試環境測試的鏡像才能更新釋出到 UAT 環境，隻有通過 UAT 環境測試的鏡像才能更新釋出到生産環境，通過在流水線上設定一些品質門，保障應用高品質傳遞到生産。

十一、寫在最後

注意，本文限于篇幅，對測試和 CI 等環節沒有涉及，但它們同樣是建構微服務架構的重要環節，也有衆多成熟的開源産品可選。

技術選型雖然重要，但還隻是微服務建設的一小部分工作，選型後的産品要在企業内部真正落地，形成完整的微服務技術棧體系，則後續還有大量內建、定制、治理、運維和推廣等工作。

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

十二、附錄連結

1. Spring Boot   
2. Alibaba Dubbo   
3. Google gRPC   
4. NetflixOSS Eureka   
5. Hashicorp Consul   
6. NetflixOSS Zuul   
7. Kong   
8. Spring Cloud Config   
9. CTrip Apollo   
10. ElasticSearch   
11. Yelp Elastalert   
12. Dianping CAT   
13. Zipkin   
14. Naver Pinpoint   
15. OpenTSDB   
16. KairosDB   
17. Argus   
18. InfluxDB   
19. Prometheus   
20. Grafana   
21. Sensu   
22. Esty 411   
23. Zalando ZMon   
24. NetflixOSS Hystrix   
25. Nginx   
26. Apache Kafka   
27. Allegro Hermes   
28. Apache Rocketmq   
29. Rabbitmq   
30. Sohutv CacheCloud   
31. Twitter twemproxy   
32. CodisLab codis   
33. Dangdang Sharding-jdbc   
34. MyCAT   
35. Xxl-job   
36. Dangdang elastic-job   
37. Apereo CAS   
38. JBoss keycloak   
39. Spring cloud security   
40. OpenID-Connect-Java-Spring-Server   
41. Google Kubernetes   
42. Apache Mesos   
43. Vmware Harbor   
44. Netflix Spinnaker   
45. Microservices in Practice – Key Architecture Concepts of an MSA