本文分享自微信公眾號-波波微課，作者楊波。
一、前言
近年，Spring Cloud儼然已經成為微服務開發的主流技術棧，在國內開發者社區非常火爆。我近年一直在一線互聯網公司（攜程，拍拍貸等）開展微服務架構實踐，根據我個人的一線實踐經驗和我平時對Spring Cloud的調研，我認為Spring Cloud技術棧中的有些組件離生產級開發尚有一定距離。比方說Spring Cloud Config和Spring Cloud Sleuth都是Pivotal自研產品，尚未得到大規模企業級生產應用，很多企業級特性缺失（具體見我後文描述）。另外Spring Cloud體系還缺失一些關鍵的微服務基礎組件，比如Metrics監控，健康檢查和告警等。所以我在參考Spring Cloud微服務技術棧的基礎上，結合自身的實戰落地經驗，也結合國內外一線互聯網公司（例如Netflix，點評，攜程，Zalando等）的開源實踐，綜合提出更貼近國內技術文化特色的輕量級的微服務參考技術棧。希望這個參考技術棧對一線的架構師（或者是初創公司）有一個好的指導，能夠少走彎路，快速落地微服務架構。
這個參考技術棧和總體架構如下圖所示：
中國式微服務技術棧2.0
主要包含11大核心組件，分別是：
核心支撐組件:
- 服務網關Zuul
- 服務註冊發現Eureka+Ribbon
- 服務配置中心Apollo
- 認證授權中心Spring Security OAuth2
- 服務框架Spring MVC/Boot
監控反饋組件:
- 數據總線Kafka
- 日誌監控ELK
- 調用鏈監控CAT
- Metrics監控KairosDB
- 健康檢查和告警ZMon
- 限流熔斷和流聚合Hystrix/Turbine
二、核心支撐組件
2.1、服務網關Zuul
2013年左右，infoq曾經對前Netflix架構總監Adrian Cockcroft有過一次專訪，其中有問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，這時網關相當於一個具有路由和軟負載能力的超級客戶端。
Ribbon是蝴蝶結的意思
2.3、服務配置中心Apollo
Spring Cloud體系裡頭有個Spring Cloud Config產品，但是功能遠遠達不到生產級，只能小規模場景下用，中大規模企業級場景不建議採用。攜程框架研發部開源的Apollo是一款在攜程和其它眾多互聯網公司生產落地下來的產品，開源兩年多，目前在github上有超過4k星，非常成功，文檔齊全也是它的一大亮點，推薦作為企業級的配置中心產品。Apollo支持完善的管理界面，支持多環境，配置變更實時生效，權限和配置審計等多種生產級功能。Apollo既可以用於連接字符串等常規配置場景，也可用於發佈開關（Feature Flag）和業務配置等高級場景。在《2018波波的微服務基礎架構和實踐》課程中，第二個模塊就配置中心相關主題，會深度剖析攜程Apollo的架構和實踐，預計6月份推出，歡迎大家關注學習。
阿波羅是希臘神話中太陽神的意思
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緩存令牌，和微服務網關對接等，才能作為生產級使用。在波波在極客時間的《微服務架構實踐160講》課程中，第一個模塊就是微服務安全架構和實踐相關主題，會深度剖析OAuth2原理和Spring Security OAuth2實踐，歡迎大家關注學習。
Spring Security OAuth2是Spring Security框架的一個擴展
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裡頭丟，造成大量空間被浪費，嚴重的還可能造成性能可用性問題。
ELK + Kafka參考部署架構
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統一為基礎組件埋點，開發人員一般不用自己埋點；另外企業用了一款調用鏈監控產品以後，一般是不會換的，開發人員用習慣就好了，侵入不是大問題。
CAT的Transaction報表
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進行限流熔斷保護，可見限流熔斷是分佈式系統穩定性的強需求，Netflix很好的抓住了這個需求並給出了經過生產級驗證的解決方案。Hystrix已經被納入Spring Cloud體系，它是Java社區中限流熔斷組件的首選（目前還看不到第二個更好的產品）。
Turbine是和Hystrix配套的一個流聚合服務，能夠對Hystrix監控數據流進行聚合，聚合以後可以在Hystrix Dashboard上看到集群的流量和性能情況。
Hystrix在英文中是豪豬獸的意思，豪豬獸通過身上的刺保護自己，Netflix為限流熔斷組件起名Hystrix，寓意Hystrix能夠保護微服務調用。
四、結論
技術棧沒有好壞之分，只有適合一說。本文推薦的技術棧主要基於我個人的實踐和總結，但是未必適合所有場景，畢竟每個企業的上下文各不相同。作為架構師你可以參考我推薦的技術棧，但不可拘泥照搬，你必須在深入理解分佈系統原理的基礎上，再結合企業實際場景靈活應用。
本文所有權歸作者楊波，感謝分享！
閱讀更多 牛旦教育IT課堂 的文章
