Dubbo学习总结（9）——Apache Dubbo Roadmap 2019

原文链接： https://mp.weixin.qq.com/s?__biz=MzU1NTMyOTI4Mw==&mid=2247493496&idx=2&sn=b746895ce8f0cc971ef254e5047b2ff3&chksm=fbd75514cca0dc0215e66ce5eb506c18ce5194234387fac69353f985ca1041f6159b504fb840&mpshare=1&scene=1&srcid=&sharer_sharetime=1567573047796&sharer_sh

导读：Apache Dubbo 是一款高性能、轻量级的开源 Java RPC 框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。自2011年开源以来，Dubbo 就是国人开发的最知名开源项目之一，也是我们实现分布式服务化和微服务架构的核心技术之一。本议题介绍 Dubbo 的发展历程、技术生态和2019年规划，分享微服务架构的一些实战经验，以及参与开源项目的心得体会。

  以下，ENJOY  

Dubbo 是一个分布式、高性能、透明化的 RPC 服务框架，提供服务自动注册、自动发现等高效服务治理方案。它是 Apache 第五个国人主导的顶级项目，到2019年5月初，Dubbo 在 Github 上有26683个星，处于领先的位置，今年5月，Apache 软件基金会宣布 Dubbo 正式毕业，成为 Apache 的顶级项目，Dubbo 从2017年7月开始重新维护到现在22个月以来，发布了17个版本，最大的变化是修复了之前积攒的 bug，同时加入了很多新特性，第三个变化是重新成立了技术社区，贡献者的数量从原先的41到现在的201，引入了200多个贡献者，Commiter 所在公司的数量从4家扩展到了18家，这些人代表了 Dubbo 社区的声音。

接下来介绍下 Dubbo Star 数的增长趋势，从图中可以看出 Dubbo 和其它的框架相比，自2017年7月阿里重启 Dubbo 开源，到目前为止 Github Star 数，Contributor 数都有了非常大的提升，Dubbo 增长速度很快，处于领先的位置，这主要是由于 Dubbo 整体的功能比较完善并且社区发展的比较红火。

接下来介绍下 Dubbo 的功能体系和生态体系。从功能体系来看目前微服务关注的点 Dubbo 基本都有涉及，图中蓝色的方块代表的是 Dubbo 重新维护之前就有的功能，绿色的方块代表的是 Dubbo 重新维护之后规划去做的，Dubbo 从它的核心的 Api，注册中心，集群的策略，再到它支持的协议和支持的序列化格式和传输，以及它的路由和负载均衡相关的策略都比较完善，之前是有一些功能，但是因为过了几年相比现在的流行的框架比较滞后，当时的设想就是把这些缺的功能给补全，甚至把阿里内部比较前沿的一些技术也融合进去，使 Dubbo 处于一种比较前沿的位置。

Dubbo 从一开始的定位就是一种典型的 RPC 的扩展，它不光支持各种 RPC 协议，比如两个系统之间的 RPC 通信你使用 Hessian 或者 Http 协议，同时你可以把这些对外暴露的服务注册到注册中心，指定协议调用时使用的序列化的格式，使用哪种格式的传输，如果有多台机器做集群，通过什么样的策略来选择哪些机器符合服务调用的条件，最终哪台机器会被负载均衡选中，来提供服务，这一整套的流程，Dubbo 提供了一个完备的框架，这些早在10年前就被设计 Dubbo 的程序员架构师考虑到，重新启动以后，我们将 Dubbo 和 Spring Boot 和 Spring Cloud 进行了深度的融合，把 Sping Cloud 里面一些极佳的特性和好的工具也会融合到 Dubbo 里，另外一个方面就是响应式编程，Dubbo 重启以后对之前支持的不好的异步化的 Api 进行重新梳理和设计，我们就可以使用异步化的 Api 来处理生产和消费的问题，同时在进一步的基础上我们积极拥抱了 RSocket，通过 RScocket 可以很自然地做到响应式的编程模型，性能高效，这会是3.0里比较大的一个特性，最后一个方面是 FluentApi，这个主要是考虑到易用性。Dubbo 在注册方面加了很多功能，拥抱 K8s，这是目前微服务鼓励原生做 Service Mesh 方面的基础设施去做的工作。集群方面，不仅支持常规方面的路由，也支持打 Tag 的方式，对集群内部的机器打标签来进行灰度，同时也支持柔性和反压的特性，集群的机器可以根据自身的负载能力动态做出反馈，实现流量权重的动态分配，集群会更具有弹性和柔性，在这个基础上，我们做了更多集群高可用和稳定性相关的工作。协议方面重启以后，除了支持 Rest 协议，同时也包含了 JsonRpc 协议，它可以看做是类似 WebSerivce 的 Rpc 调用，具有简单和跨平台的优点，RSocket  会在3.0，在序列化方面，加入了 FST，它比较精简，序列化以后的数据量减小到原来的1/10，还有一个配置协议，是谷歌2016年提出来的，底层基于 UDP，但是在 UDP 的基础上封装了可靠性和安全性，这个协议我们觉得未来有很大的发展趋势，这些是目前的扩展和当时规划的事情。

从图中可以看到，当时规划的事情，黑白框表示的是都已经完成的，剩下的是目正在做的， 以上是目前的一个时间点看到的 Dubbo 的一些功能组件。

接下来我们看一下 Dubbo 目前的一个生态，生态这方面最主要的讲的是 Dubbo 方面的多语言支持，Dubbo 和 Sping Cloud 原生的 Rest 协议相比，差异化在于大家一直认为 Dubbo 只支持 Java，而 Sping Cloud 基于 Rest 可以在不同的异构的系统里使用，所以 Dubbo 为了适配 Spring Cloud 的这个功能，为了后面更好的拥抱云原生，Service Mesh 这一层，做了多语言的接入，为了支持跨语言 Go，Js 主要是 Node Js，Python 等的接入，这些协议都可以通过代理或者 SideCar 的方式来进行接入调用 Dubbo 的服务，然后服务发现和其它的管理相对应的基础设施在整套的核心体系的外围提供基础的支持。

实际上今天为止，Js 和 Go 的已经比较完善了，各种外围的配套工具，像服务的发现和配置，新的管理控制平台，各种测试的支持和 Trace 跟踪是由 Spring Cloud 团队的的一个同事做的适配，这是 Dubbo 目前整体的一个生态，可以看出 Dubbo 在微服务里配套还是比较齐全的。其实对微服务来说最大的问题不是技术问题，因为技术的问题发展的已经很完善了，我们知道把一个系统引入微服务以后，拆成粒度比较小的系统有很多好处，比如每个系统的开发和维护成本会变低，因为系统变得简单了，但是更大的问题也出现了，比如说把一个很复杂的业务系统拆成20个小系统，这20个小系统都需要单独的做测试，部署，维护，当系统出了问题，需要对20个系统去排查问题，这些对自动化测试，自动化运维，全链路跟踪，监控做提出了非常高的要求，这就对整个研发团队的技术成熟度提出了一定要求，只有当测试，运维，业务方面的监控，自动化的 Trace 做的比较完善时，容器化的改造完成以后，再去做服务化会比较合理。微服务和单体在软件设计里面有两条曲线，叫成熟度的曲线，当你的团队规模很小的时候，单体的成本要比微服务的成本低很多，但是随着你的团队规模的增大，微服务的成本虽然起点很高，但是它的复杂度是比较平稳的，不会增加很多，比如你有50个开发人员和500个开发人员，你使用微服务的方式在保持业务的复杂度和质量的情况下是可以往前扩展的，但是单体的复杂度和成本会随着业务的复杂度逐渐递增，中间有个交叉点，这个交叉点和团队规模，业务复杂度和你的技术成熟度这几个选项有关系，超过这个交叉点就需要进行微服务改造，超不过这个点业也许单体是更好的选择。

再看一下整个 Dubbo 在2019年需要做哪些事情，在5月中旬 Apache 已经毕业了，6月份发布了2.6.7的版本，再往下基本上每个月发布一个版本，3.0的版本计划在2020年2月份推出，目前维护的主流的版本是2.7，现在 Dubbo 为了维护社群的生态，每个月会在一个城市举办技术沙龙。

Dubbo 2.7是维护的主流的版本，特别是新注册的机制和与 k8s 的配合都会在陆续的两个月推出来，同时计划在 Q3 的时候会进一步把 k8s 完善掉，把 Dubbo 的 Go 语言的版本发布出来，现在这一块很多公司已经在用，但是没有合并大 Dubbo 的主干分支上，还在单独的一个分支上，但是已经比较成熟，Q4 的时候主要去支持下 Service Mesh，包括在2020年的 Q1 的时候主要去拥抱下云原生和 Service Mesh 的浪潮。

Dubbo 3.0的路线图更加明确，一方面会继续拥抱云原生，同时会把响应式和异步化做好，把对 Rx 的支持做好， 同时我们一直在设想，做另外一件事情，响应式微服务这个概念非常火，我们知道微服务架构不管外部系统还是内部系统都走的 Rest，对外提供 Rest 是因为容易接入好管理，但是我们知道走 Rest，Http，Json 不是一种效率很高的调用方式，所以在内部应该会有更易用，更高效的方式去管理，去调用，所以这个是现在提响应式微服务架构在思考和尝试的事情。比如说我们也尝试另外一套技术栈，叫 Vert.X，Vert.X 对外提供 Rest 服务，它对外提供 Rest 调用，内部是一种 EventBus，内部所有的节点通讯是不走 RPC 调用的，类似 actor 模型，一个节点可以直接通过地址向另一个节点发消息，只要在内部一个大的集群内，这样一种方式要远远比走 RPC 调用更高效，而且这种异步的处理方式可以使系统不管存储量还是延迟降低很多，这是后面我们需要考虑的重点因素，好多的东西都会围绕这个来做。

最后两块我们看下整个的部署模式的改造，一块是和 Spring Cloud 结合，另一块是和 Service Mesh 相结合，从当前的部署模式可以看到，Dubbo 的 Client 和 Server 分别去注册和订阅它的注册中心，然后调用的时候通过一个代理和 Dubbo 的 Server 去通讯，然后非 Dubbo 的情况下，会不走 Dubbo 的注册和发现机制，但是一样是可以调用的，希望在未来可以和 Sping Cloud 的技术栈打通，所有的调用都是直连的。

另外一个方面主要是与 Service Mesh 的结合，主要是利用 K8s 的基础的元数据的管理能力和服务发现能力，所有的 Service Mesh 其实就是，不管是使用 Dubbo 还是 Spring Cloud 就会发现我们在我们的程序中会有很多控制路由，控制我们网络流量的流控，比如做我们线程调用的管控和调用速度的管控，和系统 load 负载的管控，这些和业务都没有关系，我们用的中间件可以把这些从业务复杂度中抽离出来，下沉，但是现在负责业务处理的和负责策略处理的在一个进程里，Servie Mesh 的想法是把这些策略的东西向下沉，沉到更下一部的基础设施层，就跟我们业务本身的进程没有关系，业务的进程只需要处理业务本身就可以了，这样的话，下面处理这些策略限流，流控管理，跟踪，服务发现，元数据，把这些东西抽象出来，就是 Service Mesh ，它贯穿在提供服务能力的各个节点上，相互之间可以通讯，这样的话就组成网格，所以就叫做 Mesh，如果 Service Mesh 的东西发展的非常好，我们微服务业务层就会做的很薄，开发人员只需要专注于自己的业务，提供自己的服务，消费自己的服务，而不用关心自己的服务在哪里，下沉的 Mesh 层都帮忙给处理掉了。

最后是 Dubbo 在 ISTIO 上的部署，除了部署在 K8s 上，还可以部署在 ISTIO 上，其实都是类似的方式，这些都是 Dubbo 未来要做的事情。