摘要：大揭秘目標(biāo)了解的新特性，以及版本升級的引導(dǎo)。四元數(shù)據(jù)改造我們知道以前的版本只有注冊中心，注冊中心的有數(shù)十個的鍵值對，包含了一個服務(wù)所有的元數(shù)據(jù)。

目標(biāo)：了解2.7的新特性，以及版本升級的引導(dǎo)。

我們知道Dubbo在2011年開源，停止更新了一段時間。在2017 年 9 月 7 日，Dubbo 悄悄的在 GitHub 發(fā)布了 2.5.4 版本。隨后，版本發(fā)布的非常迅速，Dubbo項(xiàng)目被重啟了，經(jīng)過大半年的更新，在2018年2月15日，Dubbo 獲得了 14 張贊成票，在無棄權(quán)和反對票的情況下，正式通過投票，順利成為 Apache 基金會孵化項(xiàng)目?，F(xiàn)在的Dubbo社區(qū)非常活躍，版本進(jìn)度也非常的快。

從上圖就可以看出dubbo現(xiàn)在的活躍度。

現(xiàn)在dubbo項(xiàng)目有以下幾個分支：

2.5.x：該分支在近期投票決定不再維護(hù)。

2.6.x：該分支現(xiàn)在還在維護(hù)中，包名前綴是com.alibaba，也是貢獻(xiàn)給 Apache 之前的版本。

2.7.1-release：一個臨時分支。

3.x-dev：將以 Streaming 為內(nèi)核，重點(diǎn)的改變在服務(wù)治理和編程模型上。具體我也還沒有深入研究，我也會跟蹤該分支的變動，敬請期待吧。

master：目前版本是2.7.x，包名前綴是：org.apache，也是 Dubbo 貢獻(xiàn)給 Apache 的開發(fā)版本，接下來的分析也會在2.7.1上進(jìn)行分析。

關(guān)注dubbo社區(qū)的朋友應(yīng)該也知道在2019.3.23在南京舉辦了Meetup，其中有一個專題就是講2.7新特性介紹。我就在分享者的基礎(chǔ)上講解一下自己的理解。

在所需的最小JDK版本從以前的1.6變成了1.8。

com.alibaba.dubbo - > org.apache.dubbo

我們知道dubbo協(xié)議本身支持三種發(fā)送請求方式：

單向發(fā)送：執(zhí)行方法不需要返回結(jié)果

同步發(fā)送：執(zhí)行方法后，等待結(jié)果返回，否則一直阻塞.

異步發(fā)送：也就是當(dāng)我發(fā)送調(diào)用后，我不阻塞等待結(jié)果，直接返回，將返回的future保存到上下文，方便后期使用。在異步發(fā)送中有兩種方式分別是

future：當(dāng)請求有響應(yīng)后，通過future.get()來獲得響應(yīng)結(jié)果，但是future.get()會導(dǎo)致線程阻塞，future從RpcContext獲取。

callback：設(shè)置一個回調(diào)線程，當(dāng)接收到響應(yīng)時，自動執(zhí)行，不會對當(dāng)前線程造成阻塞，自定義ResponseFuture支持callback。

2.6.x版本的異步方式提供了一些異步能力，包括Consumer端異步調(diào)用、參數(shù)回調(diào)、事件通知等。但當(dāng)前的異步方式存在以下問題：

Future獲取方式不夠直接，只能在RpcContext中進(jìn)行獲?。?/p>

Future只支持阻塞式的get()接口獲取結(jié)果。

Future接口無法實(shí)現(xiàn)自動回調(diào)，而自定義ResponseFuture雖支持callback回調(diào)但支持的異步場景有限，如不支持Future間的相互協(xié)調(diào)或組合等；

不支持Provider端異步

具體的可以參考該文章dubbo源碼解析（二十四）遠(yuǎn)程調(diào)用——dubbo協(xié)議中的源碼分析來理解其中存在的問題。

那么在2.7.x版本，由于JDK版本升級到了1.8，引入了JDK1.8 中的CompletableFuture接口，CompletableFuture支持 future 和 callback 兩種調(diào)用方式。關(guān)于CompletableFuture怎么被運(yùn)用到dubbo中我會在后續(xù)的文章介紹。引入該接口后，做了以下優(yōu)化：

支持Provider端異步

支持直接定義返回CompletableFuture的服務(wù)接口。通過這種類型的接口，我們可以更自然的實(shí)現(xiàn)Consumer、Provider端的異步編程。

public interface AsyncService {
    CompletableFuture sayHello(String name);
}

如果你不想將接口的返回值定義為Future類型，或者存在定義好的同步類型接口，則可以額外定義一個異步接口并提供Future類型的方法。

public interface GreetingsService {
    String sayHi(String name);
}

@AsyncFor(GreetingsService.class)
public interface GrettingServiceAsync extends GreetingsService {
    CompletableFuture sayHiAsync(String name);
}

如果你的原始接口定義不是Future類型的返回值，Provider端異步也提供了類似Servlet3.0里的Async Servlet的編程接口: RpcContext.startAsync()

public interface AsyncService {
    String sayHello(String name);
}

public class AsyncServiceImpl implements AsyncService {
    public String sayHello(String name) {
        final AsyncContext asyncContext = RpcContext.startAsync();
        new Thread(() -> {
            asyncContext.write("Hello " + name + ", response from provider.");
        }).start();
        return null;
    }
}

異步過濾器鏈回調(diào)。

具體的實(shí)現(xiàn)原理我在后續(xù)文章中結(jié)合源碼來講解，注意：這些改動都僅僅支持dubbo協(xié)議。

我們知道2.7以前的版本只有注冊中心，注冊中心的URL有數(shù)十個key/value的鍵值對，包含了一個服務(wù)所有的元數(shù)據(jù)。在越來越多的功能被增加，元數(shù)據(jù)也變得異常龐大，就出現(xiàn)了下面的問題：

注冊中心存儲的URL過長：這會導(dǎo)致存儲的壓力驟增，數(shù)據(jù)龐大導(dǎo)致在修改元數(shù)據(jù)后的通知效率也下降，并且增加了消費(fèi)者對于元數(shù)據(jù)解析的壓力，尤其是在大規(guī)模場景下的內(nèi)存增長顯著

注冊中心承擔(dān)了過多的服務(wù)治理配置的功能：初始配置的同步、存儲各種運(yùn)行期配置規(guī)則加劇了注冊中心的壓力，配置規(guī)則的靈活性也有所限制，阻礙了市場上的一些優(yōu)秀微服務(wù)配置中心的集成和擴(kuò)展。

屬性的功能定位不清晰：methods，pid，owner雖然是為了查詢服務(wù)而注冊的屬性，但是這些簡陋的信息很難滿足查詢服務(wù)治理需求，所以需要更加豐富的注冊數(shù)據(jù)。例如methods，雖然方法列表的內(nèi)容已經(jīng)很長，但是在ops開發(fā)服務(wù)測試/mock功能時，發(fā)現(xiàn)需要的方法簽名等數(shù)據(jù)還是無法獲取。

針對以上問題，在2.7中，將URL中的元數(shù)據(jù)劃分了三個部分：

元數(shù)據(jù)信息：接口的完整定義，包含接口名，接口所含的方法，以及方法所含的出入?yún)⑿畔ⅰτ诜?wù)測試和服務(wù)mock有很重要作用。

執(zhí)行鏈路上數(shù)據(jù)：需要將參數(shù)從provider端傳遞給consume端，讓consume端感知的到，比如token、timeout等

服務(wù)自己持有的配置&Ops需求：只有provider端自己需要或者consume端自己需要的數(shù)據(jù)，比如executes、document等

改造后，分別形成三大中心：

注冊中心：理想情況下，注冊中心將只用于關(guān)鍵服務(wù)信息（核心鏈路）的同步，進(jìn)一步減輕注冊中心的存儲壓力，提高地址同步效率，同時緩解當(dāng)前由于URL冗余在大規(guī)模推送時造成的Consumer端內(nèi)存計(jì)算壓力。

配置中心：解決當(dāng)前配置和地址信息耦合的問題，通過抽象動態(tài)配置層，讓開發(fā)者可以對接微服務(wù)場景下更常用的、更專業(yè)的配置中心，如Nacos, Apollo, Consul, Etcd等；提供更靈活的、更豐富的配置規(guī)則，包括服務(wù)、應(yīng)用不同粒度的配置，更豐富的路由規(guī)則，集中式管理的動態(tài)參數(shù)規(guī)則等

服務(wù)查詢治理中心：對于純粹的服務(wù)查詢相關(guān)的數(shù)據(jù)，包括Consumer的服務(wù)訂閱數(shù)據(jù)，往往都是注冊后不可變的并且不需要節(jié)點(diǎn)間的同步，如當(dāng)前URL可以看到的methods、owner等key以及所有的Consumer端URL，目前支持 redis（推薦），zookeeper,將作為Dubbo-Admin支持的服務(wù)測試，模擬和其他服務(wù)治理功能的基礎(chǔ)。

Dubbo 提供了具有一定擴(kuò)展性的路由規(guī)則，其中具有代表性的是條件路由和腳本路由。2.6.x及以下版本存在的問題：

路由規(guī)則存儲在注冊中心

只支持服務(wù)粒度的路由，應(yīng)用級別無法定義路由規(guī)則

支持路由緩存，但基本不具有擴(kuò)展性

一個服務(wù)或應(yīng)用允許定義多條路由規(guī)則，服務(wù)治理無法管控

實(shí)現(xiàn)上，每條規(guī)則生成一個Router實(shí)例并動態(tài)加載

在2.7.x版本中，對路由規(guī)則做了增強(qiáng)：

豐富的路由規(guī)則。

條件路由：支持應(yīng)用程序級別和服務(wù)級別條件。

標(biāo)記路由：新引入以更好地支持流量隔離，例如灰色部署

將治理規(guī)則與注冊表分離，也就是出現(xiàn)了配置中心，使配置中心更容易擴(kuò)展。有Apollo和Zookeeper，2.7.1還支持了consul和etcd。

應(yīng)用程序級動態(tài)配置支持。

使用YAML作為配置語言，更易于閱讀和使用

配置中心（v2.7.0）在Dubbo中承擔(dān)兩個職責(zé)：

外部化配置：啟動配置的集中式存儲 （簡單理解為dubbo.properties的外部化存儲）外部化配置目的之一是實(shí)現(xiàn)配置的集中式管理，這部分業(yè)界已經(jīng)有很多成熟的專業(yè)配置系統(tǒng)如Apollo, Nacos等，Dubbo所做的主要是保證能配合這些系統(tǒng)正常工作。外部化配置和其他本地配置在內(nèi)容和格式上并無區(qū)別，可以簡單理解為dubbo.properties的外部化存儲，配置中心更適合將一些公共配置如注冊中心、元數(shù)據(jù)中心配置等抽取以便做集中管理

服務(wù)治理：服務(wù)治理規(guī)則的存儲與通知。

配置的操作可以查看官方文檔，由于現(xiàn)在dubbo支持多種配置方式，所以這里需要強(qiáng)調(diào)的是配置覆蓋的優(yōu)先級，從上至下優(yōu)先級依此降低：

新增了Protobuf序列化支持。

其他的bug修復(fù)以及一些小細(xì)節(jié)優(yōu)化請查看github上的Issues或者PR。

升級2.7.0的引導(dǎo)請查看以下鏈接:http://dubbo.apache.org/zh-cn...

該文章講解了dubbo2.7的新特性，現(xiàn)在2.7.1已經(jīng)發(fā)布，有興趣的可以去看看2.7.1新增了什么。下一篇我就先從源碼的角度來講講這個異步化的改造。