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