微服務架構技術棧

一、前言

2014 年可以認為是微服務 1.0 的元年，當年有幾個標誌性事件:

一是 Martin Fowler 在其博客上發表了」Microservices」一文，正式提出微服務架構風格；

二是 Netflix 微服務架構經過多年大規模生產驗證，最終抽象落地形成一整套開源的微服務基礎組件，統稱 NetflixOSS，Netflix 的成功經驗開始被業界認可並推崇；

三是 Pivotal 將 NetflixOSS 開源微服務組件集成到其 Spring 體系，推出 Spring Cloud 微服務開發技術棧。

基於近年在微服務基礎架構方面的實戰經驗和平時的學習積累，我想總結並提出一些構建微服務 2.0 技術棧的選型思路，供各位在一線實戰的架構師、工程師參考借鑒。對於一些暫時還沒有成熟開源產品的微服務支撐模塊，我也會給出一些定製自研的設計思路。

二、選型準則

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

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]，建議參考，該方案的關鍵步驟如下：

.

使用支持 OAuth 2.0 和 OpenID Connect 標準協議的授權伺服器（個人建議定製自研）；

使用 API 網關作為單一訪問入口，統一實現安全治理；

客戶在訪問微服務之前，先通過授權伺服器登錄獲取 access token，然後將 access token 和請求一起發送到網關；

網關獲取 access token，通過授權伺服器校驗 token，同時做 token 轉換獲取 JWT token。

網關將 JWT Token 和請求一起轉發到後台微服務；

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

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

整個方案中，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）等。但是這些產品一般都比較複雜重量，很多企業考慮到內部各種系統靈活對接的需求，都會考慮定製自研輕量級的解決方案。

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

.

簡化發布流程如下：

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

用戶在資產治理中心申請發布，填報應用，發布和配額相關信息，然後等待審批通過；

發布審批通過，開發人員通過發布控制台發布應用；

發布系統通過查詢資產治理中心獲取發布規格信息；

發布系統向容器雲發出啟動容器實例指令；

容器雲從鏡像治理中心拉取鏡像並啟動容器；

容器內服務啟動後自註冊到服務註冊中心，並保持定期心跳；

用戶通過發布系統調用服務註冊中心調撥流量，實現藍綠，金絲雀或灰度發布等機制；

網關和內部微服務客戶端定期同步服務註冊中心上的服務路由表，將流量按負載均衡策略分發到新的服務實例上。

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

.

十一、寫在最後

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

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

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

.

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！