摘要

框架的发展可以推动业务更高速地发展，业务的高速发展很快又会遇到众多新的问题，从而对框架提出新的要求。因此，我们可以从现在互联网业务的趋势来得知未来技术的趋势。

首先是业务规模的不断扩大，未来技术的必然趋势是单体应用向微服务的转化，为了方便各种不同语言开发的单体应用，能方便地迁移到分布式应用，Dubbo肯定会支持多语言。Dubbo也会变得更加轻量化，降低框架对业务应用的体积影响。其次，Spring Boot系列无疑是现在Java应用开发的首选，为了符合主流开发习惯，Dubbo还会支持REST及Spring Boot的集成。再次，企业为了进一步降低开发、运维的成本，软件上云会成为趋势。因此Dubbo也会在后续进一步适配Cloud Native, Dubbo Mesh也在探索当中。然后，Dubbo现在在服务化治理方面存在一定的短板，完善服务化治理整体方案，建立Dubbo的生态也会是今后的趋势。最后，高性能是一个框架的立身之本，性能的提升在任何时候都会是关注点，后续Dubbo会不断完善在大规模集群、大流量场景的性能表现，并建立异步编程、benchmark等机制。

Dubbo——未来的展望_模块化

Dubbo 2.7.x 新特性

JDK8特性的引入及repackag

JDK8新特性的使用。JDK8己经逐渐成为主流使用的JDK, Dubbo 2.7.x中已经全面拥抱。JDK8的各种特性。例如：框架接口中直接使用了 default method,不需要先使用一个抽象类来定义默认方法了；使用了 CompletableFuture, Future执行结束后直接触发回调，不需要再做同步等待；还有Optional、Lambda表达式、function等JDK8的各种新特性。

异步化的支持

2.7. x版本中通过引AJDK8的新特性解决了上述问题，并提供了直接接口定义和注解两种方式。

//通过接口直接定义 CompletableFuture
public interface AsyncService { 
    CompletableFuture<String> sayHello(String name);
)

//使用@AsyncFor 注解
@AsyncFor(GreetingsService.class) 
public interface GrettingServiceAsync extends GreetingsService (
    CompletableFuture<String> sayHiAsync(String name);
)

元数据的管理

首先，现有Dubbo注册的元数据数据量很大，服务提供者端注册的参数有30多个，但接近一半是不需要通过注册中心传递的；消费者端注册的参数有20多个，只有个别需要传递给注册中心。其次，由于数据量大，有数据更新时，推送量也会相应增大。然后，Dubbo现在服务信息的更新会把某个接口下的所有服务提供者信息全量拉过来，如果集群规模较大，则整个网络传输量会瞬间激增，让整个网络的延迟增大。最后，Dubbo-OPS有新的需求，其服务测试也需要使用元数据。

基于以上的问，2.7.x版本对注册信息进行了简化，减少了注册中心的数据量；etcd注册中心的实现可以完成增量更新的特性。额外的元数据会写入Redis等第三方存储中间件，以此降低注册中心的压力，提升总体服务的性能。新旧元数据管理对比如图13.1所示。

Dubbo——未来的展望_新特性_02

动态配置的管理

Dubbo现阶段的配置基本都是静态的，缺少动态配置的手段，也容易造成不同节点的配置不同的问题。例如：Dubbo配置通常都是写在本地配置文件中的，缺少像Spring Cloud Config 一样的远程配置托管的模式；服务治理平台只有服务级别的配置，SPI等也是预先写好在配置文件中的，不能动态添加、修改。

在2.7.x版本中，Dubbo新增了动态配置中心，实现类似Spring Cloud Config 一样的远程配置方式，配置优先级如图13.2所示。

Dubbo——未来的展望_元数据_03

从图13.2知道，优先级最高的是通过启动参数进行配置的，其次是通过XML或API的方式配置的，然后是本地dubbo.propertis配置文件，最后就是新增的远程配置中心。

新的动态配置中心支持配置的动态覆盖与新增，并且还支持应用级别和服务级别的配置，兼容override配置。此外，2.7.x版本中定义了新的SPI接口，开发者可以基于该接口自定义动
态配置中心，默认支持Apollo> Nacos> ZooKeeper作为配置中心。

综合上面几个特性，我们可以得知，Dubbo从原来一个注册中心，分离出来了注册、配置、元数据三个中心，减轻了老注册中心数据容量、扩展困难的问题。

Dubbo——未来的展望_新特性_04

路由规则的管理

路由规则在2.6.x版本中支持的力度不够，只支持服务粒度的路由；支持的方式也不足，如不支持tag类型的路由规则；路由规则还存储在注册中心，造成注册中心的臃肿；一个服务允许设置多条路由规则，导致路由结果非常复杂、难以排查，等等。

在2.7.x版本中，对路由规则进行了增强，支持应用级别的路由，也支持tag类型的路由规则；路由规则的存储已经随着三个中心的确立，从注册中心转移到配置中心；每个服务都能对应精确的路由规则等。

Dubbo核心能力规划

Dubbo核心能力主要会向六个方向发展：模块化、元数据、路由策略、大流量、大规模和异步化。

模块化

Dubbo现在的通信层与服务治理层的耦合比较严重，如Cluster层中的路由规则、软负载均衡等，都耦合在框架中，而集群容错层完全可以下沉到sidecar中，框架里只保留PRC通信。因此，在后续规划中，会让Dubbo更加模块化，使得框架各个层次的能力更加内聚，方便后续的拆分，也为Dubbo Mesh做好准备。

元数据

在2.6.x版本中，Dubbo注册中心里包含注册数据、元数据和配置数据。元数据也过于冗长，注册中心过于臃肿，水平扩展能力受限。因此在核心能力规划时，会把现有的注册中心拆分为三个中心：注册中心、元数据中心和配置中心。这一规划己经在2.7.x版本中大致实现。

路由策略

随着互联网业务的不断发展，同城多机房、异地多机房等巳经比较常见，服务的数量级也不断上升。Dubbo后续会引入在阿里内部实践广泛的路由策略：多机房、灰度、参数路由等智能化策略，以此来增强现有的路由模块。

大规模

业务的发展随之带来服务数量级的不断上升，在超大规模的服务集群中，服务的注册发现、内存占用、海量服务选址对CPU消耗等有很大的挑战。因此，后续Dubbo会对大规模服务集群的各种场景进行针对性的优化。

大流量

在大规模集群的同时，也会带来大流量的问题。现在的Dubbo框架还没有完善的熔断、隔离等机制来提升整个集群的总体稳定性。当集群出现问题时，定位故障节点也相对困难。Dubbo在后续的规划中会补齐这些短板。

异步化

2.6.x版本的Dubbo框架还未支持CompletableFuture,也没有跨进程的Reactive支持。虽然在2.7.x版本中已经支持了 CompletableFuture,但Reactive还未支持。因此在后续的规划中，会通过这些异步化的方式来提升分布式系统整体的吞吐量和CPU利用率。

博文参考

深入理解Apache Dubbo与实战.pdf