微服務架構的中國式落地

前言

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

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

主要包含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、核心支撐組件

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、監控反饋組件

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可以保護微服務調用。

4、結論

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

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