http://www.infoq.com/cn/articles/china-microservice-technique

前言

近年，Spring Cloud儼然已經成為微服務開發的主流技術棧，在國內開發者社區非常火爆。

我近年一直在一線互聯網公司（攜程，拍拍貸等）開展微服務架構實踐，根據我個人的一線實踐經驗和我平時對Spring Cloud的調研，我認為Spring Cloud技術棧中的有些組件離生產級開發尚有一定距離。

比方說Spring Cloud Config和Spring Cloud Sleuth都是Pivotal自研產品，尚未得到大規模企業級生產應用，很多企業級特性缺失（具體見我后文描述）。另外Spring Cloud體系還缺失一些關鍵的微服務基礎組件，比如Metrics監控，健康檢查和告警等。

所以我在參考Spring Cloud微服務技術棧的基礎上，結合自身的實戰落地經驗，也結合國內外一線互聯網公司（例如Netflix，點評，攜程，Zalando等）的開源實踐，綜合提出更貼近國內技術文化特色的輕量級的微服務參考技術棧。希望這個參考技術棧對一線的架構師（或者是初創公司）有一個好的指導，能夠少走彎路，快速落地微服務架構。

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

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

核心支撐組件

服務網關Zuul

服務注冊發現Eureka+Ribbon

服務配置中心Apollo

認證授權中心Spring Security OAuth2

服務框架Spring MVC/Boot

監控反饋組件

數據總線Kafka

日志監控ELK

調用鏈監控CAT

Metrics監控KairosDB

健康檢查和告警ZMon

限流熔斷和流聚合Hystrix/Turbine

后續章節我會依次簡單介紹這11個組件，在《微服務架構實戰160講》課程中，我會對其中的8款核心組件的架構設計和生產實踐進行深度剖析，，感興趣的同學可以掃描下方二維碼了解詳情。

核心支撐組件

服務網關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）。

服務注冊發現Eureka + Ribbon

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

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

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

Ribbon是蝴蝶結的意思

服務配置中心Apollo

Spring Cloud體系里頭有個Spring Cloud Config產品，但是功能遠遠達不到生產級，只能小規模場景下用，中大規模企業級場景不建議采用。攜程框架研發部開源的Apollo是一款在攜程和其它眾多互聯網公司生產落地下來的產品，開源兩年多，目前在github上有超過4k星，非常成功，文檔齊全也是它的一大亮點，推薦作為企業級的配置中心產品。Apollo支持完善的管理界面，支持多環境，配置變更實時生效，權限和配置審計等多種生產級功能。Apollo既可以用于連接字符串等常規配置場景，也可用于發布開關（Feature Flag）和業務配置等高級場景。在《微服務架構實戰160講》課程中，第二個模塊就配置中心相關主題，會深度剖析攜程Apollo的架構和實踐，預計6月份推出，歡迎大家關注學習。

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

認證授權中心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緩存令牌，和微服務網關對接等，才能作為生產級使用。在《2018波波的微服務基礎架構和實踐》課程中，第一個模塊就是微服務安全架構和實踐相關主題，會深度剖析OAuth2原理和Spring Security OAuth2實踐，歡迎大家關注學習。

Spring Security OAuth2 是 Spring Security框架的一個擴展

服務框架Spring/Boot

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

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

監控反饋組件

數據總線Kafka

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

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

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

日志監控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參考部署架構

調用鏈監控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報表

Metrics監控KariosDB

除了日志和調用鏈，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展示標配，和主流時間序列數據庫都可以集成

健康檢查和告警ZMon

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

ZMon分布式監控告警系統架構，底層基于KairosDB時間序列數據庫

限流熔斷和流聚合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能夠保護微服務調用。

結論

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

本文推薦的技術棧主要面向微服務基礎架構，也是《微服務架構實戰160講》課程要深度剖析的主題。在整個互聯網基礎技術平臺體系中，還有消息，任務，數據訪問層，發布系統，容器云平臺，分布式事務，分布式一致性，測試，CI/CD等其它重要主題，這些是波波在2019第三季和2020第四季要陸續推出的內容，請大家持續關注。

附錄

Interview: Adrian Cockcroft on High Availability, Best Practices, and Lessons Learned in the Cloud https://www.infoq.com/articles/cockcroft-high-availability

Netflix云端開源工具Hystrix：曾助奧巴馬競選 http://it.sohu.com/20121129/n358943361.shtml

轉載于:https://www.cnblogs.com/davidwang456/articles/9128105.html

總結

以上是生活随笔為你收集整理的一个可供中小团队参考的微服务架构技术栈的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。