從零開始搭建公司微服務(wù)架構(gòu)技術(shù)棧，這套架構(gòu)絕了...
近年，Spring Cloud 儼然已經(jīng)成為微服務(wù)開發(fā)的主流技術(shù)棧，在國內(nèi)開發(fā)者社區(qū)非常火爆。我近年一直在一線互聯(lián)網(wǎng)公司（攜程，拍拍貸等）開展微服務(wù)架構(gòu)實踐，根據(jù)我個人的一線實踐經(jīng)驗和我平時對 Spring Cloud 的調(diào)研，我認為 Spring Cloud 技術(shù)棧中的有些組件離生產(chǎn)級開發(fā)尚有一定距離。比方說 Spring Cloud Config 和 Spring Cloud Sleuth 都是 Pivotal 自研產(chǎn)品，尚未得到大規(guī)模企業(yè)級生產(chǎn)應(yīng)用，很多企業(yè)級特性缺失（具體見我后文描述）。
另外 Spring Cloud 體系還缺失一些關(guān)鍵的微服務(wù)基礎(chǔ)組件，比如 Metrics 監(jiān)控，健康檢查和告警等。所以我在參考 Spring Cloud 微服務(wù)技術(shù)棧的基礎(chǔ)上，結(jié)合自身的實戰(zhàn)落地經(jīng)驗，也結(jié)合國內(nèi)外一線互聯(lián)網(wǎng)公司（例如 Netflix，點評，攜程，Zalando 等）的開源實踐，綜合提出更貼近國內(nèi)技術(shù)文化特色的輕量級的微服務(wù)參考技術(shù)棧。希望這個參考技術(shù)棧對一線的架構(gòu)師（或者是初創(chuàng)公司）有一個好的指導，能夠少走彎路，快速落地微服務(wù)架構(gòu)。
這個參考技術(shù)棧和總體架構(gòu)如下圖所示：
主要包含 11 大核心組件，分別是：
核心支撐組件
服務(wù)網(wǎng)關(guān) Zuul
服務(wù)注冊發(fā)現(xiàn) Eureka+Ribbon
服務(wù)配置中心 Apollo
認證授權(quán)中心 Spring Security OAuth2
服務(wù)框架 Spring MVC/Boot
監(jiān)控反饋組件
數(shù)據(jù)總線 Kafka
日志監(jiān)控 ELK
調(diào)用鏈監(jiān)控 CAT
Metrics 監(jiān)控 KairosDB
健康檢查和告警 ZMon
限流熔斷和流聚合 Hystrix/Turbine
核心支撐組件
服務(wù)網(wǎng)關(guān) Zuul
2013 年左右，InfoQ 曾經(jīng)對前 Netflix 架構(gòu)總監(jiān) Adrian Cockcroft 有過一次專訪 [附錄 1]，其中有問 Adrian：“Netflix 開源這么多項目，你認為哪一個是最不可或缺的 (MOST Indispensable)”，Adrian 回答說：“在 NetflixOSS 開源項目中，有一個容易被忽略，但是 Netflix 最強大的基礎(chǔ)服務(wù)之一，它就是 Zuul 網(wǎng)關(guān)服務(wù)。Zuul 網(wǎng)關(guān)主要用于智能路由，同時也支持認證，區(qū)域和內(nèi)容感知路由，將多個底層服務(wù)聚合成統(tǒng)一的對外 API。Zuul 網(wǎng)關(guān)的一大亮點是動態(tài)可編程，配置可以秒級生效”。從 Adrian 的回答中，我們可以感受到 Zuul 網(wǎng)關(guān)對微服務(wù)基礎(chǔ)架構(gòu)的重要性。
Zuul 在英文中是一種怪獸，星際爭霸中蟲族里頭也有 Zuul，Netflix 為網(wǎng)關(guān)起名 Zuul，寓意看門神獸。
Zuul 網(wǎng)關(guān)在 Netflix 經(jīng)過生產(chǎn)級驗證，在納入 Spring Cloud 體系之后，在社區(qū)中也有眾多成功的應(yīng)用。Zuul 網(wǎng)關(guān)在攜程（日流量超 50 億），拍拍貸等公司也有成功的落地實踐，是微服務(wù)基礎(chǔ)架構(gòu)中網(wǎng)關(guān)一塊的首選。其它開源產(chǎn)品像 Kong 或者 Nginx 等也可以改造支持網(wǎng)關(guān)功能，但是較復雜門檻高一點。
Zuul 網(wǎng)關(guān)雖然不完全支持異步，但是同步模型反而使它簡單輕量，易于編程和擴展，當然同步模型需要做好限流熔斷（和限流熔斷組件 Hystrix 配合），否則可能造成資源耗盡甚至雪崩效應(yīng)（cascading failure）。
服務(wù)注冊發(fā)現(xiàn) Eureka + Ribbon
針對微服務(wù)注冊發(fā)現(xiàn)場景，社區(qū)里頭的開源產(chǎn)品當中，經(jīng)過生產(chǎn)級大流量驗證的，目前只有 Netflix Eureka 一個，它也已經(jīng)納入 Spring Cloud 體系，在社區(qū)中有眾多成功應(yīng)用，例如攜程 Apollo 配置中心也是使用 Eureka 做軟負載。其它產(chǎn)品如 Zookeeper/Etcd/Consul 等，都是比較通用的產(chǎn)品，還需要進一步封裝定制才可生產(chǎn)級使用。Eureka 支持跨數(shù)據(jù)中心高可用，但它是 AP 最終一致系統(tǒng)，不是強一致性系統(tǒng)。
Ribbon 是可以和 Eureka 配套對接的客戶端軟負載庫，在 Eureka 的配合下能夠支持多種靈活的動態(tài)路由和負載均衡策略。內(nèi)部微服務(wù)直連可以直接走 Ribbon 客戶端軟負載，網(wǎng)關(guān)上也可以部署 Ribbon，這時網(wǎng)關(guān)相當于一個具有路由和軟負載能力的超級客戶端。
Ribbon 是蝴蝶結(jié)的意思。
服務(wù)配置中心 Apollo
Spring Cloud 體系里頭有個 Spring Cloud Config 產(chǎn)品，但是功能遠遠達不到生產(chǎn)級，只能小規(guī)模場景下用，中大規(guī)模企業(yè)級場景不建議采用。攜程框架研發(fā)部開源的 Apollo 是一款在攜程和其它眾多互聯(lián)網(wǎng)公司生產(chǎn)落地下來的產(chǎn)品，開源兩年多，目前在 github 上有超過 4k 星，非常成功，文檔齊全也是它的一大亮點，推薦作為企業(yè)級的配置中心產(chǎn)品。
Apollo 支持完善的管理界面，支持多環(huán)境，配置變更實時生效，權(quán)限和配置審計等多種生產(chǎn)級功能。Apollo 既可以用于連接字符串等常規(guī)配置場景，也可用于發(fā)布開關(guān)（Feature Flag）和業(yè)務(wù)配置等高級場景。在《2018 波波的微服務(wù)基礎(chǔ)架構(gòu)和實踐》課程中，第二個模塊就配置中心相關(guān)主題，會深度剖析攜程 Apollo 的架構(gòu)和實踐，預計 6 月份推出，歡迎大家關(guān)注學習。
阿波羅是希臘神話中太陽神的意思
認證授權(quán)中心 Spring Security OAuth2
目前開源社區(qū)還沒有特別成熟的微服務(wù)安全認證中心產(chǎn)品，之前我工作過的一些中大型互聯(lián)網(wǎng)公司，比如攜程，唯品會等，在這一塊基本都是定制自研的，但是對一般企業(yè)來說，定制自研還是有門檻的。OAuth2 是一種基于令牌 Token 的授權(quán)框架，已經(jīng)得到眾多大廠（Google, Facebook, Twitter, Microsoft 等）的支持，可以認為是事實上的微服務(wù)安全協(xié)議標準，適用于開放平臺聯(lián)合登錄，現(xiàn)代微服務(wù)安全（包括單頁瀏覽器 App/ 無線原生 App/ 服務(wù)器端 WebApp 接入微服務(wù)，以及微服務(wù)之間調(diào)用等場景），和企業(yè)內(nèi)部應(yīng)用認證授權(quán) (IAM/SSO) 等多種場景。
Spring Security OAuth2 是 Spring Security 基礎(chǔ)上的一個擴展，支持四種主要的 OAuth2 Flows，基本可以作為微服務(wù)認證授權(quán)中心的推薦產(chǎn)品。但是 Spring Security OAuth2 還只是一個框架，不是一個端到端的開箱即用的產(chǎn)品，企業(yè)級應(yīng)用仍需在其上進行定制，例如提供 Web 端管理界面，對接企業(yè)內(nèi)部的用戶認證登錄系統(tǒng)，使用 Cache 緩存令牌，和微服務(wù)網(wǎng)關(guān)對接等，才能作為生產(chǎn)級使用。在《2018 波波的微服務(wù)基礎(chǔ)架構(gòu)和實踐》課程中，第一個模塊就是微服務(wù)安全架構(gòu)和實踐相關(guān)主題，會深度剖析 OAuth2 原理和 Spring Security OAuth2 實踐，歡迎大家關(guān)注學習。
Spring Security OAuth2 是 Spring Security 框架的一個擴展。
服務(wù)框架 Spring/Boot
Spring 可以說是史上最成功的 Web App/API 開發(fā)框架之一，它融入了 Java 社區(qū)中多年來沉淀下來的最佳實踐，雖然有將近 15 年歷史，但目前的社區(qū)活躍度仍呈上升趨勢。Spring Boot 在 Spring 的基礎(chǔ)上進一步打包封裝，提供更貼心的 Starter 工程，自啟動能力，自動依賴管理，基于代碼的配置等特性進一步降低接入門檻。另外 Spring Boot 也提供 actuator 這樣的生產(chǎn)級監(jiān)控特性，支持 DevOps 研發(fā)模式，它是微服務(wù)開發(fā)框架的推薦首選。
REST 契約規(guī)范 Swagger 和 Spring 有比較好的集成，使得 Spring 也支持契約驅(qū)動開發(fā) (Contract Driven Development) 模型。對于一些中大規(guī)模的企業(yè)，如果業(yè)務(wù)復雜團隊較多，考慮到互操作性和集成成本，建議采用契約驅(qū)動開發(fā)模型，也就是開發(fā)時先定義 Swagger 契約，然后再通過契約生成服務(wù)端接口和客戶端，再實現(xiàn)服務(wù)端業(yè)務(wù)邏輯，這種開發(fā)模型能夠標準化接口，降低系統(tǒng)間集成成本，對于多團隊協(xié)同并行開發(fā)非常重要。
監(jiān)控反饋組件
數(shù)據(jù)總線 Kafka
最初由 Linkedin 研發(fā)并在其內(nèi)部大規(guī)模成功應(yīng)用，然后在 Apache 上開源的 Kafka，是業(yè)內(nèi)數(shù)據(jù)總線 (Databus) 一塊的標配，幾乎每一家互聯(lián)網(wǎng)公司都可以看到 Kafka 的身影。Kafka 堪稱開源項目的一個經(jīng)典成功案例，其創(chuàng)始人團隊從 Linkedin 離職后還專門成立了一家叫 confluent 的企業(yè)軟件服務(wù)公司，圍繞 Kafka 周邊提供配套和增值服務(wù)。在監(jiān)控一塊，日志和 Metrics 等數(shù)據(jù)可以通過 Kafka 做收集、存儲和轉(zhuǎn)發(fā)，相當于中間增加了一個大容量緩沖，能夠應(yīng)對海量日志數(shù)據(jù)的場景。除了日志監(jiān)控數(shù)據(jù)收集，Kafka 在業(yè)務(wù)大數(shù)據(jù)分析，IoT 等場景都有廣泛應(yīng)用。如果對 Kafka 進行適當定制增強，還可以用于傳統(tǒng)消息中間件場景。
Kafka 的特性是大容量，高吞吐，高可用，數(shù)據(jù)可重復消費，可水平擴展，支持消費者組等。Kafka 尤其適用于不嚴格要求實時和不丟數(shù)據(jù)的大數(shù)據(jù)日志場景。
Kafka 創(chuàng)始人三人組，離開 Linkedin 后，創(chuàng)立了基于 Kafka 的創(chuàng)業(yè)公司 Confluent。
日志監(jiān)控 ELK
<![endif]-->
ELK（ElasticSearch/Logstash/Kibana）是日志監(jiān)控一塊的標配技術(shù)棧，幾乎每一家互聯(lián)網(wǎng)公司都可以看到 ELK 的身影，據(jù)稱攜程是國內(nèi) ELK 的最大用戶，每日增量日志數(shù)據(jù)量達到 80~90TB。ELK 已經(jīng)非常成熟，基本上是開箱即用，后續(xù)主要的工作在運維、治理和調(diào)優(yōu)。
ELK 一般和 Kafka 配套使用，因為日志分詞操作還是比較耗時的，Kafka 主要作為前置緩沖，起到流量消峰作用，抵消日志流量高峰和消費（分詞建索引）的不匹配問題。一旦反向索引建立，日志檢索是非常快的，所以日志檢索快和靈活是 ElasticSearch 的最大亮點。另外 ELK 還有大容量，高吞吐，高可用，可水平擴容等企業(yè)級特性。
創(chuàng)業(yè)公司起步期，考慮到資源時間限制，調(diào)用鏈監(jiān)控和 Metrics 監(jiān)控可以不是第一優(yōu)先級，但是 ELK 是必須搭一套的，應(yīng)用日志數(shù)據(jù)一定要收集并建立索引，基本能夠覆蓋大部分 Trouble Shooting 場景（業(yè)務(wù)，性能，程序 bug 等）。
另外用好 ELK 的關(guān)鍵是治理，需要制定一些規(guī)則（比如只收集 Warn 級別以上日志），對應(yīng)用的日志數(shù)據(jù)量做好監(jiān)控，否則開發(fā)人員會濫用，什么垃圾數(shù)據(jù)都往 ELK 里頭丟，造成大量空間被浪費，嚴重的還可能造成性能可用性問題。
ELK + Kafka 參考部署架構(gòu)
調(diào)用鏈監(jiān)控 CAT
Spring Cloud 支持基于 Zipkin 的調(diào)用鏈監(jiān)控，我個人基于實踐經(jīng)驗認為 Zipkin 還不能算一款企業(yè)級調(diào)用鏈監(jiān)控產(chǎn)品，充其量只能算是一個半成品，很多重要的企業(yè)級特性缺失。Zipkin 最早是由 Twitter 在消化 Google Dapper 論文的基礎(chǔ)上研發(fā)，在 Twitter 內(nèi)部有較成功應(yīng)用，但是在開源出來的時候把不少重要的統(tǒng)計報表功能給閹割了（因為依賴于一些比較重的大數(shù)據(jù)分析平臺），只是開源了一個半成品，能簡單查詢和呈現(xiàn)可視化調(diào)用鏈，但是細粒度的調(diào)用性能數(shù)據(jù)報表沒有開源。
Google 大致在 2007 年左右開始研發(fā)稱為 Dapper 的調(diào)用鏈監(jiān)控系統(tǒng)，但在遠遠早于這個時間（大致在 2002 左右），eBay 就已經(jīng)有了自己的調(diào)用鏈監(jiān)控系統(tǒng) CAL（Centralized Application Logging），Google 和 eBay 的設(shè)計思路大致相同，但是也有一些差別。CAL 在 eBay 有大規(guī)模成功應(yīng)用，被稱為是 eBay 的四大神器之一（另外三個是 DAL，Messaging 和 SOA）。
開源調(diào)用鏈監(jiān)控系統(tǒng) CAT 的作者吳其敏（我曾經(jīng)和他同事，習慣叫他老吳），曾經(jīng)在 eBay 工作近十年，期間深入消化吸收了 CAL 的設(shè)計。2011 年后老吳離開 eBay 去了點評，用三年時間在點評再造了一款調(diào)用鏈監(jiān)控產(chǎn)品 CAT（Centralized Application Tracking），CAT 具有 CAL 的基因和影子，同時也融入了老吳在點評的探索實踐和創(chuàng)新。
CAT 是一款更完整的企業(yè)級調(diào)用鏈監(jiān)控產(chǎn)品，甚至已經(jīng)接近一個 APM（Application Performance Management）產(chǎn)品的范疇，它不僅支持調(diào)用鏈的查詢和可視化，還支持細粒度的調(diào)用性能數(shù)據(jù)統(tǒng)計報表，這塊是 CAT 和市面上其它開源調(diào)用鏈監(jiān)控產(chǎn)品最本質(zhì)的差異點，實際上開發(fā)人員大部分時間用 CAT 是看性能統(tǒng)計報表（主要是 CAT 的 Transaction 和 Problem 報表），這些報表相當于給了開發(fā)人員一把尺子，可以自助測量并持續(xù)改進應(yīng)用性能。另外 CAT 還支持應(yīng)用報錯大盤，自助告警等功能，也是企業(yè)級監(jiān)控非常實用的功能。
CAT 在點評，攜程，陸金所，拍拍貸等公司有成功落地案例，因為是國產(chǎn)調(diào)用鏈監(jiān)控產(chǎn)品，界面展示和功能等更契合國內(nèi)文化，更易于在國內(nèi)公司落地。個人推薦 CAT 作為微服務(wù)調(diào)用鏈監(jiān)控的首選。
至于社區(qū)里頭有人提到 CAT 的侵入性問題，我覺得是要一分為二看，有利有弊，有耦合性但是性能更好，一般企業(yè)中基礎(chǔ)架構(gòu)團隊會使用 CAT 統(tǒng)一為基礎(chǔ)組件埋點，開發(fā)人員一般不用自己埋點；另外企業(yè)用了一款調(diào)用鏈監(jiān)控產(chǎn)品以后，一般是不會換的，開發(fā)人員用習慣就好了，侵入不是大問題。
CAT 的 Transaction 報表
Metrics 監(jiān)控 KariosDB
除了日志和調(diào)用鏈，Metrics 也是應(yīng)用監(jiān)控的重要關(guān)注點。互聯(lián)網(wǎng)應(yīng)用提倡度量驅(qū)動開發(fā)（Metrics Driven Development），也就是說開發(fā)人員不僅要關(guān)注功能實現(xiàn)，做好單元測試（TDD），還要做好業(yè)務(wù)層（例如注冊，登錄和下單數(shù)等）和應(yīng)用層（例如調(diào)用數(shù)，調(diào)用延遲等）的監(jiān)控埋點，這個也是 DevOps（開發(fā)即運維）理念的體現(xiàn)，DevOps 要求開發(fā)人員必須關(guān)注運維需求，監(jiān)控埋點是一種生產(chǎn)級運維需求。
Metrics 監(jiān)控產(chǎn)品底層依賴于時間序列數(shù)據(jù)庫（TSDB），最近比較熱的開源產(chǎn)品有 Prometheus 和 InfluxDB，社區(qū)用戶數(shù)量和反饋都不錯，可以采納。但是這些產(chǎn)品分布式能力比較弱，定制擴展門檻比較高，一般建議剛起步量不大的公司采用。
如果企業(yè)業(yè)務(wù)和團隊規(guī)模發(fā)展到一定階段，建議考慮支持分布式能力的時間序列監(jiān)控產(chǎn)品，例如 KairosDB 或者 OpenTSDB，我本人對這兩款產(chǎn)品都有一些實踐經(jīng)驗，KariosDB 基于 Cassandra，相對更輕量一點，建議中大規(guī)模公司采用，如果你們公司已經(jīng)采用 Hadoop/HBase，則 OpenTSDB 也是不錯選擇。
KairosDB 一般也和 Kafka 配套使用，Kafka 作為前置緩沖。另外注意使用 KariosDB 打點的話 tag 的值不能太離散，否則會有查詢性能問題，這個和 KariosDB 底層存儲結(jié)構(gòu)有關(guān)系。Grafana 是 Metrics 展示標配，可以和 KariosDB 無縫集成。
Grafana 是 Metrics 展示標配，和主流時間序列數(shù)據(jù)庫都可以集成
健康檢查和告警 ZMon
除了上述監(jiān)控手段，我們?nèi)孕枰】禉z查和告警系統(tǒng)作為配套的監(jiān)控手段。ZMon 是德國電商公司 Zalando 開源的一款健康檢查和告警平臺，具備強大靈活的監(jiān)控告警能力。ZMon 本質(zhì)上可以認為是一套分布式監(jiān)控任務(wù)調(diào)度平臺，它提供眾多的 Check 腳本（也可以自己再定制擴展），能夠?qū)Ω鞣N硬件資源或者目標服務(wù)（例如 HTTP 端口，Spring 的 Actuator 端點，KariosDB 中的 Metrics，ELK 中的錯誤日志等等）進行定期的健康檢查和告警，它的告警邏輯和策略采用 Python 腳本實現(xiàn)，開發(fā)人員可以實現(xiàn)自助式告警。ZMon 同時適用于系統(tǒng)，應(yīng)用，業(yè)務(wù)，甚至端用戶體驗層的監(jiān)控和告警。
ZMon 分布式監(jiān)控告警系統(tǒng)架構(gòu)，底層基于 KairosDB 時間序列數(shù)據(jù)庫
限流熔斷和流聚合 Hystrix+Turbine
2010 年左右，Netflix 也飽受分布式微服務(wù)系統(tǒng)中雪崩效應(yīng)（Cascading Failure）的困擾，于是專門啟動了一個叫做彈性工程的項目來解決這個問題，Hystrix 就是彈性工程最終落地下來的一個產(chǎn)品。Hystrix 在 Netflix 微服務(wù)系統(tǒng)中大規(guī)模推廣應(yīng)用后，雪崩效應(yīng)問題基本得到解決，整個體統(tǒng)更具彈性。
之后 Netflix 把 Hystrix 開源貢獻給了社區(qū)，短期獲得社區(qū)的大量正面反饋，目前 Hystrix 在 github 上有超過 1.3 萬顆星，據(jù)說支持奧巴馬總統(tǒng)選舉的系統(tǒng)也曾使用 Hystrix 進行限流熔斷保護 [參考附錄 2]，可見限流熔斷是分布式系統(tǒng)穩(wěn)定性的強需求，Netflix 很好的抓住了這個需求并給出了經(jīng)過生產(chǎn)級驗證的解決方案。Hystrix 已經(jīng)被納入 Spring Cloud 體系，它是 Java 社區(qū)中限流熔斷組件的首選（目前還看不到第二個更好的產(chǎn)品）。
Turbine 是和 Hystrix 配套的一個流聚合服務(wù)，能夠?qū)?Hystrix 監(jiān)控數(shù)據(jù)流進行聚合，聚合以后可以在 Hystrix Dashboard 上看到集群的流量和性能情況。
Hystrix 在英文中是豪豬獸的意思，豪豬獸通過身上的刺保護自己，Netflix 為限流熔斷組件起名 Hystrix，寓意 Hystrix 能夠保護微服務(wù)調(diào)用。
往期推薦