摘要：可簡單地認為它是的擴展，負載均衡自然成為不可或缺的特性。是基于開發的服務代理組件，在使用場景中，它與和整合，打造具備服務動態更新和負載均衡能力的服務網關。類似的特性在項目也有體現，它是另一種高性能代理的方案，提供服務發現健康和負載均衡。

摘要： Cloud Native 應用架構隨著云技術的發展受到業界特別重視和關注，尤其是 CNCF（Cloud Native Computing Foundation）項目蓬勃發展之際。Dubbo 作為服務治理的標志性項目，自然緊跟業界的潮流，擁抱技術的變化。

Dubbo Cloud Native 實踐與思考

Cloud Native 應用架構隨著云技術的發展受到業界特別重視和關注，尤其是 CNCF（Cloud Native Computing Foundation）項目蓬勃發展之際。Dubbo 作為服務治理的標志性項目，自然緊跟業界的潮流，擁抱技術的變化。本次分享的議題包括介紹 Apache 孵化項目Dubbo Spring Boot Project 以及匯報 Dubbo 與 Cloud Native 整合過程中的一些實踐與思考，如適配 Spring Cloud 、服務發現、服務網關、服務跟蹤以及監控等。

注：為了讀者的閱讀方便和習慣，本文字稿將在演講內容的基礎上做出適當的調整。

自我介紹
馬昕曦（小馬哥），阿里巴巴中間件技術專家，十余年 Java EE 從業經驗，Dubbo 維護者、架構師以及微服務布道師。目前主要負責阿里巴巴集團微服務技術實施、架構衍進、基礎設施構建等。重點關注云計算、微服務以及軟件架構等領域。通過 SUN Java（SCJP、SCWCD、SCBCD）以及 Oracle OCA 等的認證。

主要議程
今天我非常榮幸地與大家一起討論關于 Dubbo Cloud Native 相關議題，本次議題緊扣“實踐與思考“兩個關鍵字，主要的議程包括：

Cloud Native 基礎設施
Cloud Native 架構選型
Dubbo Cloud Native 準備
Cloud Native 基礎設施
關于 Cloud Native 的定義，不同的云平臺可能給出的內容存在差異。此處，我向大家介紹目前最熱門的 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.

相對于其他學術流派，CNCF 的 Cloud Native 定義更為具體，偏向于軟件技術。這一點我們從文中的一些關鍵字能夠明顯地體會到，如關鍵字 "Containers（容器）"、"service meshes"、”microservices（微服務）“等。通常，開發人員較為關注的 Cloud Native 基礎設施為：“服務發現”、“負載均衡”、“服務網關”、“分布式配置”、“服務熔斷”以及“跟蹤監控”，如圖所示：

由于 PPT 格式的限制，此處我將“鏈路跟蹤”與“服務監控” 并陳為“跟蹤監控”。接下來，我們進入“服務發現”的討論。

服務發現（Service Discovery ）

隨著微服務架構（MSA）受到不同規模企業的青睞，服務治理的實施逐漸被提上基礎設施改造的議程。盡管這些概念在 SOA 時代已經提出，然而引起業界廣泛關注應歸功于微服務。服務發現（Service Discovery ）作為服務治理的核心特性，通常也將服務注冊（Service Registration）一并討論。無論是服務發現，還是服務注冊，在具體落地實施時，它們必須面對技術選型的問題。在座的各位，包括我，大多數是 Java 程序員，自然關心 Java 的技術方案。目前，Java 社區最為津津樂道的方案莫過于 Spring Cloud，搭配 Netflix OSS 組件 Eureka，幫助 Spring Boot 應用快速搭建服務發現體系。其中，Eureka Server 作為注冊中心服務器，Spring Boot 應用整合 Eureka Client 向 Eureka Server 注冊。實際上，Spring Cloud 除了整合 Netflix Eureka 作為服務發現之外，還提供了 Apache Zookeeper 和 HachiCorp Consul 的實現，所以這三種方案出現在當前頁面：

其中還包括 Redis 和 Apache Curator，前者是 Dubbo 的服務發現實現方案之一，然而小馬哥并不建議使用 Redis 作為注冊中心，還是保持它緩存中間件的單純性較好。而 Curator 作為 Zookeeper Java 客戶端類庫，它不但可用在 Dubbo，而且其擴展項目 Curator Service Discovery 也是 Spring Cloud 整合 Zookeeper 作為服務發現的關鍵基礎設施。或許大家思考以上方案應該如何選型的問題。

如何選擇
Eureka
當服務發現選型時，Netflix Eureka 或許是在開發人員腦海中復現的首選方案。然而 Eureka 在阿里大規模實踐時，它的表現并不理想，當 Eureka 客戶端服務實例數量達到一定時，Eureka Server 時常會出現服務不可用的情況，主要的問題集中在更新（Update）機制、復制（Replication）機制以及內存型存儲。由于時間的關系，此處我不加詳細說明，部分答案在 Eureka Wiki Eureka 2.0 Motivations 中也有描述：

Why Eureka 2.0?

Only support homogenous client views
Only supports scheduled updates
Replication algorithm limits scalability
注：以上具體內容在分享現場并沒有具體提及，此處特意為讀者補充。

以上問題 Netflix 早在 2015 年已意識到，然而 Eureka 2.0 的發布遙遙無期。后來，我托朋友聯系上了 Netflix 的工程師，咨詢他們關于 Eureka 1 在自身生產環境的使用情況。他們的回復是部分場景在使用。這樣的答復值得玩味，再細問其覆蓋比重，對方三緘其口。這不得不讓我對 Eureka 的成熟度產生了質疑，所以我不建議大家在數以千計的應用實例場景中使用。

Consul
Consul 同樣作為 Spring Cloud 服務中心，基于 GO 語言開發，其數據一致性采用 Raft 算法，低內存，集群支持。曾一度成為我理想的替換 Eureka 的方案，不過本人并不具備 Consul 的大規模運用，為此還特意請教永輝云創的架構師翟永超（《Spring Cloud 微服務實戰》的作者）。他告知 Consul 表現不錯，并在跨 DC（數據中心）方面也比較穩定：

他的答復讓我增強了 Consul 的信心，稍顯遺憾的是其 Consul 應用節點略少。后來，我聽說 B 站的哥們自研服務發現中間件 discovery，他們應該也對 Consul 做過調研和評估，他們的看法是：

Github 開源地址：https://github.com/Bilibili/d...

discovery 在 B 站 K8S 上的使用情況：

綜合兩家公司的評估，盡管沒有經過本人實際操作，并且兩者沒有提供具體的數據指標，然而在一定程度上說明 Consul 作為注冊中心的實例節點規模大概在 2k 以內。換言之，它比較適合中小型企業。

Zookeeper
Zookeeper 即可是 Spring Cloud 注冊中心，又能作為 Dubbo 注冊中心，與 Eureka 不同，它屬于 CP 分布式策略，而后者屬于 AP。兩者的共同點在于均屬于內存型注冊中心，在大規模集群場景，也會遇到 Eureka 類似的問題。不過從運維的角度，相較于 Eureka 而言，熟悉 Zookeeper 運維朋友更多。在生態性方面，Zookeeper 周邊的生態更豐富，如 Zookeeper C API，盡管 Eureka 提供了語言無關性的 REST 接口。同時，Zookeeper 還從當配置服務器的角色，降低了學習的成本。綜上結論，我推薦使用 Zookeeper 作為服務發現基礎設施，無論您選擇 Dubbo 方案，還是使用 Spring Cloud。盡管它在大規模集群時也出現 Zookeeper 間歇性卡頓等問題。

負載均衡

負載均衡是第二個重要 Cloud Native 基礎設施，熟悉 Spring Cloud 的朋友一定對右側的蝴蝶結有印象，它就是 Netflix OSS 負載均衡組件 Ribbon，框架層面提供了多種負載均衡規則，如：

隨機 - RandomRule
輪循 - RoundRobinRule
權重響應時間 - WeightedResponseTimeRule
WeightedResponseTimeRule 之外，其他的 Ribbon 負載均衡實現均沒有提供權重因子，而權重因子對于藍綠發布、服務預熱等方面的幫助是至關重要的。因此，權重因子在 Dubbo “隨機“、”輪詢“ 以及 ”最少活躍調用數“ 負載均衡算法中均體現。

以上討論的兩種框架均屬于 Java 實現，而中間的 Kong 則是更為通用的實現，通常它作為 API 服務網關，后面我們將繼續討論。可簡單地認為它是 Nginx + Lua 的擴展，負載均衡自然成為不可或缺的特性。其默認的負載均衡算法為具備權重的輪詢（weighted-round-robin），同時一致性 Hash 算法作為可選方案。

服務網關

談及服務網關，Java 工程師最容易想到的是 Spring Cloud Zuul。Zuul 是 Netflix 基于 Servlet API 開發的 Web 服務代理組件，在 Spring Cloud 使用場景中，它與 Eureka 和 Ribbon 整合，打造具備服務動態更新和負載均衡能力的服務網關。

最近，隨著 Spring Cloud Finchley 的發布，Spring Cloud Zuul 的替代方案 Spring Cloud Gateway 孕育而生，不過官方的描述還是比較謙虛謹慎，并沒有一刀切地引導開發人員從 Zuul 遷移到 Gateway 上來：

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.

兩者不同點在于，Zuul 運行在 Servlet 容器中，而 Gateway 并不像 Spring WebFlux 能夠兼容 Servlet 3.1 運行時，而是必須依賴 Netty 的運行時，以及整合 Reactive 框架 Reactor，實現異步非阻塞網關。由于近期對于 Spring 5 WebFlux 能夠大幅提升應用性能的觀點甚囂塵上，實際上，沒有任何直接性能基準測試證明 WebFlux 能夠加快程序執行速度，或許大家認為我的觀點與主流格格不入，可是我要告訴大家的是，這個問題我在同事間驗證過很多次，大多數情況，Reactive 并不沒有提升性能。就連 Spring 官方也承認這個觀點：

1.1.7. Performance vs scale

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 the WebClient to 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.

資源地址：https://docs.spring.io/spring...

同時，這里提供一篇 Spring 5 WebFlux: Performance tests 的文章，在結尾部分給出了結論，作者坦言在速度上沒有明顯的提升，甚至從結果來看，速度稍微更糟糕：

No improvement in speed was observed with our reactive apps (the Gatling results are even slightly worse).
以上測試工程和結論是由開源項目 JHipster 的工程師給出，具備一定的客觀性和可信度。

資源地址：https://blog.ippon.tech/sprin...

換言之，基于 Reactor 開發的 Gateway 在性能可能并沒有明顯的提升。因此，Zuul 和 Gateway 的性能對比則演變為 Servlet 容器和 Netty Web 容器的比較，感興趣的朋友可以去網上尋找一些比較數據，兩者的性能在伯仲間。

當然，我和在座的各位一樣，對 Java 的實現方案自然是情有獨鐘。然而我想說的是，身為 Java 工程師，眼中難免有 Java，但是眼中不要只有 Java。Nginx 作為當年著名 “C10K” 問題的解決方案，無論從連接數量，還是資源消耗方面均優于 Java 實現。作為技術人，應該具有更為寬廣的胸懷，接納非我族類的氣魄，該放手的時候就放手。Nginx 作為服務網關不失為一種好的方案，然而它的動態性略為不足，需要結合 Lua 腳本輔助完成，因此，OpenResty 和 Kong 這類方案脫穎而出。如果就 HTTP API 網關而言，個人認為 Kong 的方案更佳，因為它提供完整的解決方案，包括前面討論的負載均衡（權重）、服務熔斷以及服務發現等特性。類似的特性在 CNCF 項目 Envoy 也有體現，它是另一種高性能代理的方案，提供服務發現、健康和負載均衡。在協議上，天然支持 HTTP 和 HTTP/2，而通訊協議支持 gRPC，建議大家予以高度關注。

值得一提的是，HTTP API 網關通常需要支持 sidecar，換言之，支撐網關服務的基礎設施必須提供服務發現的能力，就功能性而言，Zuul 和 Gateway 自身并不具備這樣的特性，需要搭配 Eureka 這樣組件，它們更像服務路由器的角色。

分布式配置

左邊和中間的四種技術均為 Spring Cloud 分布式配置的底層存儲，其中 Git 為版本式配置，而 JDBC 是從 Spring Cloud Edgware 版本開始支持，提供更為通用和動態的配置源。這里我們又見到 Zookeeper 的聲影，從簡化運維的角度，可以利用 Zookeeper 即承擔服務發現，也作為分布式配置的基礎設施。而最右邊的 etcd 是最近非常火的 Kubernetes 分布式配置的 key-value 存儲，提供快速、簡單、安全和可高的解決方案。

服務熔斷

服務熔斷也非常讓開發人員聯想到 Spring Cloud Hystrix 技術，不過 Hystrix 并非與 Spring Cloud 強耦合，當然 Dubbo 也能結合 Netflix Hystrix 框架提供服務熔斷的能力，后面部分將介紹 Dubbo 與 Hystrix 整合，提升 Dubbo 服務熔斷的能力。確切地說，Dubbo 所提供的能力是集群容錯，包括 Failover 等模式。 Kong 也天然地支持服務熔斷的能力，所以它作為 API 網關的特性是全面的。

鏈路跟蹤

以上鏈路跟蹤的基礎設施從左至右，分別為 Zipkin、OpenTracing 以及 Jaeger，三者的靈感均來自于 Google 論文 Dapper。相對而言，Java 程序員可能更為熟悉 Zipkin，因為它是 Spring Cloud Sleuth 首選方案，提供客戶端上報以及服務端聚合和 Dashboard 等功能。而 OpenTracing 和 Jaeger 是 CNCF 孵化項目，前者屬于開放的標準，提供多語言的適配實現，后者則由 Uber（優步）公司開發并開源的鏈路跟蹤項目，功能上與 Zipkin 類似，不過它基于 GO 語言開發，同時也提供 Java 客戶端。

OpenTracing 官網：http://opentracing.io/
jaeger 官網：https://www.jaegertracing.io/

服務監控

服務監控與鏈路跟蹤有所區別，主要用于監控應用系統或業務的指標數據，可能是健康閾值，如 CPU 或 內存使用率，也可以是業務指標，如最近一小時的用戶登錄量。通常采用 Metrics 方式暴露，可使用客戶端推送或服務端拉取的方式傳輸 Metrics 信息到數據中心。通常 Metrics 數據與時間是存在對應關系，因此，基本上采用時序型數據庫來存儲，如圖中的 OpenTSDB。通常，Java 微服務應用會選擇 Spring Boot 框架作為基礎設施，如我之前設計的監控架構就采用了 Spring Boot + OpenTSDB ，后端存儲基于 HBase。當時 Spring Boot Actuator Metrics 僅為簡單的 Key Value 形式，自然 OpenTSDB 是理想的選擇。隨著 Spring Boot 2.0 開始支持 Micrometer 之后，使得 Spring Boot 的應用能夠整合更多的 Micrometer 適配方案，其中名氣較大的就是圖中間的 Prometheus，它同樣也是 CNCF 的孵化項目。

當然服務監控不只是 Metrics 方式，我所知道國內不少的公司采用了日志收集的方案，并搭配 ELK（Elasticsearch, Logstash, Kibana） 架構，減少運維成本。假設您沒有使用該方案，或者僅使用了 Elasticsearch 的話，無論哪種方案，圖形化界面的監控是必不可少的，因此我推薦 Grafana，該項目能夠支持多種數據源，包括前文提到的 OpenTSDB、Prometheus 以及 ElasticSearch 等。由此，從數據采集、上報、聚合以及展示的特性上，這些基礎設施幫助 Cloud Native 應用構建服務監控的閉環。

本議程介紹了一些 Cloud Native 技術設施，接下里我們繼續討論 Cloud Native 架構選型。

Cloud Native 架構選型
CNCF 架構體系

CNCF 體系作為目前最熱門的架構選型之一，基本上圍繞著 Kubernetes 為中心而構建。個人認為，Java 業界和 CNCF 體系并沒有達成共識，如服務網關，CNCF 主打 Envoy，而 Java 主要的方案為 Zuul 和 Spring Cloud Gateway。因此，個人建議是密切的關注 CNCF 的發展，不過個別孵化項目可以先行，如 Prometheus 和 Jaeger 等。 至于 CNCF 與 Java 生態的整合和落地，還得有待時日。

原文鏈接