微服務架構的中國式落地

前言

近年，Spring Cloud儼然已經成為微服務開發的主流技術棧，在國內開發者社區非常火爆。我近年一直在一線互聯網公司（攜程，拍拍貸等）開展微服務架構實踐，根據我個人的一線實踐經驗和我平時對Spring Cloud的調研，我認為Spring Cloud技術棧中的有些組件離生產級開發尚有一定距離。，比方說Spring Cloud Config和Spring Cloud Sleuth都是Pivotal自研產品，尚未得到大規模企業級生產應用，很多企業級特性缺失（具體見我後文描述）。另外Spring Cloud體系還缺失一些關鍵的微服務基礎組件，比如Metrics監控，健康檢查和告警等。所以我在參考Spring Cloud微服務技術棧的基礎上，結合自身的實戰落地經驗，也結合國內外一線互聯網公司（例如Netflix，點評，攜程，Zalando等）的開源實踐，綜合提出更貼近國內技術文化特色的輕量級的微服務參考技術棧。希望這個參考技術棧對一線的架構師（或者是初創公司）有一個好的指導，能夠少走彎路，快速落地微服務架構。

這個參考技術棧和總體架構如下圖所示：

中國式微服務技術棧2.0

主要包含11大核心組件，分別是：

核心支撐組件:

1. 服務網關Zuul

2. 服務註冊發現Eureka+Ribbon

3. 服務配置中心Apollo

4. 認證授權中心Spring Security OAuth2

5. 服務框架Spring MVC/Boot

監控反饋組件:

1. 數據匯流排Kafka

2. 日誌監控ELK

3. 調用鏈監控CAT

4. Metrics監控KairosDB

5. 健康檢查和告警ZMon

6. 限流熔斷和流聚合Hystrix/Turbine

二、核心支撐組件

2.1 服務網關Zuul

2013年左右，infoq曾經對前Netflix架構總監Adrian Cockcroft有過一次專訪[附錄1]，其中有問Adrian：“Netflix開源這麼多項目，你認為哪一個是最不可或缺的(MOST Indispensable)”，Adrian回答說：“在NetflixOSS開源項目中，有一個容易被忽略，但是Netflix最強大的基礎服務之一，它就是Zuul網關服務。Zuul網關主要用於智能路由，同時也支持認證，區域和內容感知路由，將多個底層服務聚合成統一的對外API。Zuul網關的一大亮點是動態可編程，配置可以秒級生效”。從Adrian的回答中，我們可以感受到Zuul網關對微服務基礎架構的重要性。

Zuul在英文中是一種怪獸，星際爭霸中蟲族裡頭也有Zuul，Netflix為網關起名Zuul，寓意看門神獸

Zuul網關在Netflix經過生產級驗證，在納入Spring Cloud體系之後，在社區中也有眾多成功的應用。Zuul網關在攜程（日流量超50億），拍拍貸等公司也有成功的落地實踐，是微服務基礎架構中網關一塊的首選。其它開源產品像Kong或者Nginx等也可以改造支持網關功能，但是較複雜門檻高一點。

Zuul網關雖然不完全支持非同步，但是同步模型反而使它簡單輕量，易於編程和擴展，當然同步模型需要做好限流熔斷（和限流熔斷組件Hystrix配合），否則可能造成資源耗盡甚至雪崩效應（cascading failure）。

2.2 服務註冊發現Eureka + Ribbon

針對微服務註冊發現場景，社區裡頭的開源產品當中，經過生產級大流量驗證的，目前只有Netflix Eureka一個，它也已經納入Spring Cloud體系，在社區中有眾多成功應用，例如攜程Apollo配置中心也是使用Eureka做軟負載。其它產品如Zookeeper/Etcd/Consul等，都是比較通用的產品，還需要進一步封裝定製才可生產級使用。Eureka支持跨數據中心高可用，但它是AP最終一致系統，不是強一致性系統。

Eureka是阿基米德洗澡時發現浮力原理時發出的驚嘆聲，在微服務中寓意發現

Ribbon是可以和Eureka配套對接的客戶端軟負載庫，在Eureka的配合下能夠支持多種靈活的動態路由和負載均衡策略。內部微服務直連可以直接走Ribbon客戶端軟負載，網關上也可以部署Ribbon，這時網關相當於一個具有路由和軟負載能力的超級客戶端。

2.3 服務配置中心Apollo

Spring Cloud體系裡頭有個Spring Cloud Config產品，但是功能遠遠達不到生產級，只能小規模場景下用，中大規模企業級場景不建議採用。攜程框架研發部開源的Apollo是一款在攜程和其它眾多互聯網公司生產落地下來的產品，開源兩年多，目前在github上有超過4k星，非常成功，文檔齊全也是它的一大亮點，推薦作為企業級的配置中心產品。Apollo支持完善的管理界面，支持多環境，配置變更實時生效，許可權和配置審計等多種生產級功能。Apollo既可以用於連接字元串等常規配置場景，也可用於發佈開關（Feature Flag）和業務配置等高級場景。

阿波羅是希臘神話中太陽神的意思

2.4 認證授權中心Spring Security OAuth2

目前開源社區還沒有特別成熟的微服務安全認證中心產品，之前我工作過的一些中大型互聯網公司，比如攜程，唯品會等，在這一塊基本都是定製自研的，但是對一般企業來說，定製自研還是有門檻的。OAuth2是一種基於令牌Token的授權框架，已經得到眾多大廠（Google, Facebook, Twitter, Microsoft等）的支持，可以認為是事實上的微服務安全協議標準，適用於開放平臺聯合登錄，現代微服務安全（包括單頁瀏覽器App/無線原生App/伺服器端WebApp接入微服務，以及微服務之間調用等場景），和企業內部應用認證授權(IAM/SSO)等多種場景。

Spring Security OAuth2是Spring Security基礎上的一個擴展，支持四種主要的OAuth2 Flows，基本可以作為微服務認證授權中心的推薦產品。但是Spring Security OAuth2還只是一個框架，不是一個端到端的開箱即用的產品，企業級應用仍需在其上進行定製，例如提供Web端管理界面，對接企業內部的用戶認證登錄系統，使用Cache緩存令牌，和微服務網關對接等，才能作為生產級使用。在這裡給大家推薦一個架構交流群650385180，裡面會分享一些資深架構師錄製的視頻錄像：有Spring，MyBatis，Netty源碼分析，高併發、高性能、分散式、微服務架構的原理，JVM性能優化這些成為架構師必備的知識體系。還能領取免費的學習資源，以下的知識體系圖也是在群里獲取。相信對於已經工作和遇到技術瓶頸的碼友，在這個群里一定有你需要的內容。

2.5 服務框架Spring Boot

Spring可以說是史上最成功的Web App/API開發框架之一，它融入了Java社區中多年來沉澱下來的最佳實踐，雖然有將近15年曆史，但目前的社區活躍度仍呈上升趨勢。Spring Boot在Spring的基礎上進一步打包封裝，提供更貼心的Starter工程，自啟動能力，自動依賴管理，基於代碼的配置等特性進一步降低接入門檻。另外Spring Boot也提供actuator這樣的生產級監控特性，支持DevOps研發模式，它是微服務開發框架的推薦首選。

REST契約規範Swagger和Spring有比較好的集成，使得Spring也支持契約驅動開發(Contract Driven Development)模型。對於一些中大規模的企業，如果業務複雜團隊較多，考慮到互操作性和集成成本，建議採用契約驅動開發模型，也就是開發時先定義Swagger契約，然後再通過契約生成服務端介面和客戶端，再實現服務端業務邏輯，這種開發模型能夠標準化介面，降低系統間集成成本，對於多團隊協同並行開發非常重要。

Spring Boot Logo

三、監控反饋組件

3.1 數據匯流排Kafka

最初由Linkedin研發併在其內部大規模成功應用，然後在Apache上開源的Kafka，是業內數據匯流排(Databus)一塊的標配，幾乎每一家互聯網公司都可以看到Kafka的身影。Kafka堪稱開源項目的一個經典成功案例，其創始人團隊從Linkedin離職後還專門成立了一家叫confluent的企業軟體服務公司，圍繞Kafka周邊提供配套和增值服務。在監控一塊，日誌和Metrics等數據可以通過Kafka做收集、存儲和轉發，相當於中間增加了一個大容量緩衝，能夠應對海量日誌數據的場景。除了日誌監控數據收集，Kafka在業務大數據分析，IoT等場景都有廣泛應用。如果對Kafka進行適當定製增強，還可以用於傳統消息中間件場景。

Kafka的特性是大容量，高吞吐，高可用，數據可重覆消費，可水平擴展，支持消費者組等。Kafka尤其適用於不嚴格要求實時和不丟數據的大數據日誌場景。

Kafka創始人三人組，離開Linkedin後，創立了基於Kafka的創業公司Confluent

3.2 日誌監控ELK

ELK（ElasticSearch/Logstash/Kibana）是日誌監控一塊的標配技術棧，幾乎每一家互聯網公司都可以看到ELK的身影，據稱攜程是國內ELK的最大用戶，每日增量日誌數據量達到80~90TB。ELK已經非常成熟，基本上是開箱即用，後續主要的工作在運維、治理和調優。ELK一般和Kafka配套使用，因為日誌分詞操作還是比較耗時的，Kafka主要作為前置緩衝，起到流量消峰作用，抵消日誌流量高峰和消費（分詞建索引）的不匹配問題。一旦反向索引建立，日誌檢索是非常快的，所以日誌檢索快和靈活是ElasticSearch的最大亮點。另外ELK還有大容量，高吞吐，高可用，可水平擴容等企業級特性。

創業公司起步期，考慮到資源時間限制，調用鏈監控和Metrics監控可以不是第一優先順序，但是ELK是必須搭一套的，應用日誌數據一定要收集並建立索引，基本能夠覆蓋大部分Trouble Shooting場景（業務，性能，程式bug等）。另外用好ELK的關鍵是治理，需要制定一些規則（比如只收集Warn級別以上日誌），對應用的日誌數據量做好監控，否則開發人員會濫用，什麼垃圾數據都往ELK裡頭丟，造成大量空間被浪費，嚴重的還可能造成性能可用性問題。

3.3 調用鏈監控CAT

Spring Cloud支持基於Zipkin的調用鏈監控，我個人基於實踐經驗認為Zipkin還不能算一款企業級調用鏈監控產品，充其量只能算是一個半成品，很多重要的企業級特性缺失。Zipkin最早是由Twitter在消化Google Dapper論文的基礎上研發，在Twitter內部有較成功應用，但是在開源出來的時候把不少重要的統計報表功能給閹割了（因為依賴於一些比較重的大數據分析平臺），只是開源了一個半成品，能簡單查詢和呈現可視化調用鏈，但是細粒度的調用性能數據報表沒有開源。

Google大致在2007年左右開始研發稱為Dapper的調用鏈監控系統，但在遠遠早於這個時間（大致在2002左右），eBay就已經有了自己的調用鏈監控系統CAL(Centralized Application Logging)，Google和eBay的設計思路大致相同，但是也有一些差別。CAL在eBay有大規模成功應用，被稱為是eBay的四大神器之一（另外三個是DAL，Messaging和SOA）。開源調用鏈監控系統CAT的作者吳其敏（我曾經和他同事，習慣叫他老吳），曾經在eBay工作近十年，期間深入消化吸收了CAL的設計。2011年後老吳離開eBay去了點評，用三年時間在點評再造了一款調用鏈監控產品CAT（Centralized Application Tracking），CAT具有CAL的基因和影子，同時也融入了老吳在點評的探索實踐和創新。

CAT是一款更完整的企業級調用鏈監控產品，甚至已經接近一個APM（Application Performance Management）產品的範疇，它不僅支持調用鏈的查詢和可視化，還支持細粒度的調用性能數據統計報表，這塊是CAT和市面上其它開源調用鏈監控產品最本質的差異點，實際上開發人員大部分時間用CAT是看性能統計報表（主要是CAT的Transaction和Problem報表），這些報表相當於給了開發人員一把尺子，可以自助測量並持續改進應用性能。另外CAT還支持應用報錯大盤，自助告警等功能，也是企業級監控非常實用的功能。

CAT在點評，攜程，陸金所，拍拍貸等公司有成功落地案例，因為是國產調用鏈監控產品，界面展示和功能等更契合國內文化，更易於在國內公司落地。個人推薦CAT作為微服務調用鏈監控的首選。至於社區裡頭有人提到CAT的侵入性問題，我覺得是要一分為二看，有利有弊，有耦合性但是性能更好，一般企業中基礎架構團隊會使用CAT統一為基礎組件埋點，開發人員一般不用自己埋點；另外企業用了一款調用鏈監控產品以後，一般是不會換的，開發人員用習慣就好了，侵入不是大問題。

3.4 Metrics監控KairosDB

除了日誌和調用鏈，Metrics也是應用監控的重要關註點。互聯網應用提倡度量驅動開發（Metrics Driven Development），也就是說開發人員不僅要關註功能實現，做好單元測試（TDD），還要做好業務層（例如註冊，登錄和下單數等）和應用層（例如調用數，調用延遲等）的監控埋點，這個也是DevOps（開發即運維）理念的體現，DevOps要求開發人員必須關註運維需求，監控埋點是一種生產級運維需求。

Metrics監控產品底層依賴於時間序列資料庫（TSDB），最近比較熱的開源產品有Prometheus和InfluxDB，社區用戶數量和反饋都不錯，可以採納。但是這些產品分散式能力比較弱，定製擴展門檻比較高，一般建議剛起步量不大的公司採用。如果企業業務和團隊規模發展到一定階段，建議考慮支持分散式能力的時間序列監控產品，例如KairosDB或者OpenTSDB，我本人對這兩款產品都有一些實踐經驗，KariosDB基於Cassandra，相對更輕量一點，建議中大規模公司採用，如果你們公司已經採用Hadoop/HBase，則OpenTSDB也是不錯選擇。

KairosDB一般也和Kafka配套使用，Kafka作為前置緩衝。另外註意使用KariosDB打點的話tag的值不能太離散，否則會有查詢性能問題，這個和KariosDB底層存儲結構有關係。Grafana是Metrics展示標配，可以和KariosDB無縫集成。

Grafana是Metrics展示標配，和主流時間序列資料庫都可以集成

3.5 健康檢查和告警ZMon

除了上述監控手段，我們仍需要健康檢查和告警系統作為配套的監控手段。ZMon是德國電商公司Zalando開源的一款健康檢查和告警平臺，具備強大靈活的監控告警能力。ZMon本質上可以認為是一套分散式監控任務調度平臺，它提供眾多的Check腳本（也可以自己再定製擴展），能夠對各種硬體資源或者目標服務（例如HTTP埠，Spring的Actuator端點，KariosDB中的Metrics，ELK中的錯誤日誌等等）進行定期的健康檢查和告警，它的告警邏輯和策略採用Python腳本實現，開發人員可以實現自助式告警。ZMon同時適用於系統，應用，業務，甚至端用戶體驗層的監控和告警。

ZMon分散式監控告警系統架構，底層基於KairosDB時間序列資料庫

3.6 限流熔斷和流聚合Hystrix+Turbine

2010年左右，Netflix也飽受分散式微服務系統中雪崩效應（Cascading Failure）的困擾，於是專門啟動了一個叫做彈性工程的項目來解決這個問題，Hystrix就是彈性工程最終落地下來的一個產品。Hystrix在Netflix微服務系統中大規模推廣應用後，雪崩效應問題基本得到解決，整個體統更具彈性。之後Netflix把Hystrix開源貢獻給了社區，短期獲得社區的大量正面反饋，目前Hystrix在github上有超過1.3萬顆星，據說支持奧巴馬總統選舉的系統也曾使用Hystrix進行限流熔斷保護[參考附錄2]，可見限流熔斷是分散式系統穩定性的強需求，Netflix很好的抓住了這個需求並給出了經過生產級驗證的解決方案。Hystrix已經被納入Spring Cloud體系，它是Java社區中限流熔斷組件的首選（目前還看不到第二個更好的產品）。

Turbine是和Hystrix配套的一個流聚合服務，能夠對Hystrix監控數據流進行聚合，聚合以後可以在Hystrix Dashboard上看到集群的流量和性能情況。

Hystrix在英文中是豪豬獸的意思，豪豬獸通過身上的刺保護自己，Netflix為限流熔斷組件起名Hystrix，寓意Hystrix能夠保護微服務調用。

四、結論

1. 技術棧沒有好壞之分，只有適合一說。本文推薦的技術棧主要基於我個人的實踐和總結，但是未必適合所有場景，畢竟每個企業的上下文各不相同。作為架構師你可以參考我推薦的技術棧，但不可拘泥照搬，你必須在深入理解分佈系統原理的基礎上，再結合企業實際場景靈活應用。

2. 本文推薦的技術棧主要面向微服務基礎架構，在整個互聯網基礎技術平臺體系中，還有消息，任務，數據訪問層，發佈系統，容器雲平臺，分散式事務，分散式一致性，測試，CI/CD等其它重要主題。