摘要：Cloud Native 應(yīng)用架構(gòu)隨著云技術(shù)的發(fā)展受到業(yè)界特別重視和關(guān)注，尤其是 CNCF（Cloud Native Computing Foundation）項(xiàng)目蓬勃發(fā)展之際。Dubbo 作為服務(wù)治理的標(biāo)志性項(xiàng)目，自然緊跟業(yè)界的潮流，擁抱技術(shù)的變化。
Dubbo Cloud Native 實(shí)踐與思考
分享簡(jiǎn)介
Cloud Native 應(yīng)用架構(gòu)隨著云技術(shù)的發(fā)展受到業(yè)界特別重視和關(guān)注，尤其是 CNCF（Cloud Native Computing Foundation）項(xiàng)目蓬勃發(fā)展之際。Dubbo 作為服務(wù)治理的標(biāo)志性項(xiàng)目，自然緊跟業(yè)界的潮流，擁抱技術(shù)的變化。本次分享的議題包括介紹 Apache 孵化項(xiàng)目Dubbo Spring Boot Project 以及匯報(bào) Dubbo 與 Cloud Native 整合過(guò)程中的一些實(shí)踐與思考，如適配 Spring Cloud 、服務(wù)發(fā)現(xiàn)、服務(wù)網(wǎng)關(guān)、服務(wù)跟蹤以及監(jiān)控等。
注：為了讀者的閱讀方便和習(xí)慣，本文字稿將在演講內(nèi)容的基礎(chǔ)上做出適當(dāng)?shù)恼{(diào)整。
自我介紹
馬昕曦（小馬哥），阿里巴巴中間件技術(shù)專家，十余年 Java EE 從業(yè)經(jīng)驗(yàn)，Dubbo 維護(hù)者、架構(gòu)師以及微服務(wù)布道師。目前主要負(fù)責(zé)阿里巴巴集團(tuán)微服務(wù)技術(shù)實(shí)施、架構(gòu)衍進(jìn)、基礎(chǔ)設(shè)施構(gòu)建等。重點(diǎn)關(guān)注云計(jì)算、微服務(wù)以及軟件架構(gòu)等領(lǐng)域。通過(guò) SUN Java（SCJP、SCWCD、SCBCD）以及 Oracle OCA 等的認(rèn)證。
主要議程
今天我非常榮幸地與大家一起討論關(guān)于 Dubbo Cloud Native 相關(guān)議題，本次議題緊扣“實(shí)踐與思考“兩個(gè)關(guān)鍵字，主要的議程包括：
Cloud Native 基礎(chǔ)設(shè)施
Cloud Native 架構(gòu)選型
Dubbo Cloud Native 準(zhǔn)備
Cloud Native 基礎(chǔ)設(shè)施
關(guān)于 Cloud Native 的定義，不同的云平臺(tái)可能給出的內(nèi)容存在差異。此處，我向大家介紹目前最熱門的 CNCF 的定義：
”CNCF Cloud Native Definition v1.0“ 中的描述：
Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.
相對(duì)于其他學(xué)術(shù)流派，CNCF 的 Cloud Native 定義更為具體，偏向于軟件技術(shù)。這一點(diǎn)我們從文中的一些關(guān)鍵字能夠明顯地體會(huì)到，如關(guān)鍵字 "Containers（容器）"、"service meshes"、”microservices（微服務(wù)）“等。通常，開發(fā)人員較為關(guān)注的 Cloud Native 基礎(chǔ)設(shè)施為：“服務(wù)發(fā)現(xiàn)”、“負(fù)載均衡”、“服務(wù)網(wǎng)關(guān)”、“分布式配置”、“服務(wù)熔斷”以及“跟蹤監(jiān)控”，如圖所示：
由于 PPT 格式的限制，此處我將“鏈路跟蹤”與“服務(wù)監(jiān)控” 并陳為“跟蹤監(jiān)控”。接下來(lái)，我們進(jìn)入“服務(wù)發(fā)現(xiàn)”的討論。
服務(wù)發(fā)現(xiàn)（Service Discovery ）
隨著微服務(wù)架構(gòu)（MSA）受到不同規(guī)模企業(yè)的青睞，服務(wù)治理的實(shí)施逐漸被提上基礎(chǔ)設(shè)施改造的議程。盡管這些概念在 SOA 時(shí)代已經(jīng)提出，然而引起業(yè)界廣泛關(guān)注應(yīng)歸功于微服務(wù)。服務(wù)發(fā)現(xiàn)（Service Discovery ）作為服務(wù)治理的核心特性，通常也將服務(wù)注冊(cè)（Service Registration）一并討論。無(wú)論是服務(wù)發(fā)現(xiàn)，還是服務(wù)注冊(cè)，在具體落地實(shí)施時(shí)，它們必須面對(duì)技術(shù)選型的問(wèn)題。在座的各位，包括我，大多數(shù)是 Java 程序員，自然關(guān)心 Java 的技術(shù)方案。目前，Java 社區(qū)最為津津樂(lè)道的方案莫過(guò)于 Spring Cloud，搭配 Netflix OSS 組件 Eureka，幫助 Spring Boot 應(yīng)用快速搭建服務(wù)發(fā)現(xiàn)體系。其中，Eureka Server 作為注冊(cè)中心服務(wù)器，Spring Boot 應(yīng)用整合 Eureka Client 向 Eureka Server 注冊(cè)。實(shí)際上，Spring Cloud 除了整合 Netflix Eureka 作為服務(wù)發(fā)現(xiàn)之外，還提供了 Apache Zookeeper 和 HachiCorp Consul 的實(shí)現(xiàn)，所以這三種方案出現(xiàn)在當(dāng)前頁(yè)面：
其中還包括 Redis 和 Apache Curator，前者是 Dubbo 的服務(wù)發(fā)現(xiàn)實(shí)現(xiàn)方案之一，然而小馬哥并不建議使用 Redis 作為注冊(cè)中心，還是保持它緩存中間件的單純性較好。而 Curator 作為 Zookeeper Java 客戶端類庫(kù)，它不但可用在 Dubbo，而且其擴(kuò)展項(xiàng)目 Curator Service Discovery 也是 Spring Cloud 整合 Zookeeper 作為服務(wù)發(fā)現(xiàn)的關(guān)鍵基礎(chǔ)設(shè)施。或許大家思考以上方案應(yīng)該如何選型的問(wèn)題。
如何選擇
Eureka
當(dāng)服務(wù)發(fā)現(xiàn)選型時(shí)，Netflix Eureka 或許是在開發(fā)人員腦海中復(fù)現(xiàn)的首選方案。然而 Eureka 在阿里大規(guī)模實(shí)踐時(shí)，它的表現(xiàn)并不理想，當(dāng) Eureka 客戶端服務(wù)實(shí)例數(shù)量達(dá)到一定時(shí)，Eureka Server 時(shí)常會(huì)出現(xiàn)服務(wù)不可用的情況，主要的問(wèn)題集中在更新（Update）機(jī)制、復(fù)制（Replication）機(jī)制以及內(nèi)存型存儲(chǔ)。由于時(shí)間的關(guān)系，此處我不加詳細(xì)說(shuō)明，部分答案在 Eureka WikiEureka 2.0 Motivations中也有描述：
Only support homogenous client views
Only supports scheduled updates
Replication algorithm limits scalability
注：以上具體內(nèi)容在分享現(xiàn)場(chǎng)并沒(méi)有具體提及，此處特意為讀者補(bǔ)充。
以上問(wèn)題 Netflix 早在 2015 年已意識(shí)到，然而 Eureka 2.0 的發(fā)布遙遙無(wú)期。后來(lái)，我托朋友聯(lián)系上了 Netflix 的工程師，咨詢他們關(guān)于 Eureka 1 在自身生產(chǎn)環(huán)境的使用情況。他們的回復(fù)是部分場(chǎng)景在使用。這樣的答復(fù)值得玩味，再細(xì)問(wèn)其覆蓋比重，對(duì)方三緘其口。這不得不讓我對(duì) Eureka 的成熟度產(chǎn)生了質(zhì)疑，所以我不建議大家在數(shù)以千計(jì)的應(yīng)用實(shí)例場(chǎng)景中使用。
Consul
Consul 同樣作為 Spring Cloud 服務(wù)中心，基于 GO 語(yǔ)言開發(fā)，其數(shù)據(jù)一致性采用 Raft 算法，低內(nèi)存，集群支持。曾一度成為我理想的替換 Eureka 的方案，不過(guò)本人并不具備 Consul 的大規(guī)模運(yùn)用，為此還特意請(qǐng)教永輝云創(chuàng)的架構(gòu)師翟永超（《Spring Cloud 微服務(wù)實(shí)戰(zhàn)》的作者）。他告知 Consul 表現(xiàn)不錯(cuò)，并在跨 DC（數(shù)據(jù)中心）方面也比較穩(wěn)定：
他的答復(fù)讓我增強(qiáng)了 Consul 的信心，稍顯遺憾的是其 Consul 應(yīng)用節(jié)點(diǎn)略少。后來(lái)，我聽說(shuō) B 站的哥們自研服務(wù)發(fā)現(xiàn)中間件discovery，他們應(yīng)該也對(duì) Consul 做過(guò)調(diào)研和評(píng)估，他們的看法是：
Github 開源地址：https://github.com/Bilibili/discovery/
discovery在 B 站 K8S 上的使用情況：
綜合兩家公司的評(píng)估，盡管沒(méi)有經(jīng)過(guò)本人實(shí)際操作，并且兩者沒(méi)有提供具體的數(shù)據(jù)指標(biāo)，然而在一定程度上說(shuō)明 Consul 作為注冊(cè)中心的實(shí)例節(jié)點(diǎn)規(guī)模大概在 2k 以內(nèi)。換言之，它比較適合中小型企業(yè)。
Zookeeper
Zookeeper 即可是 Spring Cloud 注冊(cè)中心，又能作為 Dubbo 注冊(cè)中心，與 Eureka 不同，它屬于 CP 分布式策略，而后者屬于 AP。兩者的共同點(diǎn)在于均屬于內(nèi)存型注冊(cè)中心，在大規(guī)模集群場(chǎng)景，也會(huì)遇到 Eureka 類似的問(wèn)題。不過(guò)從運(yùn)維的角度，相較于 Eureka 而言，熟悉 Zookeeper 運(yùn)維朋友更多。在生態(tài)性方面，Zookeeper 周邊的生態(tài)更豐富，如 Zookeeper C API，盡管 Eureka 提供了語(yǔ)言無(wú)關(guān)性的 REST 接口。同時(shí)，Zookeeper 還從當(dāng)配置服務(wù)器的角色，降低了學(xué)習(xí)的成本。綜上結(jié)論，我推薦使用 Zookeeper 作為服務(wù)發(fā)現(xiàn)基礎(chǔ)設(shè)施，無(wú)論您選擇 Dubbo 方案，還是使用 Spring Cloud。盡管它在大規(guī)模集群時(shí)也出現(xiàn) Zookeeper 間歇性卡頓等問(wèn)題。
負(fù)載均衡
負(fù)載均衡是第二個(gè)重要 Cloud Native 基礎(chǔ)設(shè)施，熟悉 Spring Cloud 的朋友一定對(duì)右側(cè)的蝴蝶結(jié)有印象，它就是 Netflix OSS 負(fù)載均衡組件 Ribbon，框架層面提供了多種負(fù)載均衡規(guī)則，如：
隨機(jī)-RandomRule
輪循-RoundRobinRule
權(quán)重響應(yīng)時(shí)間-WeightedResponseTimeRule
WeightedResponseTimeRule之外，其他的 Ribbon 負(fù)載均衡實(shí)現(xiàn)均沒(méi)有提供權(quán)重因子，而權(quán)重因子對(duì)于藍(lán)綠發(fā)布、服務(wù)預(yù)熱等方面的幫助是至關(guān)重要的。因此，權(quán)重因子在 Dubbo “隨機(jī)“、”輪詢“ 以及 ”最少活躍調(diào)用數(shù)“ 負(fù)載均衡算法中均體現(xiàn)。
以上討論的兩種框架均屬于 Java 實(shí)現(xiàn)，而中間的 Kong 則是更為通用的實(shí)現(xiàn)，通常它作為 API 服務(wù)網(wǎng)關(guān)，后面我們將繼續(xù)討論?？珊?jiǎn)單地認(rèn)為它是 Nginx + Lua 的擴(kuò)展，負(fù)載均衡自然成為不可或缺的特性。其默認(rèn)的負(fù)載均衡算法為具備權(quán)重的輪詢（weighted-round-robin），同時(shí)一致性 Hash 算法作為可選方案。
服務(wù)網(wǎng)關(guān)
談及服務(wù)網(wǎng)關(guān)，Java 工程師最容易想到的是 Spring Cloud Zuul。Zuul 是 Netflix 基于 Servlet API 開發(fā)的 Web 服務(wù)代理組件，在 Spring Cloud 使用場(chǎng)景中，它與 Eureka 和 Ribbon 整合，打造具備服務(wù)動(dòng)態(tài)更新和負(fù)載均衡能力的服務(wù)網(wǎng)關(guān)。
最近，隨著 Spring Cloud Finchley 的發(fā)布，Spring Cloud Zuul 的替代方案 Spring Cloud Gateway 孕育而生，不過(guò)官方的描述還是比較謙虛謹(jǐn)慎，并沒(méi)有一刀切地引導(dǎo)開發(fā)人員從 Zuul 遷移到 Gateway 上來(lái)：
API Gateway built on top of the Spring Ecosystem, including: Spring 5, Spring Boot 2 and Project Reactor. Spring Cloud Gateway aims to provide a simple, yet effective way to route to APIs and provide cross cutting concerns to them such as: security, monitoring/metrics, and resiliency.
兩者不同點(diǎn)在于，Zuul 運(yùn)行在 Servlet 容器中，而 Gateway 并不像 Spring WebFlux 能夠兼容 Servlet 3.1 運(yùn)行時(shí)，而是必須依賴 Netty 的運(yùn)行時(shí)，以及整合 Reactive 框架 Reactor，實(shí)現(xiàn)異步非阻塞網(wǎng)關(guān)。由于近期對(duì)于 Spring 5 WebFlux 能夠大幅提升應(yīng)用性能的觀點(diǎn)甚囂塵上，實(shí)際上，沒(méi)有任何直接性能基準(zhǔn)測(cè)試證明 WebFlux 能夠加快程序執(zhí)行速度，或許大家認(rèn)為我的觀點(diǎn)與主流格格不入，可是我要告訴大家的是，這個(gè)問(wèn)題我在同事間驗(yàn)證過(guò)很多次，大多數(shù)情況，Reactive 并不沒(méi)有提升性能。就連 Spring 官方也承認(rèn)這個(gè)觀點(diǎn)：
Performance has many characteristics and meanings.Reactive and non-blocking generally do not make applications run faster. They can, in some cases, for example if using theWebClientto execute remote calls in parallel.On the whole it requires more work to do things the non-blocking way and that can increase slightly the required processing time.
同時(shí)，這里提供一篇Spring 5 WebFlux: Performance tests的文章，在結(jié)尾部分給出了結(jié)論，作者坦言在速度上沒(méi)有明顯的提升，甚至從結(jié)果來(lái)看，速度稍微更糟糕：
No improvement in speed was observed with our reactive apps (the Gatling results are even slightly worse).
以上測(cè)試工程和結(jié)論是由開源項(xiàng)目 JHipster 的工程師給出，具備一定的客觀性和可信度。
資源地址：https://blog.ippon.tech/spring-5-webflux-performance-tests/
換言之，基于 Reactor 開發(fā)的 Gateway 在性能可能并沒(méi)有明顯的提升。因此，Zuul 和 Gateway 的性能對(duì)比則演變?yōu)?Servlet 容器和 Netty Web 容器的比較，感興趣的朋友可以去網(wǎng)上尋找一些比較數(shù)據(jù)，兩者的性能在伯仲間。
當(dāng)然，我和在座的各位一樣，對(duì) Java 的實(shí)現(xiàn)方案自然是情有獨(dú)鐘。然而我想說(shuō)的是，身為 Java 工程師，眼中難免有 Java，但是眼中不要只有 Java。Nginx 作為當(dāng)年著名 “C10K” 問(wèn)題的解決方案，無(wú)論從連接數(shù)量，還是資源消耗方面均優(yōu)于 Java 實(shí)現(xiàn)。作為技術(shù)人，應(yīng)該具有更為寬廣的胸懷，接納非我族類的氣魄，該放手的時(shí)候就放手。Nginx 作為服務(wù)網(wǎng)關(guān)不失為一種好的方案，然而它的動(dòng)態(tài)性略為不足，需要結(jié)合 Lua 腳本輔助完成，因此，OpenResty 和 Kong 這類方案脫穎而出。如果就 HTTP API 網(wǎng)關(guān)而言，個(gè)人認(rèn)為 Kong 的方案更佳，因?yàn)樗峁┩暾慕鉀Q方案，包括前面討論的負(fù)載均衡（權(quán)重）、服務(wù)熔斷以及服務(wù)發(fā)現(xiàn)等特性。類似的特性在 CNCF 項(xiàng)目 Envoy 也有體現(xiàn)，它是另一種高性能代理的方案，提供服務(wù)發(fā)現(xiàn)、健康和負(fù)載均衡。在協(xié)議上，天然支持 HTTP 和 HTTP/2，而通訊協(xié)議支持 gRPC，建議大家予以高度關(guān)注。
值得一提的是，HTTP API 網(wǎng)關(guān)通常需要支持 sidecar，換言之，支撐網(wǎng)關(guān)服務(wù)的基礎(chǔ)設(shè)施必須提供服務(wù)發(fā)現(xiàn)的能力，就功能性而言，Zuul 和 Gateway 自身并不具備這樣的特性，需要搭配 Eureka 這樣組件，它們更像服務(wù)路由器的角色。
分布式配置
左邊和中間的四種技術(shù)均為 Spring Cloud 分布式配置的底層存儲(chǔ)，其中 Git 為版本式配置，而 JDBC 是從 Spring Cloud Edgware 版本開始支持，提供更為通用和動(dòng)態(tài)的配置源。這里我們又見到 Zookeeper 的聲影，從簡(jiǎn)化運(yùn)維的角度，可以利用 Zookeeper 即承擔(dān)服務(wù)發(fā)現(xiàn)，也作為分布式配置的基礎(chǔ)設(shè)施。而最右邊的 etcd 是最近非?；鸬?Kubernetes 分布式配置的 key-value 存儲(chǔ)，提供快速、簡(jiǎn)單、安全和可高的解決方案。
服務(wù)熔斷
服務(wù)熔斷也非常讓開發(fā)人員聯(lián)想到 Spring Cloud Hystrix 技術(shù)，不過(guò) Hystrix 并非與 Spring Cloud 強(qiáng)耦合，當(dāng)然 Dubbo 也能結(jié)合 Netflix Hystrix 框架提供服務(wù)熔斷的能力，后面部分將介紹 Dubbo 與 Hystrix 整合，提升 Dubbo 服務(wù)熔斷的能力。確切地說(shuō)，Dubbo 所提供的能力是集群容錯(cuò)，包括 Failover 等模式。 Kong 也天然地支持服務(wù)熔斷的能力，所以它作為 API 網(wǎng)關(guān)的特性是全面的。
鏈路跟蹤
以上鏈路跟蹤的基礎(chǔ)設(shè)施從左至右，分別為 Zipkin、OpenTracing 以及 Jaeger，三者的靈感均來(lái)自于Google 論文 Dapper。相對(duì)而言，Java 程序員可能更為熟悉 Zipkin，因?yàn)樗?Spring Cloud Sleuth 首選方案，提供客戶端上報(bào)以及服務(wù)端聚合和 Dashboard 等功能。而 OpenTracing 和 Jaeger 是 CNCF 孵化項(xiàng)目，前者屬于開放的標(biāo)準(zhǔn)，提供多語(yǔ)言的適配實(shí)現(xiàn)，后者則由 Uber（優(yōu)步）公司開發(fā)并開源的鏈路跟蹤項(xiàng)目，功能上與 Zipkin 類似，不過(guò)它基于 GO 語(yǔ)言開發(fā)，同時(shí)也提供 Java 客戶端。
