看一下“Dubbo 2.7”的三大新特性

Dubbo 2.7.x 作为 Apache 的孵化版本，除了代码优化之外，还新增了许多重磅的新特性，本文将会介绍其中最典型的三个新特性：

• 一、异步化改造
• 二、三大中心改造
• 三、服务治理增强

一、异步支持优化

我们知道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端异步

那么在2.7.x版本，由于JDK版本升级到了1.8，引入了JDK1.8 中的CompletableFuture接口，CompletableFuture支持 future 和 callback 两种调用方式。关于CompletableFuture怎么被运用到dubbo中我会在后续的文章介绍。引入该接口后，做了以下优化：

支持Provider端异步

支持直接定义返回CompletableFuture的服务接口。通过这种类型的接口，我们可以更自然的实现Consumer、Provider端的异步编程。

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

如果你不想将接口的返回值定义为Future类型，或者存在定义好的同步类型接口，则可以额外定义一个异步接口并提供Future类型的方法。

public interface GreetingsService { 
String sayHi(String name);
}
@AsyncFor(GreetingsService.class)
public interface GrettingServiceAsync extends GreetingsService { 
 CompletableFuture<String> 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;
 }
}

异步过滤器链回调。

二、三大中心改造

三大中心指的：注册中心，元数据中心，配置中心。

在 2.7 之前的版本，Dubbo 只配备了注册中心，主流使用的注册中心为 zookeeper。新增加了元数据中心和配置中心，自然是为了解决对应的痛点，下面我们来详细阐释三大中心改造的原因。

元数据改造

元数据是什么？元数据定义为描述数据的数据，在服务治理中，例如服务接口名，重试次数，版本号等等都可以理解为元数据。在 2.7 之前，元数据一股脑丢在了注册中心之中，这造成了一系列的问题：

推送量大 -> 存储数据量大 -> 网络传输量大 -> 延迟严重

生产者端注册 30+ 参数，有接近一半是不需要作为注册中心进行传递；消费者端注册 25+ 参数，只有个别需要传递给注册中心。有了以上的理论分析，Dubbo 2.7 进行了大刀阔斧的改动，只将真正属于服务治理的数据发布到注册中心之中，大大降低了注册中心的负荷。

同时，将全量的元数据发布到另外的组件中：元数据中心。元数据中心目前支持 redis（推荐），zookeeper。这也为 Dubbo 2.7 全新的 Dubbo Admin 做了准备，关于新版的 Dubbo Admin，我将会后续准备一篇独立的文章进行介绍。

示例：使用 zookeeper 作为元数据中心

<dubbo:metadata-report address="zookeeper://127.0.0.1:2181"/>

Dubbo 2.6 元数据

dubbo://30.5.120.185:20880/com.alibaba.dubbo.demo.DemoService?
anyhost=true&
application=demo-provider&
interface=com.alibaba.dubbo.demo.DemoService&
methods=sayHello&
bean.name=com.alibaba.dubbo.demo.DemoService&
dubbo=2.0.2&
executes=4500&
generic=false&
owner=kirito&
pid=84228&
retries=7&
side=provider&
timestamp=1552965771067

从本地的 zookeeper 中取出一条服务数据，通过解码之后，可以看出，的确有很多参数是不必要。

Dubbo 2.7 元数据

在 2.7 中，如果不进行额外的配置，zookeeper 中的数据格式仍然会和 Dubbo 2.6 保持一致，这主要是为了保证兼容性，让 Dubbo 2.6 的客户端可以调用 Dubbo 2.7 的服务端。如果整体迁移到 2.7，则可以为注册中心开启简化配置的参数：

<dubbo:registry address=“zookeeper://127.0.0.1:2181” simplified="true"/>

Dubbo 将会只上传那些必要的服务治理数据，一个简化过后的数据如下所示：

dubbo://30.5.120.185:20880/org.apache.dubbo.demo.api.DemoService?
application=demo-provider&
dubbo=2.0.2&
release=2.7.0&
timestamp=1552975501873

元数据中心的数据可以被用于服务测试，服务 MOCK 等功能。目前注册中心配置中 simplified 的默认值为 false，因为考虑到了迁移的兼容问题，在后续迭代中，默认值将会改为 true。

配置中心支持

衡量配置中心的必要性往往从三个角度出发：

1. 分布式配置统一管理
2. 动态变更推送
3. 安全性

Spring Cloud Config, Apollo, Nacos 等分布式配置中心组件都对上述功能有不同程度的支持。在 2.7 之前的版本中，在 zookeeper 中设置了部分节点：configurators，routers，用于管理部分配置和路由信息，它们可以理解为 Dubbo 配置中心的雏形。在 2.7 中，Dubbo 正式支持了配置中心，目前支持的几种注册中心 Zookeeper，Apollo，Nacos（2.7.1-release 支持）。

在 Dubbo 中，配置中心主要承担了两个作用

• 外部化配置。启动配置的集中式存储
• 服务治理。服务治理规则的存储与通知

示例：使用 Zookeeper 作为配置中心

<dubbo:config-center address="zookeeper://127.0.0.1:2181"/>

引入配置中心后，需要注意配置项的覆盖问题。

三、服务治理增强

如果我们把 Dubbo 当做一个服务治理框架，而不仅仅是一个 RPC 框架。在 2.7 中，Dubbo 对其服务治理能力进行了增强，增加了标签路由的能力，并抽象出了应用路由和服务路由的概念。在最后一个特性介绍中，着重对标签路由 TagRouter 进行探讨。

在服务治理中，路由层和负载均衡层的对比。区别 1，Router：m 选 n，LoadBalance：n 选 1；区别 2，路由往往是叠加使用的，负载均衡只能配置一种。

在很长的一段时间内，Dubbo 社区经常有人提的一个问题是：Dubbo 如何实现流量隔离和灰度发布，直到 2.7 提供了标签路由，用户可以使用这个功能，来实现上述的需求。

标签路由提供了这样一个能力，当调用链路为 A -> B -> C -> D 时，用户给请求打标，最典型的打标方式可以借助 attachment（他可以在分布式调用中传递下去），调用会优先请求那些匹配的服务端，如 A -> B，C -> D，由于集群中未部署 C 节点，则会降级到普通节点。

打标方式会收到集成系统差异的影响，从而导致很大的差异，所以 Dubbo 只提供了 RpcContext.getContext().setAttachment() 这样的基础接口，用户可以使用 SPI 扩展，或者 server filter 的扩展，对测试流量进行打标，引导进入隔离环境/灰度环境。新版的 Dubbo Admin 提供了标签路由的配置项，Dubbo 用户可以在自己系统的基础上对标签路由进行二次扩展，或者借鉴标签路由的设计，实现自己系统的流量隔离，灰度发布。