Dubbo云原生之路：Dubbo3.0Roadmap發(fā)布4Dubbo3.0前瞻之：應(yīng)用級服務(wù)發(fā)現(xiàn)14Dubbo3.0前瞻之：重構(gòu)SpringCloud服務(wù)治理31Dubbo3.0前瞻之：常用協(xié)議對比及RPC協(xié)議新形態(tài)探索45Dubbo3.0前瞻之：應(yīng)用級服務(wù)發(fā)現(xiàn)輕松支持百萬集群，帶來真正可伸縮微服務(wù)架構(gòu)512020雙11，Dubbo3.0在考拉的超大規(guī)模實(shí)踐61Dubbo版Swagger來啦！Dubbo-Api-Docs發(fā)布！67Dubbo3.0前瞻之:對接Kubernetes原生服務(wù)78Dubbo云原生之路：Dubbo3.0Roadmap發(fā)布<4Dubbo云原生之路：Dubbo3.0Roadmap發(fā)布作者：劉軍，花名陸龜，Github賬號Chickenlj，ApacheDubboPMC，項(xiàng)目核心開發(fā)，見證了Dubbo重啟開源，到從Apache基金會畢業(yè)的整個(gè)過程?，F(xiàn)任職阿里云云原生應(yīng)用平臺團(tuán)隊(duì)，參與服務(wù)框架、微服務(wù)相關(guān)工作，目前主要在推動Dubbo3.0-Dubbo云原生?？v觀中國開源歷史，你真的沒法找到第二個(gè)像Dubbo一樣自帶爭議和討論熱度的開源項(xiàng)目。一方面，2011年，它的開源填補(bǔ)了當(dāng)時(shí)生產(chǎn)環(huán)境使用的RPC框架的空白，一發(fā)布就被廣泛采用；另一方面，它經(jīng)歷了停止維護(hù)、重啟維護(hù)后捐獻(xiàn)給Apache基金會、接著又以頂級項(xiàng)目的身份畢業(yè)。即便阿里努力對外展示開源投入的決心，在云原生時(shí)代，Dubbo的路將怎么走下去？它如何延續(xù)當(dāng)前光芒？今年是Dubbo從Apache基金會畢業(yè)的一周年，同時(shí)也是推進(jìn)Dubbo3.0，即全面擁抱云原生的重要一年。我們很高興地了解到，Dubbo3.0Preview版將在2021年3月下旬發(fā)布。Dubbo與開源中國共同策劃【Dubbo云原生之路】系列文章，和大家一起回顧ApacheDubbo社區(qū)的發(fā)展。在這里，我們也向所有的Dubbo用戶和開發(fā)者發(fā)出投稿邀請，如果你正在使用Dubbo，或是正在為Dubbo貢獻(xiàn)力量，歡迎和我們分享你的開發(fā)使用經(jīng)驗(yàn)，優(yōu)質(zhì)文章也會收錄進(jìn)【Dubbo云原生之路】系列。本篇作為整個(gè)系列的開篇，將整體回顧并展望Dubbo項(xiàng)目發(fā)展，同時(shí)簡要概括后續(xù)文章。5>Dubbo云原生之路：Dubbo3.0Roadm從2019年到現(xiàn)在，在Dubbo畢業(yè)的這一年時(shí)間里，Dubbo社區(qū)和產(chǎn)品都取得長足進(jìn)步，同時(shí)Dubbo云原生版本-Dubbo3.0的開發(fā)工作也已經(jīng)全面鋪開。社區(qū)方面。需要重點(diǎn)提及的有兩點(diǎn)：l一個(gè)是落地與貢獻(xiàn)的企業(yè)用戶進(jìn)一步增加，主動與社區(qū)取得聯(lián)系的中、大規(guī)模公司達(dá)200多家，如攜程、工商銀行、瓜子二手車、網(wǎng)聯(lián)清算、中通等；l另一個(gè)是以Dubbo-go為代表的子社區(qū)蓬勃發(fā)展。產(chǎn)品技術(shù)演進(jìn)方面。DubboJava版發(fā)布10個(gè)版本，在多語言、協(xié)議、性能、服務(wù)治理模型等方面都有深度探索。Dubbogo發(fā)布超過8個(gè)版本，在功能基本對齊Java版本的基礎(chǔ)上，一些方向上也已經(jīng)走在了Java版本前面。值得一提的是，阿里巴巴內(nèi)部也正在積極推動Dubbo社區(qū)版本在內(nèi)部的落地，從今年開始逐步實(shí)現(xiàn)以Dubbo替換其內(nèi)部的HSF框架。這一方面有利于阿里將其在HSF上的豐富服務(wù)治理經(jīng)驗(yàn)回饋輸出到社區(qū)，另一方面阿里官方的落地也將直接加速Dubbo云原生的發(fā)展。在云原生大潮下，3.0已被正式列為今年Dubbo產(chǎn)品建設(shè)的核心目標(biāo)，涉及下一代RPC協(xié)議、服務(wù)治理模型、云原生基礎(chǔ)設(shè)施適配等多方面的內(nèi)容。其中，很多方面已經(jīng)在當(dāng)前的2.7版本中做了前置性探索，如近期發(fā)布的基于HTTP/2的協(xié)議支持、應(yīng)用級服務(wù)發(fā)現(xiàn)等，后續(xù)工作將以此為基礎(chǔ)展開。系列文章也會有對Dubbo3.0Roadmap及技術(shù)方案的詳細(xì)解析。2017年7月，Dubbo開源項(xiàng)目被重新激活，2018年捐獻(xiàn)到Apache基金會，2019年5月，Dubbo正式從Apache基金會孵化畢業(yè)，成為Apache頂級項(xiàng)目。接下來，文章分別從社區(qū)、子社區(qū)、產(chǎn)品三方面介紹Dubbo過去一年的成績。社區(qū)一年發(fā)布24個(gè)版本，貢獻(xiàn)者已超300如果說最開始重新激活是以阿里巴巴為主導(dǎo)的項(xiàng)目維護(hù)投入，那自Dubbo加入Apache起，它就已經(jīng)開始成為一個(gè)社區(qū)主導(dǎo)、社區(qū)貢獻(xiàn)為主的完全開放的基金會項(xiàng)目。Dubbo云原生之路：Dubbo3.0Roadmap發(fā)布<6到今天，這一趨勢正變得更明顯。包括阿里巴巴、攜程、工商銀行、瓜子二手車、網(wǎng)聯(lián)清算、中通等在內(nèi)的互聯(lián)網(wǎng)、傳統(tǒng)企業(yè)公司，在Dubbo的使用與社區(qū)代碼貢獻(xiàn)上都有投入。Dubbo社區(qū)正變得非?；钴S和多樣化。過去一年，Dubbo社區(qū)項(xiàng)目總共發(fā)布24個(gè)版本，發(fā)展Committer/PMC27人，其中有20%的貢獻(xiàn)者是來自于阿里巴巴，80%以上來自不同組織的開發(fā)者或愛好者。Dubbo社區(qū)組織了超過10場線下meetup活動，基本覆蓋了國內(nèi)開發(fā)者聚集的城市。通過線下或線上直播活動，分享超過100個(gè)topic的演講，深度講解Dubbo社區(qū)最新動態(tài)、功能模塊開發(fā)和近期規(guī)劃等。主題演講大多是社區(qū)采集方式，由Dubbo的深度企業(yè)分享實(shí)踐經(jīng)驗(yàn)，其中典型的代表包括攜程、工商銀行、考拉、信用算力等。從Github統(tǒng)計(jì)數(shù)據(jù)來看，DubboStar數(shù)取得新的里程碑，已超過3萬，相比重啟開源時(shí)增長了近5倍；貢獻(xiàn)者由最初的幾十個(gè)增長到現(xiàn)在的300多個(gè)，而這其中有60多人已經(jīng)被提名為committer，不論是貢獻(xiàn)者數(shù)量還是committer比例都得到很大的提升；DubboJava發(fā)布的有65個(gè)。上述主要是對DubboJava項(xiàng)目社區(qū)發(fā)展的總結(jié)，下面將介紹DubboJava產(chǎn)品方面的進(jìn)展。DubboJava迭代，目前主要維護(hù)3個(gè)大版本當(dāng)前社區(qū)維護(hù)的DubboJava大版本主要有3個(gè)，分別是2.5.x、2.6.x和2.7.x。l2.7.x是社區(qū)的主要開發(fā)版本，在過去的一年共發(fā)布了8個(gè)版本（2.7.0-2.7.7每個(gè)版本都有一些值得關(guān)注的特性或功能升級，涵蓋從編程模型、服務(wù)治理、性能到協(xié)議的多個(gè)方面的增強(qiáng)。l2.6.x版本則定位為bugfix版本，過去一年共發(fā)布了3個(gè)版本，主要以修復(fù)問題和安全漏洞為主，并沒有增加太多新的feature。l2.5.x版本從2019年初開始已宣布EOF，只做安全修復(fù)；而到了下半年已經(jīng)完全停止了維護(hù)。下面通過一個(gè)簡要分層模塊圖，回顧過去一段時(shí)間Dubbo的技術(shù)架構(gòu)演進(jìn)，從編程模型、服務(wù)治理、傳輸協(xié)議、性能優(yōu)化等角度切入：7>Dubbo云原生之路：Dubbo3.0Road以上很多功能都已被各大廠商落地，用于解決具體的業(yè)務(wù)問題。我們也期待，接下來這些廠商帶來更多關(guān)于Dubbo實(shí)踐經(jīng)驗(yàn)的深度總結(jié)。Dubbo-go發(fā)展的第五年，正與Dubbo齊頭并進(jìn)除DubboJava之外，Dubbo周邊也發(fā)展出了很多優(yōu)秀的子項(xiàng)目（子社區(qū)其中包括Dubbo-spring-boot-project、Dubbo-go等，這里先著重介紹Dubbo-go子社區(qū)。Dubbo-go項(xiàng)目最早由于雨在2016年5月構(gòu)建，同年9月發(fā)布并開源，如下時(shí)間軸圖清晰記錄了Dubbo-go的前世今生。Dubbo云原生之路：Dubbo3.0Roa秉承"bridgethegapbetweenJavaandGo"天然使命的Dubbo-go，已經(jīng)進(jìn)入第五個(gè)年頭，也走出了自己獨(dú)特的發(fā)展路徑：l當(dāng)前的v1.4.0版本已對齊2.6.x版本，即將發(fā)布的版本將與v2.7.x【對標(biāo)v2.7.5】對齊，而后將會發(fā)布對標(biāo)Dubbo3.x的v1.6.0版本；l獨(dú)立維護(hù)從底層的hessian2協(xié)議庫Dubbo-go-hessian2、網(wǎng)絡(luò)庫getty到上層對標(biāo)Dubbo的Dubbo-go的全套實(shí)現(xiàn)；l獨(dú)立的TCP+Protobuf和gRPC+JSON通信方案也已開發(fā)完成【將包含著在版本v1.5.0中】；l已與Dubbo/gRPC/SpringBoot實(shí)現(xiàn)互聯(lián)互通；l通過接入Opentracing和Promethus，Dubbo-go在可觀測性等微服務(wù)方向的進(jìn)行了自己獨(dú)特的探索；l已實(shí)現(xiàn)了基于HTTPS的可信RPC調(diào)用；l已經(jīng)實(shí)現(xiàn)了自己獨(dú)特的把kubernetes作為注冊中心的微服務(wù)方案；9>Dubbo云原生之路：Dubbo3.0Roadmap發(fā)布Dubbo-go從最開始Dubbo的Go語言實(shí)現(xiàn)，已發(fā)展成為目前Dubbo多語言版本中功能最強(qiáng)大者，它的發(fā)展離不開背后強(qiáng)大的Dubbo-go社區(qū)。除了上述Dubbo-go的自身特性外，通過跨社區(qū)合作，取得了如下成績：l通過與MOSN社區(qū)合作，已經(jīng)實(shí)現(xiàn)Dubbo/Dubbo-go應(yīng)用可以零成本接入基于MOSN實(shí)現(xiàn)DubboMesh，實(shí)現(xiàn)微服務(wù)和云原生共存的“雙模微服務(wù)”；l與sentinel社區(qū)合作，在Dubbo/Dubbo-go完整接入sentinel的降級和限流方案；l與Apollo社區(qū)合作，在Dubbo-go中實(shí)現(xiàn)遠(yuǎn)程配置下發(fā)；l與Nacos社區(qū)合作，實(shí)現(xiàn)基于Nacos的服務(wù)發(fā)現(xiàn)；Dubbo-go（包括子項(xiàng)目）目前已先后在攜程、涂鴉智能和螞蟻金服等公司生產(chǎn)落地。3.0是下一代Dubbo架構(gòu)的代號。一年前，最開始探索ReactiveStream之時(shí)，社區(qū)也曾有過對Dubbo3.0的廣泛討論。而這一次，在云原生大背景下，3.0代表了更全面的Dubbo架構(gòu)升級，涉及到下一代RPC協(xié)議、全新的服務(wù)治理模型和云原生基礎(chǔ)設(shè)施適配等。阿里巴巴是參與Dubbo3.0開發(fā)建設(shè)的主要力量之一，這款始于阿里的開源項(xiàng)目正重新回歸阿里內(nèi)部落地。去年開始，阿里巴巴就已經(jīng)在逐步推動以Dubbo替換其內(nèi)部的HSF框架的工作，通過將Dubbo與HSF兩個(gè)框架融為一體，并在此基礎(chǔ)上發(fā)展出適應(yīng)云原生架構(gòu)的Dubbo版本。Dubbo重回阿里巴巴的落地是擁抱社區(qū)、擁抱云原生、擁抱標(biāo)準(zhǔn)化的一次很好的實(shí)踐。阿里巴巴內(nèi)部Dubbo3.0的落地，對社區(qū)也是一個(gè)重大利好，這一方面有利于阿里巴巴將其在HSF上的豐富服務(wù)治理經(jīng)驗(yàn)回饋輸出到社區(qū)，另一方面也將直接推動Dubbo云原生架構(gòu)的快速演進(jìn)。除了阿里巴巴之外，包括斗魚、工商銀行、愛奇藝、斗魚等廠商也都在參與下一代Dubbo3.0的建設(shè)。下面列出了Dubbo3.0中的三個(gè)重要方向，具體的Roadmap將在接下來文章中單獨(dú)說明：Dubbo云原生之路：Dubbo3.0Roadmap發(fā)布<10l下一代RPC協(xié)議。新協(xié)議將提供更豐富的如Stream、FlowControl等內(nèi)置語義，同時(shí)將具有更好的擴(kuò)展性、網(wǎng)關(guān)的友好性等；l基于應(yīng)用粒度的服務(wù)發(fā)現(xiàn)機(jī)制。在兼顧Dubbo面向接口的易用性與功能性的基礎(chǔ)上，解決與KubernetesNativeService適配問題，解決大規(guī)模集群下的地址推送性能瓶頸問題；l適配云原生基礎(chǔ)設(shè)施的解決方案。這涉及到Dubbo服務(wù)與基礎(chǔ)設(shè)施生命周期對接、KubernetesNativeService適配、適應(yīng)基礎(chǔ)設(shè)施調(diào)度的服務(wù)治理規(guī)則、適配ServiceMesh架構(gòu)的解決方案等；接下來沿著這三個(gè)方面簡要展開。下一代RPC協(xié)議專注在協(xié)議自身來說，下一代的協(xié)議主要聚焦在HTTP/2、ReactiveStream、FlowControl等方面：lReactiveStreamReactiveStream引入RPC，帶來更豐富的通信語義和API編程模型支持，如Request-Stream、Bi-Stream等。lHTTP/2微服務(wù)云原生場景下，基于HTTP/2構(gòu)建的通信協(xié)議具有更好的通用性和穿透性。lFlowControl協(xié)議內(nèi)置流控機(jī)制，支持類似ReqctiveStream的Request(n)流控機(jī)制。從解決的業(yè)務(wù)場景問題上來說，基于新的協(xié)議Dubbo在框架層面要支持智能決策的負(fù)載均衡算法、對Mesh和網(wǎng)關(guān)更友好、更容易提供多語言實(shí)現(xiàn)與互通等。lMesh協(xié)議對穿透Mesh更友好，區(qū)分協(xié)議頭Metadata與RPCPayload，方便完成與Mesh的協(xié)作，包括流量控制機(jī)制、應(yīng)用層配置協(xié)商等。l協(xié)議通用性兼顧通用性與性能，支持協(xié)議能在各種設(shè)備上運(yùn)行。l多語言支持如通過支持Protobuf提供了更完善的跨語言服務(wù)定義與序列化傳輸?shù)闹С?。?yīng)用級服務(wù)治理面向接口一直以來都是Dubbo框架的優(yōu)勢。一方面它的易用性，為開發(fā)者屏蔽了遠(yuǎn)程調(diào)用的存在；另一方面面向接口的地址發(fā)現(xiàn)、服務(wù)治理帶來了更強(qiáng)大的能力，使得整個(gè)Dubbo治理體系非常強(qiáng)大與靈活。既然面向接口有如此多的好處，那為什么我們還要探索面向應(yīng)用的服務(wù)治理模式呢？聽起來似乎有些矛盾。其實(shí)到底是面向接口，還是面向應(yīng)用，只是從不同的角度看Dubbo。我們所聊的“面向接口->面向應(yīng)用”的改造，主要體現(xiàn)在服務(wù)注冊、發(fā)現(xiàn)層面：而我們說的面向應(yīng)用的新模型，主要對第2點(diǎn)，即注冊中心的數(shù)據(jù)組織轉(zhuǎn)變?yōu)椤懊嫦驊?yīng)用/實(shí)例”粒度。這為我們解決兩個(gè)問題：l在服務(wù)發(fā)現(xiàn)層面與KubernetesService等微服務(wù)模型對齊。l服務(wù)發(fā)現(xiàn)的數(shù)據(jù)量將有一個(gè)量級的下降，從“接口數(shù)*實(shí)例數(shù)”下降到“應(yīng)用數(shù)*實(shí)例數(shù)”。Dubbo云原生之路：Dubbo3.0Roadmap發(fā)布<12具體可以參見文章《Dubbo邁出云原生重要一步-應(yīng)用級服務(wù)發(fā)現(xiàn)解析》，本系列文章后續(xù)也會有對這部分機(jī)制和實(shí)現(xiàn)的更深度解析。云原生基礎(chǔ)設(shè)施云原生帶來了底層基礎(chǔ)設(shè)施，應(yīng)用開發(fā)、部署和運(yùn)維等全方位的變化：基礎(chǔ)設(shè)施l基礎(chǔ)設(shè)施調(diào)度機(jī)制變化，帶來運(yùn)維（生命周期）、服務(wù)治理等方面的變化。l服務(wù)發(fā)現(xiàn)能力下沉，Kubernetes抽象了NativeServiceDiscovery。ServiceMesh-云原生微服務(wù)解決方案lMesh為跨語言、sdk升級等提供了解決方案，Dubbosdk要與Mesh協(xié)作，做到功能、協(xié)議、服務(wù)治理等多方便的適配。lMesh尚未大規(guī)模鋪開，且其更適合對流量管控更關(guān)注的應(yīng)用，傳統(tǒng)SDK的性能優(yōu)勢仍舊存在，兩者混部遷移場景可能會長期存在。從應(yīng)用場景上，Dubbo可能的部署環(huán)境包括：l不使用KubernetesNativeService，Kubernetes只作為容器編排調(diào)度設(shè)施，繼續(xù)使用Dubbo自建的服務(wù)注冊、發(fā)現(xiàn)機(jī)制。l復(fù)用KubernetesNativeService，Dubbo不再關(guān)心服務(wù)注冊，DubboClient負(fù)責(zé)服務(wù)發(fā)現(xiàn)與流量分配。lDubbosdk往Mesh遷移，一方面要做到適應(yīng)Mesh架構(gòu)，成為Mesh體系下的RPC編程和通信方案；另一方面要做到Dubbo與Mesh架構(gòu)長期共存，互相打通服務(wù)發(fā)現(xiàn)和治理體系。lKubernetes上與云下混合部署的平滑遷移支持，包括服務(wù)發(fā)現(xiàn)的統(tǒng)一與網(wǎng)絡(luò)通信方案的打通。從Dubbo功能劃分上，將著重從以下方面提供對云原生基礎(chǔ)設(shè)施的支持：13>Dubbo云原生之路：Dubbo3.生命周期：Dubbo與Kubernetes調(diào)度機(jī)制綁定，保持服務(wù)生命周期與Pod容器等生命周期的自動對齊治理規(guī)則：服務(wù)治理規(guī)則在規(guī)則體、規(guī)則格式方面進(jìn)行優(yōu)化，如規(guī)則體以YAML描述、取消過濾規(guī)則對IP的直接依賴，定義規(guī)則特有的CRD資源等。服務(wù)發(fā)現(xiàn)：支持K8SNativeService的服務(wù)發(fā)現(xiàn)，包括DNS、API-Server，支持xDS的服務(wù)發(fā)現(xiàn)Mesh架構(gòu)協(xié)作：構(gòu)建下一代的基于HTTP/2的通信協(xié)議，支持xDS的標(biāo)準(zhǔn)化的數(shù)據(jù)下發(fā)新一代的RPC協(xié)議和應(yīng)用級服務(wù)發(fā)現(xiàn)模型將會是這一部分的前置基礎(chǔ)。作為系列文章開篇，我們在這里對Dubbo過去一年的成績做了簡要的總結(jié)與回顧，包括Dubbo社區(qū)、產(chǎn)品迭代的發(fā)展。接下來我們會看到更多來自深度Dubbo用戶的落地經(jīng)驗(yàn)分享，Dubbo-go子社區(qū)的發(fā)展故事等。更重要的，我們也對下一代云原生Dubbo-Dubbo3.0做了展望，后續(xù)關(guān)于Dubbo3.0Roadmap、方案設(shè)計(jì)與進(jìn)展解析等也將在后面的文章中發(fā)布。Dubbo3.0前瞻之：應(yīng)用級服務(wù)發(fā)現(xiàn)作者：劉軍，花名陸龜，Github賬號Chickenlj，ApacheDubboPMC，項(xiàng)目核心開發(fā)，見證了Dubbo重啟開源，到從Apache基金會畢業(yè)的整個(gè)過程?，F(xiàn)任職阿里云云原生應(yīng)用平臺團(tuán)隊(duì)，參與服務(wù)框架、微服務(wù)相關(guān)工作，目前主要在推動Dubbo3.0-Dubbo云原生。從Internet剛開始興起，如何動態(tài)感知后端服務(wù)的地址變化就是一個(gè)必須要面對的問題，為此人們定義了DNS協(xié)議，基于此協(xié)議，調(diào)用方只需要記住由固定字符串組成的域名，就能輕松完成對后端服務(wù)的訪問，而不用擔(dān)心流量最終會訪問到哪些機(jī)器IP，因?yàn)橛写斫M件會基于DNS地址解析后的地址列表，將流量透明的、均勻的分發(fā)到不同的后端機(jī)器上。在使用微服務(wù)構(gòu)建復(fù)雜的分布式系統(tǒng)時(shí)，如何感知backend服務(wù)實(shí)例的動態(tài)上下線，也是微服務(wù)框架最需要關(guān)心并解決的問題之一。業(yè)界將這個(gè)問題稱之為-微服務(wù)的地址發(fā)現(xiàn)（ServiceDiscovery業(yè)界比較有代表性的微服務(wù)框架如SpringCloud、Microservices、Dubbo等都抽象了強(qiáng)大的動態(tài)地址發(fā)現(xiàn)能力，并且為了滿足微服務(wù)業(yè)務(wù)場景的需求，絕大多數(shù)框架的地址發(fā)現(xiàn)都是基于自己設(shè)計(jì)的一套機(jī)制來實(shí)現(xiàn)，因此在能力、靈活性上都要比傳統(tǒng)DNS豐富得多。如SpringCloud中常用的Eureka，Dubbo中常用的Zookeeper、Nacos等，這些注冊中心實(shí)現(xiàn)不止能夠傳遞地址（IP+Port），還包括一些微服務(wù)的Metadata信息，如實(shí)例序列化類型、實(shí)例方法列表、各個(gè)方法級的定制化配置等。下圖是微服務(wù)中ServiceDiscovery的基本工作原理圖，微服務(wù)體系中的實(shí)例大概可分為三種角色：服務(wù)提供者（Provider）、服務(wù)消費(fèi)者（Consumer）和注冊中心(Registry）。而不同框架實(shí)現(xiàn)間最主要的區(qū)別就體現(xiàn)在注冊中心數(shù)據(jù)的組織：地址如何組織、以什么粒度組織、除地址外還同步哪些數(shù)據(jù)？我們今天這篇文章就是圍繞這三個(gè)角色展開，重點(diǎn)看下Dubbo中對于服務(wù)發(fā)現(xiàn)方案的設(shè)計(jì)，包括之前老的服務(wù)發(fā)現(xiàn)方案的優(yōu)勢和缺點(diǎn)，以及Dubbo3.0中正在設(shè)計(jì)、開發(fā)中的全新的面向應(yīng)用粒度的地址發(fā)現(xiàn)方案，我們期待這個(gè)新的方案能做到：l支持幾十萬/上百萬級集群實(shí)例的地址發(fā)現(xiàn)。l與不同的微服務(wù)體系（如SpringCloud）實(shí)現(xiàn)在地址發(fā)現(xiàn)層面的互通。我們先以一個(gè)DEMO應(yīng)用為例，來快速的看一下Dubbo“接口粒度”服務(wù)發(fā)現(xiàn)與“應(yīng)用粒度”服務(wù)發(fā)現(xiàn)體現(xiàn)出來的區(qū)別。這里我們重點(diǎn)關(guān)注Provider實(shí)例是如何向注冊中心注冊的，并且，為了體現(xiàn)注冊中心數(shù)據(jù)量變化，我們觀察的是兩個(gè)Provider實(shí)例的場景。應(yīng)用DEMO提供的服務(wù)列表如下：<<dubbo:serviceinterface="org.apache.dubbo.samples.basic.api.DemoService"<dubbo:serviceinterface="org.apache.dubbo.samples.basic.api.GreetingService"我們示例注冊中心實(shí)現(xiàn)采用的是Zookeeper，啟動03和04兩個(gè)實(shí)例后，以下是兩種模式下注冊中心的實(shí)際數(shù)據(jù)。03實(shí)例注冊的數(shù)據(jù)：dubbodubbo://03:20880/org.apache.dubbo.samples.basic.api.DemoService?anyhost=true&application=demo-provider&default=true&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false&interface=org.apache.dubbo.samples.basic.api.DemoService&methods=testVoid,sayHello&pid=995&release=2.7.7&side=provider×tamp=1596988171266dubbo://03:20880/org.apache.dubbo.samples.basic.api.GreetingService?anyhost=true&application=demo-provider&default=true&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false&interface=org.apache.dubbo.samples.basic.api.GreetingService&methods=greeting&pid=995&release=2.7.7&side=provider×tamp=159698817081604實(shí)例注冊的數(shù)據(jù)：dubbodubbo://04:20880/org.apache.dubbo.samples.basic.api.DemoService?anyhost=true&application=demo-provider&default=true&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false&interface=org.apache.dubbo.samples.basic.api.DemoService&methods=testVoid,sayHello&pid=995&release=2.7.7&side=provider×tamp=1596988171266dubbo://04:20880/org.apache.dubbo.samples.basic.api.GreetingService?anyhost=true&application=demo-provider&default=true&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false&interface=org.apache.dubbo.samples.basic.api.GreetingService&methods=greeting&pid=995&release=2.7.7&side=provider×tamp=15969881708162.“應(yīng)用粒度”服務(wù)發(fā)現(xiàn)03實(shí)例數(shù)據(jù)：{{"name":"demo-provider","id":"03"address":"03","metadata":{"dubbo.metadata.storage-type":"local","dubbo.revision":"6785535733750099598"},}04實(shí)例數(shù)據(jù)：{{"name":"demo-provider","id":"04:2"address":"04","metadata":{"dubbo.metadata.storage-type":"local","dubbo.revision":"7829635812370099387"},}對比以上兩種不同粒度的服務(wù)發(fā)現(xiàn)模式，從“接口粒度”升級到“應(yīng)用粒度”后我們可以總結(jié)出最大的區(qū)別是：注冊中心數(shù)據(jù)量不再與接口數(shù)成正比，不論應(yīng)用提供有多少接口，注冊中心只有一條實(shí)例數(shù)據(jù)。那么接下來我們詳細(xì)看下這個(gè)變化給Dubbo帶來了哪些好處。我們先說結(jié)論，應(yīng)用級服務(wù)發(fā)現(xiàn)給Dubbo帶來以下優(yōu)勢：與業(yè)界主流微服務(wù)模型對齊，比如SpringCloud、KubernetesNativeService等提升性能與可伸縮性。注冊中心數(shù)據(jù)的重新組織（減少能最大幅度的減輕注冊中心的存儲、推送壓力，進(jìn)而減少DubboConsumer側(cè)的地址計(jì)算壓力；集群規(guī)模也開始變得可預(yù)測、可評估（與RPC接口數(shù)量無關(guān)，只與實(shí)例部署規(guī)模相關(guān)）自動、透明的實(shí)例地址發(fā)現(xiàn)（負(fù)載均衡）是所有微服務(wù)框架需要解決的事情，這能讓后端的部署結(jié)構(gòu)對上游微服務(wù)透明，上游服務(wù)只需要從收到的地址列表中選取一個(gè)，發(fā)起調(diào)用就可以了。要實(shí)現(xiàn)以上目標(biāo)，涉及兩個(gè)關(guān)鍵點(diǎn)的自動同步：l實(shí)例地址，服務(wù)消費(fèi)方需要知道地址以建立鏈接。lRPC方法定義，服務(wù)消費(fèi)方需要知道RPC服務(wù)的具體定義，不論服務(wù)類型是rest或rmi等。對于RPC實(shí)例間借助注冊中心的數(shù)據(jù)同步，REST定義了一套非常有意思的成熟度模型，感興趣的朋友可以參考這里：點(diǎn)擊查看，按照文章中的4級成熟度定義，Dubbo當(dāng)前基于接口粒度的模型可以對應(yīng)到L4級別。接下來，我們看看Dubbo、SpringCloud以及Kubernetes分別是怎么圍繞自動化的實(shí)例地址發(fā)現(xiàn)這個(gè)目標(biāo)設(shè)計(jì)的。a)SpringCloudSpringCloud通過注冊中心只同步了應(yīng)用與實(shí)例地址，消費(fèi)方可以基于實(shí)例地址與服務(wù)提供方建立鏈接，但是消費(fèi)方對于如何發(fā)起http調(diào)用（SpringCloud基于rest通信）一無所知，比如對方有哪些httpendpoint，需要傳入哪些參數(shù)等。RPC服務(wù)這部分信息目前都是通過線下約定或離線的管理系統(tǒng)來協(xié)商的。這種架構(gòu)的優(yōu)缺點(diǎn)總結(jié)如下。優(yōu)勢：部署結(jié)構(gòu)清晰、地址推送量小。缺點(diǎn)：地址訂閱需要指定應(yīng)用名，provider應(yīng)用變更（拆分）需消費(fèi)端感知；RPC調(diào)用無法全自動同步。Dubbo通過注冊中心同時(shí)同步了實(shí)例地址和RPC方法，因此其能實(shí)現(xiàn)RPC過程的自動同步，面向RPC編程、面向RPC治理，對后端應(yīng)用的拆分消費(fèi)端無感知，其缺點(diǎn)則是地址推送數(shù)量變大，和RPC方法成正比。c)Dubbo+KubernetesDubbo要支持Kubernetesnativeservice，相比之前自建注冊中心的服務(wù)發(fā)現(xiàn)體系來說，在工作機(jī)制上主要有兩點(diǎn)變化：l服務(wù)注冊由平臺接管，provider不再需要關(guān)心服務(wù)注冊。lconsumer端服務(wù)發(fā)現(xiàn)將是Dubbo關(guān)注的重點(diǎn)，通過對接平臺層的API-Server、DNS等，Dubboclient可以通過一個(gè)ServiceName（通常對應(yīng)到ApplicationName）查詢到一組Endpoints（一組運(yùn)行provider的pod通過將Endpoints映射到Dubbo內(nèi)部地址列表，以驅(qū)動Dubbo內(nèi)置的負(fù)載均衡機(jī)制工作。KubernetesService作為一個(gè)抽象概念，怎么映射到Dubbo是一個(gè)值得討論的點(diǎn)：ServiceName->ApplicationName，Dubbo應(yīng)用和Kubernetes服務(wù)一一對應(yīng)，對于微服務(wù)運(yùn)維和建設(shè)環(huán)節(jié)透明，與開發(fā)階段解耦：apiVersionapiVersion:v1kind:Servicemetadata:name:provider-app-namespec:selector:app:provider-app-nameports:-protocol:TCPtargetPort:9376ServiceName->DubboRPCService，Kubernetes要維護(hù)調(diào)度的服務(wù)與應(yīng)用內(nèi)建RPC服務(wù)綁定，維護(hù)的服務(wù)數(shù)量變多：apiVersion:v1kind:Servicemetadata:name:rpc-service-1spec:selector:app:provider-app-name...apiVersion:v1kind:Servicemetadata:name:rpc-service-2spec:selector:app:provider-app-name...apiVersion:v1kind:Servicemetadata:name:rpc-service-Nspec:selector:app:provider-app-name...結(jié)合以上幾種不同微服務(wù)框架模型的分析，我們可以發(fā)現(xiàn)，Dubbo與SpringCloud、Kubernetes等不同產(chǎn)品在微服務(wù)的抽象定義上還是存在很大不同的。SpringCloud和Kubernetes在微服務(wù)的模型抽象上還是比較接近的，兩者基本都只關(guān)心實(shí)例地址的同步，如果我們?nèi)リP(guān)心其他的一些服務(wù)框架產(chǎn)品，會發(fā)現(xiàn)它們絕大多數(shù)也是這么設(shè)計(jì)的，即REST成熟度模型中的L3級別。對比起來Dubbo則相對是比較特殊的存在，更多的是從RPC服務(wù)的粒度去設(shè)計(jì)的。對應(yīng)REST成熟度模型中的L4級別。如我們上面針對每種模型做了詳細(xì)的分析，每種模型都有其優(yōu)勢和不足。而我們最初決定Dubbo要做出改變，往其他的微服務(wù)發(fā)現(xiàn)模型上的對齊，是我們最早在確定Dubbo的云原生方案時(shí)，我們發(fā)現(xiàn)要讓Dubbo去支持KubernetesNativeService，模型對齊是一個(gè)基礎(chǔ)條件；另一點(diǎn)是來自用戶側(cè)對Dubbo場景化的一些工程實(shí)踐的需求，得益于Dubbo對多注冊、多協(xié)議能力的支持，使得Dubbo聯(lián)通不同的微服務(wù)體系成為可能，而服務(wù)發(fā)現(xiàn)模型不一致成為其中的一個(gè)障礙，這部分的場景描述請參見以下文章：點(diǎn)擊查看。2.更大規(guī)模的微服務(wù)集群-解決性能瓶頸這部分涉及到和注冊中心、配置中心的交互，關(guān)于不同模型下注冊中心數(shù)據(jù)的變化，之前原理部分我們簡單分析過。為更直觀的對比服務(wù)模型變更帶來的推送效率提升，我們來通過一個(gè)示例看一下不同模型注冊中心的對比：圖中左邊是微服務(wù)框架的一個(gè)典型工作流程，Provider和Consumer通過注冊中心實(shí)現(xiàn)自動化的地址通知。其中，Provider實(shí)例的信息如圖中表格所示：應(yīng)用DEMO包含三個(gè)接口DemoService123，當(dāng)前實(shí)例的ip地址為0。l對于SpringCloud和Kubernetes模型，注冊中心只會存儲一條DEMO-0+metadata的數(shù)據(jù)。l對于老的Dubbo模型，注冊中心存儲了三條接口粒度的數(shù)據(jù)，分別對應(yīng)三個(gè)接口DemoService123，并且很多的址數(shù)據(jù)都是重復(fù)的?？梢钥偨Y(jié)出，基于應(yīng)用粒度的模型所存儲和推送的數(shù)據(jù)量是和應(yīng)用、實(shí)例數(shù)成正比的，只有當(dāng)我們的應(yīng)用數(shù)增多或應(yīng)用的實(shí)例數(shù)增長時(shí)，地址推送壓力才會上漲。而對于基于接口粒度的模型，數(shù)據(jù)量是和接口數(shù)量正相關(guān)的，鑒于一個(gè)應(yīng)用通常發(fā)布多個(gè)接口的現(xiàn)狀，這個(gè)數(shù)量級本身比應(yīng)用粒度是要乘以倍數(shù)的；另外一個(gè)關(guān)鍵點(diǎn)在于，接口粒度導(dǎo)致的集群規(guī)模評估的不透明，相對于實(shí)i例、應(yīng)用增長都通常是在運(yùn)維側(cè)的規(guī)劃之中，接口的定義更多的是業(yè)務(wù)側(cè)的內(nèi)部行為，往往可以繞過評估給集群帶來壓力。以Consumer端服務(wù)訂閱舉例，根據(jù)我對社區(qū)部分Dubbo中大規(guī)模頭部用戶的粗略統(tǒng)計(jì)，根據(jù)受統(tǒng)計(jì)公司的實(shí)際場景，一個(gè)Consumer應(yīng)用要消費(fèi)（訂閱）的Provier應(yīng)用數(shù)量往往要超過10個(gè)，而具體到其要消費(fèi)（訂閱）的的接口數(shù)量則通常要達(dá)到30個(gè)，平均情況下Consumer訂閱的3個(gè)接口來自同一個(gè)Provider應(yīng)用，如此計(jì)算下來，如果以應(yīng)用粒度為地址通知和選址基本單位，則平均地址推送和計(jì)算量將下降60%還要多。而在極端情況下，也就是當(dāng)Consumer端消費(fèi)的接口更多的來自同一個(gè)應(yīng)用時(shí)，這個(gè)地址推送與內(nèi)存消耗的占用將會進(jìn)一步得到降低，甚至可以超過80%以上。一個(gè)典型的幾段場景即是Dubbo體系中的網(wǎng)關(guān)型應(yīng)用，有些網(wǎng)關(guān)應(yīng)用消費(fèi)（訂閱）達(dá)100+應(yīng)用，而消費(fèi)（訂閱）的服務(wù)有1000+，平均有10個(gè)接口來自同一個(gè)應(yīng)用，如果我們把地址推送和計(jì)算的粒度改為應(yīng)用，則地址推送量從原來的n1000變?yōu)閚100，地址數(shù)量降低可達(dá)近90%。上面一節(jié)我們從服務(wù)模型及支撐大規(guī)模集群的角度分別給出了Dubbo往應(yīng)用級服務(wù)發(fā)現(xiàn)靠攏的好處或原因，但這么做的同時(shí)接口粒度的服務(wù)治理能力還是要繼續(xù)保留，這是Dubbo框架編程模型易用性、服務(wù)治理能力優(yōu)勢的基礎(chǔ)。以下是我認(rèn)為我們做服務(wù)模型遷移仍要堅(jiān)持的設(shè)計(jì)原則：l新的服務(wù)發(fā)現(xiàn)模型要實(shí)現(xiàn)對原有Dubbo消費(fèi)端開發(fā)者的無感知遷移，即Dubbo繼續(xù)面向RPC服務(wù)編程、面向RPC服務(wù)治理，做到對用戶側(cè)完全無感知。l建立Consumer與Provider間的自動化RPC服務(wù)元數(shù)據(jù)協(xié)調(diào)機(jī)制，解決傳統(tǒng)微服務(wù)模型無法同步RPC級接口配置的缺點(diǎn)。應(yīng)用級服務(wù)發(fā)現(xiàn)作為一種新的服務(wù)發(fā)現(xiàn)機(jī)制，和以前Dubbo基于RPC服務(wù)粒度的服務(wù)發(fā)現(xiàn)在核心流程上基本上是一致的：即服務(wù)提供者往注冊中心注冊地址信息，服務(wù)消費(fèi)者從注冊中心拉取&訂閱地址信息。這里主要的不同有以下兩點(diǎn)：注冊中心數(shù)據(jù)以“應(yīng)用-實(shí)例列表”格式組織，不再包含RPC服務(wù)信息以下是每個(gè)Instancemetadata的示例數(shù)據(jù)，總的原則是metadata只包含當(dāng)前instance節(jié)點(diǎn)相關(guān)的信息，不涉及RPC服務(wù)粒度的信息?？傮w信息概括如下：實(shí)例地址、實(shí)例各種環(huán)境標(biāo)、metadataservice元數(shù)據(jù)、其他少量必要屬性。{{"name":"provider-app-name","id":"02"address":"02","name":"provider-app-name","metadata":{"storage-type":"local","revision":"6785535733750099598",}},"registrationTimeUTC":1583461240877,"serviceType":"DYNAMIC",}Client–Server自行協(xié)商RPC方法信息在注冊中心不再同步RPC服務(wù)信息后，服務(wù)自省在服務(wù)消費(fèi)端和提供端之間建立了一條內(nèi)置的RPC服務(wù)信息協(xié)商機(jī)制，這也是“服務(wù)自省”這個(gè)名字的由來。服務(wù)端實(shí)例會暴露一個(gè)預(yù)定義的MetadataServiceRPC服務(wù)，消費(fèi)端通過調(diào)用MetadataService獲取每個(gè)實(shí)例RPC方法相關(guān)的配置信息。當(dāng)前MetadataService返回的數(shù)據(jù)格式如下：[["dubbo://02:20880/org.apache.dubbo.demo.DemoService?anyhost=true&application=demo-provider&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false&interface=org.apache.dubbo.demo.DemoService&methods=sayHello&pid=9585&release=2.7.5&side=provider×tamp=1583469714314","dubbo://02:20880/org.apache.dubbo.demo.HelloService?anyhost=true&application=demo-provider&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false&interface=org.apache.dubbo.demo.DemoService&methods=sayHello&pid=9585&release=2.7.5&side=provider×tamp=1583469714314",""dubbo://02:20880/org.apache.dubbo.demo.WorldService?anyhost=true&application=demo-provider&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false&interface=org.apache.dubbo.demo.DemoService&methods=sayHello&pid=9585&release=2.7.5&side=provider×tamp=1583469714314"]熟悉Dubbo基于RPC服務(wù)粒度的服務(wù)發(fā)現(xiàn)模型的開發(fā)者應(yīng)該能看出來，服務(wù)自省機(jī)制機(jī)制將以前注冊中心傳遞的URL一拆為二：l一部分和實(shí)例相關(guān)的數(shù)據(jù)繼續(xù)保留在注冊中心，如ip、port、機(jī)器標(biāo)識等。l另一部分和RPC方法相關(guān)的數(shù)據(jù)從注冊中心移除，轉(zhuǎn)而通過MetadataService暴露給消費(fèi)端。理想情況下是能達(dá)到數(shù)據(jù)按照實(shí)例、RPC服務(wù)嚴(yán)格區(qū)分開來，但明顯可以看到以上實(shí)現(xiàn)版本還存在一些數(shù)據(jù)冗余，有些也數(shù)據(jù)還未合理劃分。尤其是MetadataService部分，其返回的數(shù)據(jù)還只是簡單的URL列表組裝，這些URL其實(shí)是包含了全量的數(shù)據(jù)。以下是服務(wù)自省的一個(gè)完整工作流程圖，詳細(xì)描述了服務(wù)注冊、服務(wù)發(fā)現(xiàn)、MetadataService、RPC調(diào)用間的協(xié)作流程。l服務(wù)提供者啟動，首先解析應(yīng)用定義的“普通服務(wù)”并依次注冊為RPC服務(wù)，緊接著注冊內(nèi)建的MetadataService服務(wù)，最后打開TCP監(jiān)聽端口。l啟動完成后，將實(shí)例信息注冊到注冊中心（僅限ip、port等實(shí)例相關(guān)數(shù)據(jù)），提供者啟動完成。l服務(wù)消費(fèi)者啟動，首先依據(jù)其要“消費(fèi)的provider應(yīng)用名”到注冊中心查詢地址列表，并完成訂閱（以實(shí)現(xiàn)后續(xù)地址變更自動通知）。l消費(fèi)端拿到地址列表后，緊接著對MetadataService發(fā)起調(diào)用，返回結(jié)果中包含了所有應(yīng)用定義的“普通服務(wù)”及其相關(guān)配置信息。l至此，消費(fèi)者可以接收外部流量，并對提供者發(fā)起DubboRPC調(diào)用。在以上流程中，我們只考慮了一切順利的情況，但在更詳細(xì)的設(shè)計(jì)或編碼實(shí)現(xiàn)中，我們還需要嚴(yán)格約定一些異常場景下的框架行為。比如，如果消費(fèi)者M(jìn)etadataService調(diào)用失敗，則在重試知道成功之前，消費(fèi)者將不可以接收外部流量。元數(shù)據(jù)同步機(jī)制Client與Server間在收到地址推送后的配置同步是服務(wù)自省的關(guān)鍵環(huán)節(jié)，目前針對元數(shù)據(jù)同步有兩種具體的可選方案，分別是：l內(nèi)建MetadataService。l獨(dú)立的元數(shù)據(jù)中心，通過中細(xì)化的元數(shù)據(jù)集群協(xié)調(diào)數(shù)據(jù)。內(nèi)建MetadataServiceMetadataService通過標(biāo)準(zhǔn)的Dubbo協(xié)議暴露，根據(jù)查詢條件，會將內(nèi)存中符合條件的“普通服務(wù)”配置返回給消費(fèi)者。這一步發(fā)生在消費(fèi)端選址和調(diào)用前。元數(shù)據(jù)中心復(fù)用2.7版本中引入的元數(shù)據(jù)中心，provider實(shí)例啟動后，會嘗試將內(nèi)部的RPC服務(wù)組織成元數(shù)據(jù)的格式到元數(shù)據(jù)中心，而consumer則在每次收到注冊中心推送更新后，主動查詢元數(shù)據(jù)中心。注意consumer端查詢元數(shù)據(jù)中心的時(shí)機(jī)，是等到注冊中心的地址更新通知之后。也就是通過注冊中心下發(fā)的數(shù)據(jù)，我們能明確的知道何時(shí)某個(gè)實(shí)例的元數(shù)據(jù)被更新了，此時(shí)才需要去查元數(shù)據(jù)中心。RPC服務(wù)<->應(yīng)用映射關(guān)系回顧上文講到的注冊中心關(guān)于“應(yīng)用-實(shí)例列表”結(jié)構(gòu)的數(shù)據(jù)組織形式，這個(gè)變動目前對開發(fā)者并不是完全透明的，業(yè)務(wù)開發(fā)側(cè)會感知到查詢/訂閱地址列表的機(jī)制的變化。具體來說，相比以往我們基于RPC服務(wù)來檢索地址，現(xiàn)在consumer需要通過指定provider應(yīng)用名才能實(shí)現(xiàn)地址查詢或訂閱。老的Consumer開發(fā)與配置示例：<!--<!--框架直接通過RPCService1/2/N去注冊中心查詢或訂閱地址列表--><dubbo:registryaddress="zookeeper://<dubbo:referenceinterface="RPCService1"/><dubbo:referenceinterface="RPCService2"/><dubbo:referenceinterface="RPCServiceN"/>新的Consumer開發(fā)與配置示例：<!--<!--框架需要通過額外的provided-by="provider-app-x"才能在注冊中心查詢或訂閱到地址列表--><dubbo:registryaddress="zookeeper://:2181?registry-type=service"/><dubbo:referenceinterface="RPCService1"provided-by="provider-app-x"/><dubbo:referenceinterface="RPCService2"provided-by="provider-app-x"/><dubbo:referenceinterface="RPCServiceN"provided-by="provider-app-y"/>以上指定provider應(yīng)用名的方式是SpringCloud當(dāng)前的做法，需要consumer端的開發(fā)者顯示指定其要消費(fèi)的provider應(yīng)用。以上問題的根源在于注冊中心不知道任何RPC服務(wù)相關(guān)的信息，因此只能通過應(yīng)用名來查詢。為了使整個(gè)開發(fā)流程對老的Dubbo用戶更透明，同時(shí)避免指定provider對可擴(kuò)展性帶來的影響（參見下方說明我們設(shè)計(jì)了一套RPC服務(wù)到應(yīng)用名的映射關(guān)系，以嘗試在consumer自動完成RPC服務(wù)到provider應(yīng)用名的轉(zhuǎn)換。Dubbo之所以選擇建立一套“接口-應(yīng)用”的映射關(guān)系，主要是考慮到service-app映射關(guān)系的不確定性。一個(gè)典型的場景即是應(yīng)用/服務(wù)拆分，如上面提到的配置<dubbo:referenceinterface="RPCService2"provided-by="provider-app-x"/>，PCService2是定義于provider-app-x中的一個(gè)服務(wù)，未來它隨時(shí)可能會被開發(fā)者分拆到另外一個(gè)新的應(yīng)用如provider-app-x-1中，這個(gè)拆分要被所有的PCService2消費(fèi)方感知到，并對應(yīng)用進(jìn)行修改升級，如改為<dubbo:referenceinterface="RPCService2"provided-by="provider-app-x-1"/>，這樣的升級成本不可否認(rèn)還是挺高的。到底是Dubbo框架幫助開發(fā)者透明的解決這個(gè)問題，還是交由開發(fā)者自己去解決，當(dāng)然這只是個(gè)策略選擇問題，并且Dubbo2.7.5+版本目前是都提供了的。其實(shí)我個(gè)人更傾向于交由業(yè)務(wù)開發(fā)者通過組織上的約束來做，這樣也可進(jìn)一步降低Dubbo框架的復(fù)雜度，提升運(yùn)行態(tài)的穩(wěn)定性。應(yīng)用級服務(wù)發(fā)現(xiàn)機(jī)制是Dubbo面向云原生走出的重要一步，它幫Dubbo打通了與其他微服務(wù)體系之間在地址發(fā)現(xiàn)層面的鴻溝，也成為Dubbo適配KubernetesNativeService等基礎(chǔ)設(shè)施的基礎(chǔ)。我們期望Dubbo在新模型基礎(chǔ)上，能繼續(xù)保留在編程易用性、服務(wù)治理能力等方面強(qiáng)大的優(yōu)勢。但是我們也應(yīng)該看到應(yīng)用粒度的模型一方面帶來了新的復(fù)雜性，需要我們繼續(xù)去優(yōu)化與增強(qiáng)；另一方面，除了地址存儲與推送之外，應(yīng)用粒度在幫助Dubbo選址層面也有進(jìn)一步挖掘的潛力。Dubbo3.0前瞻之：重構(gòu)SpringCloud服務(wù)治理作者：作者：小馬哥（mercyblitzJava勸退師，《SpringBoot編程思想》作者，ApacheDubboPMC、SpringCloudAlibaba項(xiàng)目架構(gòu)師。目前主要負(fù)責(zé)阿里集團(tuán)中間件開源項(xiàng)目、微服務(wù)技術(shù)實(shí)施、架構(gòu)衍進(jìn)、基礎(chǔ)設(shè)施構(gòu)建等。在Java微服務(wù)生態(tài)中，SpringCloud成為了開發(fā)人員的首選技術(shù)棧，然而隨著實(shí)踐的深入和運(yùn)用規(guī)模的擴(kuò)大，大家逐漸意識到SpringCloud的局限性。在服務(wù)治理方面，相較于Dubbo而言，SpringCloud并不成熟。遺憾的是，Dubbo往往被部分開發(fā)者片面地視作服務(wù)治理的RPC框架，而非微服務(wù)基礎(chǔ)設(shè)施。即使是那些有意將SpringCloud遷移至Dubbo的小伙伴，當(dāng)面對其中遷移和改造的成本時(shí)，難免望而卻步。慶幸的是，Dubbo3的到來將給這一局面帶來重要變革，未來DubboSpringCloud將無縫對接Dubbo3，作為SpringCloudAlibaba的最核心組件，完全地?fù)肀pringCloud技術(shù)棧，不但無縫地整合SpringCloud注冊中心，包括Nacos、Eureka、Zookeeper以及Consul，而且完全地兼容SpringCloudOpenFeign以及@LoadBalancedRestTemplate，本文將討論DubboSpringCloud對SpringCloud技術(shù)棧所帶來的革命性變化由于SpringCloud技術(shù)棧涵蓋的特性眾多，因此本文討論的范圍僅限于服務(wù)治理部分。本文作為Dubbo3的前瞻，將著重講解當(dāng)前版本的DubboSpringCloud實(shí)現(xiàn)，DubboSpringCloud得以實(shí)現(xiàn)的一個(gè)重要基礎(chǔ)即是我們前瞻之一提到的應(yīng)用級服務(wù)發(fā)現(xiàn)。應(yīng)用級服務(wù)發(fā)現(xiàn)是Dubbo3規(guī)劃中的重要一環(huán)，是Dubbo與云原生基礎(chǔ)設(shè)施打通、實(shí)現(xiàn)大規(guī)模微服務(wù)集群的基石。Dubbo3.0前瞻之：重構(gòu)SpringCloud服務(wù)治理<32其實(shí)Dubbo社區(qū)早在2.7.5版本開始便探索了應(yīng)用級服務(wù)發(fā)現(xiàn)，嘗試去優(yōu)化Dubbo的服務(wù)發(fā)現(xiàn)模型，因此DubboSpringCloud是基于DubboSpringBoot2.7.x（從2.7.0開始，DubboSpringBoot與Dubbo在版本上保持一致）和SpringCloud2.x開發(fā)，而本文也將基于2.7.x的這個(gè)先期版本展開講解。無論開發(fā)人員是Dubbo用戶還是SpringCloud用戶，都能輕松地駕馭DubboSpringCloud，并以接近“零”成本的代價(jià)使應(yīng)用向上遷移。DubboSpringCloud致力于簡化CloudNative開發(fā)成本，提高研發(fā)效能以及提升應(yīng)用性能等目的。由于Spring官方宣布SpringCloudEdgware(下文簡稱為“E”版)將在2019年8月1日后停止維護(hù)13，因此，目前DubboSpringCloud發(fā)布版本并未對“E”版提供支持，僅為“F”版和“G”版開發(fā)，同時(shí)也建議和鼓勵SpringCloud用戶更新至“F”版或“G”版。同時(shí)，DubboSpringCloud基于ApacheDubboSpringBoot2.7.x開發(fā)（最低Java版本為1.8提供完整的Dubbo注解驅(qū)動、外部化配置以及Production-Ready的特性，點(diǎn)擊查看詳情。以下表格將說明DubboSpringCloud版本關(guān)系映射關(guān)系：SpringCloudSpringCloudAlibabaSpringBootDubboSpringBootFinchley0.2.2.RELEASE2.0.x2.7.1Greenwich2.2.1.RELEASE2.1.x2.7.1Edgware0.1.2.RELEASE1.5.x:x:DubboSpringCloud不支持該版本。33>Dubbo3.0前瞻之：重構(gòu)SpringCl由于DubboSpringCloud構(gòu)建在原生的SpringCloud之上，其服務(wù)治理方面的能力可認(rèn)為是SpringCloudPlus，不僅完全覆蓋SpringCloud原生特性，而且提供更為穩(wěn)定和成熟的實(shí)現(xiàn)，特性比對如下表所示：功能組件SpringCloudDubboSpringCloud分布式配置（Distributedconfiguration）Git、Zookeeper、Consul、JDBCSpringCloud分布式配置+Dubbo配置中心（Dubbo2.7開始支持配置中心，可自定義適配）。rviceregistrationanddiscovery）Eureka、Zookeeper、ConsulSpringCloud原生注冊中心（SpringCloud原生注冊中心，除Eureka、Zookeeper、Consul之外，還包括SpringCloudAlibaba中的Nacos）+Dubbo原生注冊中心。負(fù)載均衡（Loadbalancing）Ribbon（隨機(jī)、輪詢等算法）Dubbo內(nèi)建實(shí)現(xiàn)（隨機(jī)、輪詢等算法+權(quán)重等特性）。服務(wù)熔斷（CircuitBreakers）SpringCloudHystrixSpringCloudHystrix+AlibabaSentinel等（Sentinel已被SpringCloud項(xiàng)目納為CircuitBreaker的候選實(shí)現(xiàn)）。服務(wù)調(diào)用（Service-to-servicecalls）OpenFeign、RestTemplateSpringCloud服務(wù)調(diào)用+Dubbo@Reference。鏈路跟蹤（Tracing）SpringCloudSleuth+ZipkinZipkin、opentracing等。DubboSpringCloud基于SpringCloudCommons抽象實(shí)現(xiàn)Dubbo服務(wù)注冊與發(fā)現(xiàn)，應(yīng)用只需增添外部化配置屬性“dubbo.registry.address=spring-cloud://localhost”，就能輕松地橋接到所有原生SpringCloud注冊中心，包括：-Nacos-Eureka-Zookeeper-ConsulDubbo3.0前瞻之：重構(gòu)SpringCloud服務(wù)治理<34注：DubboSpringCloud將在下個(gè)版本支持SpringCloud注冊中心與Dubbo注冊中心并存，提供雙注冊機(jī)制，實(shí)現(xiàn)無縫遷移默認(rèn)情況，SpringCloudOpenFeign以及@LoadBalancedRestTemplate作為SpringCloud的兩種服務(wù)調(diào)用方式。DubboSpringCloud為其提供了第三種選擇，即Dubbo服務(wù)將作為SpringCloud服務(wù)調(diào)用的同等公民出現(xiàn)，應(yīng)用可通過ApacheDubbo注解@Service和@Reference暴露和引用Dubbo服務(wù)，實(shí)現(xiàn)服務(wù)間多種協(xié)議的通訊。同時(shí)，也可以利用Dubbo泛化接口輕松實(shí)現(xiàn)服務(wù)網(wǎng)關(guān)。DubboSpringCloud引入了全新的服務(wù)治理特性-服務(wù)自?。⊿erviceIntrospection其設(shè)計(jì)目的在于最大化減輕注冊中心負(fù)載，去Dubbo注冊元信息中心化。假設(shè)一個(gè)SpringCloud應(yīng)用引入DubboSpringBootStarter，并暴露N個(gè)Dubbo服務(wù)，以DubboNacos注冊中心為例，當(dāng)前應(yīng)用將注冊N+1個(gè)Nacos應(yīng)用，除SpringCloud應(yīng)用本身之前，其余N個(gè)應(yīng)用均來自于Dubbo服務(wù)，當(dāng)N越大時(shí)，注冊中心負(fù)載越重。因此，DubboSpringCloud應(yīng)用對注冊中心的負(fù)載相當(dāng)于傳統(tǒng)Dubbo的N分之一，在不增加基礎(chǔ)設(shè)施投入的前提下，理論上，使其集群規(guī)模擴(kuò)大N倍。當(dāng)然，未來的Dubbo也將提供服務(wù)自省的能力。盡管DubboSpringCloud完全地保留了原生SpringCloud服務(wù)調(diào)用特性，不過Dubbo服務(wù)治理的能力是SpringCloudOpenFeign所不及的，如高性能、高可用以及負(fù)載均衡穩(wěn)定性等方面。因此，建議開發(fā)人員將SpringCloudOpenFeign或者@LoadBalancedRestTemplate遷移為Dubbo服務(wù)?？紤]到遷移過程并非一蹴而就，因此，DubboSpringCloud提供了方案，即@DubboTransported注解。該注解能夠幫助服務(wù)消費(fèi)端的SpringCloudOpenFeign接35>Dubbo3.0前瞻之：重構(gòu)Spring口以及@LoadBalancedRestTemplateBean底層走Dubbo調(diào)用（可切換Dubbo支持的協(xié)議而服務(wù)提供方則只需在原有@RestController類上追加Dubbo@Servce注解（需要抽取接口）即可，換言之，在不調(diào)整Feign接口以及RestTemplateURL的前提下，實(shí)現(xiàn)無縫遷移。如果遷移時(shí)間充分的話，建議使用Dubbo服務(wù)重構(gòu)系統(tǒng)中的原生SpringCloud服務(wù)的定義。開發(fā)DubboSpringCloud應(yīng)用的方法與傳統(tǒng)Dubbo或SpringCloud應(yīng)用類似，按照以下步驟就能完整地實(shí)現(xiàn)Dubbo服務(wù)提供方和消費(fèi)方的應(yīng)用，完整的示例代碼請?jiān)L問一下資源：lDubbo服務(wù)提供方應(yīng)用lDubbo服務(wù)消費(fèi)方應(yīng)用Dubbo服務(wù)接口是服務(wù)提供方與消費(fèi)方的遠(yuǎn)程通訊契約，通常由普通的Java接口（interface）來聲明，如EchoService接口：publicpublicinterfaceEchoService{Stringecho(Stringmessage);}為了確保契約的一致性，推薦的做法是將Dubbo服務(wù)接口打包在第二方或者第三方的artifact（jar）中，如以上接口就存放在artifactspring-cloud-dubbo-sample-api之中。對于服務(wù)提供方而言，不僅通過依賴artifact的形式引入Dubbo服務(wù)接口，而且需要將其實(shí)現(xiàn)。對應(yīng)的服務(wù)消費(fèi)端，同樣地需要依賴該artifact，并以接口調(diào)用的方式執(zhí)行遠(yuǎn)程方法。接下來進(jìn)一步討論怎樣實(shí)現(xiàn)Dubbo服務(wù)提供方和消費(fèi)方。Dubbo3.0前瞻之：重構(gòu)SpringCloud初始化spring-cloud-dubbo-server-sampleMaven工程首先，創(chuàng)建artifactId名為spring-cloud-dubbo-server-sample的Maven工程，并在其pom.xml文件中增添DubboSpringCloud必要的依賴：<<dependencies><!--SampleAPI--><dependency><artifactId>spring-cloud-dubbo-sample-api</artifactId><version>${project.version}</version><!--SpringBootdependencies--><dependency><artifactId>spring-boot-actuator<!--DubboSpringCloudStarter--><dependency><artifactId>spring-cloud-starter-dubbo</artifactId><!--SpringCloudNacosServiceDiscovery--><dependency><artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>以上依賴artifact說明如下：lspring-cloud-dubbo-sample-api:提供EchoService接口的artifact。lspring-boot-actuator:SpringBootProduction-Readyartifact，間接引入spring-bootartifact。lspring-cloud-starter-dubbo:DubboSpringCloudStarterartifact，間接引入dubbo-spring-boot-starter等artifact。37>Dubbo3.0前瞻之：重構(gòu)Springlspring-cloud-starter-alibaba-nacos-discovery:NacosSpringCloud服務(wù)注冊與發(fā)現(xiàn)artifact。值得注意的是，以上artifact未指定版本(version)，因此，還需顯示地聲明<dependencyManagement>:<<dependencyManagement><dependencies><!--SpringCloudAlibabadependencies--><dependency><artifactId>spring-cloud-alibaba-dependencies</artifactId><version>2.2.1.RELEASE</version></dependencies></dependencyManagement>注：以上完整的Maven依賴配置，請參考spring-cloud-dubbo-server-samplepom.xml文件。完成以上步驟之后，下一步則是實(shí)現(xiàn)Dubbo服務(wù)。實(shí)現(xiàn)Dubbo服務(wù)EchoService作為暴露的Dubbo服務(wù)接口，服務(wù)提供方spring-cloud-dubbo-server-sample需要將其實(shí)現(xiàn)：@org.apache.dubbo.config.annotation.Service@org.apache.dubbo.config.annotation.ServiceclassEchoServiceImplimplementsEchoService{@OverridepublicStringecho(Stringmessage){return"[echo]Hello,}}Dubbo3.0前瞻之：重構(gòu)SpringCloud服務(wù)治理<38其中，@org.apache.dubbo.config.annotation.Service是Dubbo服務(wù)注解，僅聲明該Java服務(wù)（本地）實(shí)現(xiàn)為Dubbo服務(wù)。因此，下一步需要將其配置Dubbo服務(wù)（遠(yuǎn)程）。配置Dubbo服務(wù)提供方在暴露Dubbo服務(wù)方面，推薦開發(fā)人員外部化配置的方式，即指定Java服務(wù)實(shí)現(xiàn)類的掃描基準(zhǔn)包。注：DubboSpringCloud繼承了DubboSpringBoot的外部化配置特性，也可以通過標(biāo)注@DubboComponentScan來實(shí)現(xiàn)基準(zhǔn)