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

目標：了解2.7的新特性，以及版本升級的引導。

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

從上圖就可以看出dubbo現在的活躍度。

現在dubbo項目有以下幾個分支：

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

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

2.7.1-release：一個臨時分支。

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

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

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

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

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

我們知道dubbo協議本身支持三種發送請求方式：

單向發送：執行方法不需要返回結果

同步發送：執行方法后，等待結果返回，否則一直阻塞.

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

future：當請求有響應后，通過future.get()來獲得響應結果，但是future.get()會導致線程阻塞，future從RpcContext獲取。

callback：設置一個回調線程，當接收到響應時，自動執行，不會對當前線程造成阻塞，自定義ResponseFuture支持callback。

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

Future獲取方式不夠直接，只能在RpcContext中進行獲取；

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

Future接口無法實現自動回調，而自定義ResponseFuture雖支持callback回調但支持的異步場景有限，如不支持Future間的相互協調或組合等；

不支持Provider端異步

具體的可以參考該文章dubbo源碼解析（二十四）遠程調用——dubbo協議中的源碼分析來理解其中存在的問題。

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

支持Provider端異步

支持直接定義返回CompletableFuture的服務接口。通過這種類型的接口，我們可以更自然的實現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;
    }
}

異步過濾器鏈回調。

具體的實現原理我在后續文章中結合源碼來講解，注意：這些改動都僅僅支持dubbo協議。

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

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

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

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

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

元數據信息：接口的完整定義，包含接口名，接口所含的方法，以及方法所含的出入參信息。對于服務測試和服務mock有很重要作用。

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

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

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

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

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

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

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

路由規則存儲在注冊中心

只支持服務粒度的路由，應用級別無法定義路由規則

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

一個服務或應用允許定義多條路由規則，服務治理無法管控

實現上，每條規則生成一個Router實例并動態加載

在2.7.x版本中，對路由規則做了增強：

豐富的路由規則。

條件路由：支持應用程序級別和服務級別條件。

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

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

應用程序級動態配置支持。

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

配置中心（v2.7.0）在Dubbo中承擔兩個職責：

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

服務治理：服務治理規則的存儲與通知。

配置的操作可以查看官方文檔，由于現在dubbo支持多種配置方式，所以這里需要強調的是配置覆蓋的優先級，從上至下優先級依此降低：

新增了Protobuf序列化支持。

其他的bug修復以及一些小細節優化請查看github上的Issues或者PR。

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

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