阿里Dubbo疯狂更新，关Spring Cloud什么事？

原文出处，在 Spring For All 社区（http://spring4all.com ）: http://www.spring4all.com/article/213

最近，开源社区发生了一件大事，那个全国 Java 开发者使用最广的开源服务框架 Dubbo 低调重启维护，而且 3 个月连续发布了 4 个维护版本。

我上次在写放弃Dubbo，选择最流行的Spring Cloud微服务架构实践与经验总结这篇文章的时候，就有不少的网友给我留言说，Dubbo 又开始更新了。我固然是清楚的，我也一直在关注着 Dubbo 的走向，在几个月前技术圈里面就有一个消息说是 Dubbo 又开始更新了，你们议论纷纷不知真伪。我还专门跑到 GitHub 上面进行了留言询问，最后在 Dubbo 的 gitter 聊天室里面找到了确信的答案，说是正在组建团队。虽然稍稍有所期待，但也不知道阿里此次拿出了多少的诚意来作这件事，因而我昨天又到 GitHub 逛了一下，发现从 9 月开始，阿里三个月连着发布了四个版本，仍是很是有诚意的，值得关注。

Dubbo简介

Dubbo 是阿里巴巴公司一个开源的高性能服务框架，致力于提供高性能和透明化的 RPC 远程服务调用方案，以及 SOA 服务治理方案，使得应用可经过高性能 RPC 实现服务的输出、输入功能和 Spring 框架无缝集成。Dubbo 包含远程通信、集群容错和自动发现三个核心部分。

它提供透明化的远程方法调用，实现像调用本地方法同样调用远程方法，只需简单配置，没有任何 API 侵入。同时它具有软负载均衡及容错机制，可在内网替代 F5 等硬件负载均衡器，下降成本，减小单点。它能够实现服务自动注册与发现，再也不须要写死服务提供方地址，注册中心基于接口名查询服务提供者的 IP 地址，而且可以平滑添加或删除服务提供者。

2011 年底，阿里巴巴在 GitHub 上开源了基于 Java 的分布式服务治理框架 Dubbo，以后它成为了国内该类开源项目的佼佼者，许多开发者对其表示青睐。同时，前后有很多公司在实践中基于 Dubbo 进行分布式系统架构。目前在 GitHub 上，它的 fork、star 数均已破万。

Dubbo核心功能:

• 远程通信，提供对多种基于长链接的 NIO 框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。
• 集群容错，提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。
• 自动发现，基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方能够平滑增长或减小机器。

Dubbo发展史

发展到开源

2008 年末在阿里内部开始规划调用，2009 年初开发 1.0 版本；2010 年 04 月在 1.0 的版本之上进行了重构，发布了 2.0 版本；2011 年 10 月阿里宣布将 Dubbo 开源，开源的第一个版本为版本 dubbo-2.0.7。

开源成长

Dubbo 开源以后，框架发展比较迅速，几乎两三个月会发布一个版本，于 2012 年 3 月 14 号发布版本 dubbo-2.1.0。随后又进入另外一个快速发展期，版本发布频繁，几乎每个月会发布好几回。直到 2013 年 3 月 17 号发布了 dubbo-2.4.10，版本陷入停滞；2014 年 10 月 30 号发布版本 dubbo-2.4.11，修复了一个小 Bug，版本又陷入漫长的停滞到如今。

阿里以外的发展

2014 年的 10 月 20 号，当当网 Fork 了阿里的一个 Dubbo 版本开始维护，并命名为 dubbox-2.8.0。值得注意的是，当当网扩展 Dubbo 服务框架支持 REST 风格远程调用，而且跟随着 ZooKeepe 和 Spring 升级了对应的版本。以后 Dubbox 一直在小版本维护，2015 年 3 月 31 号发布了最后一个版本 dubbox-2.8.4。

Dubbo团队这三个月都作了什么

目前 Dubbo 的主力开发以阿里巴巴中间件团队为主，同时在阿里内部也招募了一些对 Dubbo 感兴趣的同事。你们要知道，Dubbo 距离今年开始维护的上一个版本是什么时间发布的吗？是 2014 年 10 月 30 号，差了整整将近 3 年，Dubbo 所依赖的 Jdk、Spring、Zookeeper、Zkclient 等等不知道都更新了多少个版本。所以阿里恢复更新的第一步就是适配所依赖的各组件版本，让 Dubbo 所依赖的基础环境不要太落伍，另外也 Fixed 掉了一些严重的 Bug。

dubbo-2.5.4/5版本

2017 年 9 月，阿里发布了 dubbo-2.5.4/5 版本，更新内容以下：

依赖升级

依赖	当前版本	目标版本	影响点
spring	3.2.16.RELEASE	4.3.10.RELEASE	schema配置解析；Http RPC协议
zookeeper	3.3.3	3.4.9	经常使用注册中心
zkclient	0.1 0.10	zookeeper	客户端工具
curator	1.1.16	2.12.0	zookeeper客户端工具
commons-logging	1.1.1	1.2	日志实现集成
hessian	4.0.6	4.0.38	hessian RPC协议
jedis	2.1.0	2.9.0	redis注册中心；缓存RPC
httpclient	4.1.2	4.5.3	hessian等用http链接池
validator	1.0.0	1.1.0.Final	java validation规范
cxf	2.6.1	3.0.14	webservice
jcache	0.4	1.0.0	jcache规范

这版在升级相关依赖版本的同时，以问题反馈频率和影响面排定优先级，优先解决了几个反馈最多、影响较大的一些缺陷，包括优雅停机、异步调用、动态配置、MonitorFilter 监控统计等问题。

dubbo-2.5.6版本

2017 年 10 月，阿里发布了 dubbo-2.5.6 版本，又 Fixed 掉了一大批严重的 Bug。

发布内容

• 泛化调用PojoUtils工具类不能正确处理枚举类型、私有字段等问题
• provider业务线程池满后，拒绝请求的异常没法通知到consumer端
• 业务返回值payload超阈值时，payload被重复发送回consumer
• slf4jLogger正确输出log调用实际所在行号
• 延迟(delay)暴露存在潜在并发问题，致使不一样服务占用多个端口
• 无provider时，consumer端mock逻辑不能生效
• 一些小优化：OverrideListener监听逻辑、provider端关闭心跳请求、Main启动类停机逻辑等
• 一些小bug修复：动态配置不能删除、telnet支持泛型json调用、monitor统计错误等

dubbo-2.5.7版本

2017 年 11 月，也就是 12 天前，阿里发布了 dubbo-2.5.7。此次不但修复了一批主要的 Bug，还作了一处小功能的完善。

发布内容

• 完善注解配置方式，修复社区反馈的旧版注解bug
• 支持启动时从环境变量读取注册ip port、绑定ip port，支持社区反馈的容器化部署场景等
• 调整、开放一些不完善的xml配置项，如dump.directory等
• 解决启动阶段zk没法链接致使应用无限阻塞的问题
• 解决zk没法链接时，MonitorService初次访问会致使rpc请求阻塞问题 #672
• 内部json实现标记deprecate，转为依赖开源fastjson实现
• RMI协议支持传递attachments
• Hessian支持EnumSet类型序列化
• 社区反馈的一些小bug修复及优化

此次版本发布内容较多，所以还给出了升级建议。

升级请注意

• 这次升级存在如下不兼容或须要注意点，但对核心功能均无影响，且只需添加依赖或遵照配置规则便可避免。这里只是把潜在的注意点列出来，若是你没用到这些功能无需额外关注。
• AccesslogFilter、telnet、mock等部分功能依赖了老版JSON实现，如开启以上功能，升级后请添加fastjson做为第三方依赖。
• 这次升级完善了注解配置方式，同时保留了老的注解配置代码，如工程从以前的老版本注解配置转到2.5.7版本，请确保删除老的注解扫描配置，使用新的配置形式。
• 在工程启动阶段，如遇到zk不可达，当前版本的行为是使用注册中心缓存继续启动（具体由check参数决定。 MonitorService初次调用，如遇zk不可达，当前版本会忽略monitor数据上传，以免阻塞rpc主流程。

重点

在 2.5.7 版本更新的同时还给出了下一步的预告，近期即将提供 dubbo-spring-boot-starter 启动配置模块。

这个提示说明了两个事情：

• Dubbo 还会继续完善，后续会开发不少的新的功能，因此但愿你们关注。
• 说明 Spring Boot 的影响力也愈来愈大，各类牛逼的开源软件纷纷给出了支持，如今也将包括 Dubbo。

Dubbo 下一步会作什么？

根据阿里技术的信息，最近三个版本会作的事情以下：

• 优先解决社区使用过程当中的问题和框架的缺陷，吸取社区贡献的新特性，解决文档访问和不全面的问题。
• 提供服务延迟暴乱、优雅停机 API 接口支持 RESTFULE 风格服务调用，提供 netty http 的支持，集成高性能序列化协议。
• 路由功能优化、消费端异步功能优化、提供端异步调用支持注册中心推送通知异步、合并处理改造等。

将来计划：

重构动态配置模块，动态配置和注册中心分离，集成流行的开源分布式配置管理框架，服务元数据注册与注册中心分离，丰富元数据内容，适配流行的 consul etcd 等注册中心方案。考虑提供 opentrace、oauth二、metrics、health、gateway 等部分服务化基础组件的支持，服务治理平台 OPS 重作，除代码、UI 重构外，指望能提供更强的服务测试、健康检查、服务动态治理等特性。Dubbo 模块化，各个模块可单独打包、单独依赖，集群熔断和自动故障检测能力。

继续在 Dubbo 框架现代化、国际化这两个大的方向上进行探索。现代化方面主要是考虑到目前微服务架构以及容器化日渐流行的大趋势，Dubbo 做为 RPC 框架如何很好地融入其中，成为其生态体系中不可或缺的一个组件。**强调的是 Dubbo 将来的定位并非要成为一个微服务的全面解决方案，而是专一在 RPC 领域，成为微服务生态体系中的一个重要组件。**至于你们关注的微服务化衍生出的服务治理需求， Dubbo 将积极适配开源解决方案，甚至启动独立的开源项目予以支持。

Dubbo和Spring Cloud有何不一样？

首先作一个简单的功能对比：

	Dubbo	Spring Cloud
服务注册中心	Zookeeper	Spring Cloud Netflix Eureka
服务调用方式	RPC	REST API
服务监控	Dubbo-monitor	Spring Boot Admin
断路器	不完善	Spring Cloud Netflix Hystrix
服务网关	无	Spring Cloud Netflix Zuul
分布式配置	无	Spring Cloud Config
服务跟踪	无	Spring Cloud Sleuth
消息总线	无	Spring Cloud Bus
数据流	无	Spring Cloud Stream
批量任务	无	Spring Cloud Task
……	……	……

从上图能够看出其实Dubbo的功能只是Spring Cloud体系的一部分。

这样对比是不够公平的，首先 Dubbo 是 SOA 时代的产物，它的关注点主要在于服务的调用，流量分发、流量监控和熔断。而 Spring Cloud 诞生于微服务架构时代，考虑的是微服务治理的方方面面，另外因为依托了 Spirng、Spirng Boot 的优点之上，两个框架在开始目标就不一致，Dubbo 定位服务治理、Spirng Cloud 是一个生态。

若是仅仅关注于服务治理的这个层面，Dubbo其实还优于Spring Cloud不少：

• Dubbo 支持更多的协议，如：rmi、hessian、http、webservice、thrift、memcached、redis 等。
• Dubbo 使用 RPC 协议效率更高，在极端压力测试下，Dubbo 的效率会高于 Spring Cloud 效率一倍多。
• Dubbo 有更强大的后台管理，Dubbo 提供的后台管理 Dubbo Admin 功能强大，提供了路由规则、动态配置、访问控制、权重调节、均衡负载等诸多强大的功能。
• 能够限制某个 IP 流量的访问权限，设置不一样服务器分发不一样的流量权重，而且支持多种算法，利用这些功能咱们能够在线上作灰度发布、故障转移等，Spring Cloud 到如今还不支持灰度发布、流量权重等功能。

因此Dubbo专一于服务治理；Spring Cloud关注于微服务架构生态。

Dubbo发布对Spring Cloud有影响吗？

国内技术人喜欢拿 Dubbo 和 Spring Cloud 进行对比，是由于二者都是服务治理很是优秀的开源框架。但它们二者的出发点是不同的，Dubbo 关注于服务治理这块而且之后也会继续往这个方向去发展。Spring Cloud 关注的是微服务治理的生态。由于微服务治理的方方面面都是它所关注的内容，服务治理也只是微服务生态的一部分而已。所以能够大胆的判定，Dubbo 将来会在服务治理方面更为出色，而 Spring Cloud 在微服务治理上面无人能敌。

同时根据 Dubbo 最新的更新技术来看，Dubbo 也会积极的拥抱开源，拥抱新技术。Dubbo 接下来的版本将会很快的支持 Spring Boot，方便咱们享受高效开发的同时，也能够支持高效的服务调用。Dubbo 被普遍应用于中国各互联网公司，现在阿里又从新重视起来而且发布了新版本和一系列的计划，对于正在使用 Dubbo 的公司来讲是一个喜讯，对于中国广大的开发者来讲更是一件很是喜悦的事情。咱们很是乐于看到中国有一款很是优秀的开源框架，让咱们有更多的选择，有更好的支持。

二者其实不必定有竞争关系，若是使用得当甚至能够互补；另外两个关注的领域也不一致，所以对 Spring Cloud 的影响甚微。

如何选择？

可能不少人正在犹豫，在服务治理的时候应该选择那个框架呢？若是公司对效率有极高的要求建议使用 Dubbo，相对比 RPC 的效率会比 HTTP 高不少；若是团队不想对技术架构作大的改造建议使用 Dubbo，Dubbo 仅仅须要少许的修改就能够融入到内部系统的架构中。但若是技术团队喜欢挑战新技术，建议选择 Spring Cloud，Spring Cloud 架构体系有有趣很酷的技术。若是公司选择微服务架构去重构整个技术体系，那么 Spring Cloud 是当仁不让之选，它能够说是目前最好的微服务框架没有之一。

最后，技术选型是一个综合的问题，须要考虑团队的状况、业务的发展以及公司的产品特征。最炫最酷的技术并不必定是最好的，选择适合本身团队、符合公司业务的框架才是最佳方案。技术的发展永远没有尽头，所以咱们对技术也要保持空杯、保持饥饿、保持敬畏！

原文出处阿里Dubbo疯狂更新，关Spring Cloud什么事？