【.com原创文章】最近，开源社区发生了一件大事。国内Java开发者使用最广泛的开源服务框架Dubbo低调重启维护，3个月发布4个维护版本。上次写《抛弃Dubbo，选择最流行的SpringCloud微服务架构实践与经验总结》一文时，很多网友给我留言说Dubbo又开始更新了。我当然清楚，也一直在关注Dubbo的方向。几个月前，技术圈传出一则消息，Dubbo又开始更新了，大家议论纷纷。也去github上发帖查询，最后在dubbo的gitter聊天室里找到了令人信服的答案，说正在组建团队。虽然有点期待，但不知道阿里这次这样做到底有多大的诚意，于是昨天又去GitHub上发现，从9月份开始，阿里已经连续三个月发布了四次release.这个版本还是很有诚意的，值得关注。Dubbo简介Dubbo是阿里巴巴开源的高性能服务框架。致力于提供高性能透明的RPC远程服务调用解决方案和SOA服务治理解决方案，使应用程序能够通过高性能RPC实现服务输出和输入功能，与Spring框架无缝集成。Dubbo包含三个核心部分：远程通信、集群容错和自动发现。提供透明的远程方法调用，实现像调用本地方法一样调用远程方法，配置简单，无API侵入。同时具有软负载均衡和容错机制，可以替代内网的F5等硬件负载均衡器，降低成本和单点。可以实现服务的自动注册和发现，不再需要硬编码服务提供者的地址，注册中心根据接口名称查询服务提供者的IP地址，可以平滑的添加或删除服务提供者。2011年底，阿里巴巴在GitHub上开源了基于Java的分布式服务治理框架Dubbo。此后，它成为国内此类开源项目的佼佼者，受到众多开发者的青睐。同时，很多公司在实践中也实现了基于Dubbo的分布式系统架构。目前在GitHub上，其fork和star数已超过10000。Dubbo的核心功能：远程通信，提供对各种基于长连接的NIO框架的抽象封装，包括多线程模型、序列化、“请求-响应”模式下的信息交互方式。集群容错，提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡、容错、地址路由、动态配置等集群支持。自动发现，基于注册中心目录服务，实现服务消费者动态发现服务提供者，地址透明，服务提供者平滑增减机器。Dubbo的发展历史已经发展到开源。2008年底，阿里开始筹划号召，2009年初开发1.0版本；2010年4月，重构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一直在小版本维护，最后一个版本dubbox-2.8.4发布于2015年3月31日，请问Dubbo团队这三个月都做了些什么呢？目前主要开发Dubbo的主要是阿里巴巴的中间件团队，同时阿里内部也招募了一些对Dubbo感兴趣的同事。大家应该知道，今年最后一个版本的Dubbo是什么时候发布的？那是2014年10月30日，距离过去将近3年。Dubbo依赖的Jdk、Spring、Zookeeper、Zkclient等我都不知道。更新了多少个版本。所以，阿里恢复更新的第一步就是适配其依赖的组件的版本，让Dubbo依赖的基础环境不会太落伍，一些严重的bug也得到了修复。dubbo-2.5.4/5版本2017年9月，阿里发布dubbo-2.5.4/5版本，更新内容如下：依赖升级该版本同时升级相关依赖版本，根据问题反馈频率和影响区域安排优先级，优先解决一些反馈最多、影响较大的缺陷，包括优雅关闭、异步调用、动态配置、MonitorFilter监控统计等。dubbo-2.5.6版本2017年10月，阿里发布了dubbo-2.5.6版本，修复了大量严重bug。发布内容主要包括：对PojoUtils工具类的泛化调用无法正确处理枚举类型、私有字段等问题。Provider业务线程池满后，无法将拒绝请求的异常通知给Consumer。当业务返回值payload超过阈值时，将payload重复发回给消费者。slf4jLogger正确输出日志调用的实际行号。延迟暴露了潜在的并发问题，导致不同的服务占用多个端口。当没有provider时，consumer端的mock逻辑无法生效。一些小优化：OverrideListener监听逻辑、provider端关闭心跳请求、Main启动类关闭逻辑等一些小bug修复：动态配置无法删除、telnet支持通用json调用、监听统计错误等dubbo-2.5。7版本2017年11月，也就是12天前，阿里发布了dubbo-2.5.7。这次不仅修复了一批重大bug，还改进了一个小功能。发布内容主要包括：改进注解配置方式，修复社区反馈的注解旧bug。支持启动时从环境变量中读取注册ip端口和绑定ip端口，支持社区反馈的容器化部署场景等。调整并开启一些不完善的xml配置项，如dump.directory等。解决ZK的问题在启动阶段无法连接并导致应用程序无限阻塞。解决ZK无法连接时，初始访问MonitorService会导致rpc请求阻塞的问题#672。内部json实现被标记为已弃用，而是依赖于开源fastjson实现。RMI协议支持传递附件。Hessian支持EnumSet类型序列化。社区报告的一些小错误修复和优化。本次发布的内容较多，所以也给出了升级建议：本次升级有以下不兼容或需要注意的地方，但对核心功能没有影响，可以通过添加依赖或遵循配置规则来避免。这里只是罗列了一些潜在的注意点，如果你不使用这些功能，则不需要额外注意。AccesslogFilter、telnet和mock等一些功能依赖于旧的JSON实现。如果启用了以上功能，请在升级后添加fastjson作为第三方依赖。本次升级改进了注解配置方式，同时保留了旧的注解配置代码。如果项目从之前版本的注解配置更改为2.5.7版本，请务必删除旧的注解扫描配置，使用新的配置形式。在项目启动阶段，如果ZK不可达，当前版本的行为是继续使用注册表缓存启动。详细信息由检查参数确定。首次调用MonitorService时，如果ZK不可达，当前版本会忽略监控数据上传，避免阻塞rpc主进程。在更新2.5.7版本的同时，也给出了下一步的通知。近期会提供dubbo-spring-boot-starter启动配置模块。这个提示说明两点：Dubbo会不断完善，未来会开发很多新的功能，希望大家多多关注。说明SpringBoot的影响力也在越来越大，各种牛逼的开源软件都给予了支持，现在Dubbo也将包括在内。接下来Dubbo会做什么？根据阿里科技的信息，最后三个版本将做以下工作：优先解决社区使用中的问题和框架的缺陷，吸收社区贡献的新特性，解决文档访问和不完整问题。提供服务延迟暴动，优雅宕机API接口，支持RESTFULE风格的服务调用，提供nettyhttp支持，集成高性能序列化协议。路由功能优化，消费者端异步功能优化，提供者端异步调用支持注册中心推送通知异步，合并处理改造等。未来计划重构动态配置模块，将动态配置与注册中心分离，集成流行的开源分布式配置管理框架，将服务元数据注册与注册中心分离，丰富元数据内容，适配流行的注册中心方案如consuletcd。考虑为一些基于服务的基础组件提供支持，例如opentrace、oauth2、metrics、health和gateway。重做服务治理平台OPS。除了代码和UI重构之外，还有望提供更强大的服务测试、健康检查和服务动态治理。和其他特征。Dubbo是模块化的，每个模块都可以单独封装依赖，具有集群熔断和故障自动检测能力。在Dubbo框架现代化和国际化两大方向上继续探索。在现代化方面，我们主要考虑现在的微服务架构和容器化是如何越来越流行的。Dubbo作为一个RPC框架如何能够很好的融入其中，成为其生态系统中不可或缺的组成部分。强调Dubbo未来的定位不是成为微服务的综合解决方案，而是专注于RPC领域，成为微服务生态中的重要组成部分。对于大家关心的微服务衍生出来的服务治理需求，Dubbo会积极适配开源方案，甚至会推出独立的开源项目来支持。Dubbo和SpringCloud有什么区别？首先做一个简单的功能对比：从上图可以看出Dubbo的功能只是SpringCloud体系的一部分。这种比较不够公平。首先，Dubbo是SOA时代的产物。它的重点主要是服务调用、流量分发、流量监控和熔断。SpringCloud诞生于微服务架构时代，考虑到微服务治理的方方面面。另外，依托于Spirng和SpirngBoot的优势，这两个框架在一开始的目标并不一致。Dubbo定位服务治理和SpirngCloud是一个生态。如果只关注这一层的服务治理，Dubbo比SpringCloud要好很多：Dubbo支持的协议更多，比如：rmi、hessian、http、webservice、thrift、memcached、redis等。Dubbo在使用RPC协议时效率更高。在极限压力测试下，Dubbo的效率将是SpringCloud的两倍以上。Dubbo拥有更强大的后台管理。Dubbo提供的后台管理DubboAdmin功能强大，提供路由规则、动态配置、访问控制、权重调整、负载均衡等诸多强大功能。可以限制某个IP流量的访问权限，设置不同的服务器分配不同的流量权重，支持多种算法。有了这些功能，我们就可以做在线灰度发布，故障转移等，SpringCloud目前还不支持灰度发布，流量权重等功能。下图是DubboAdmin后台的截图：所以Dubbo专注于服务治理，SpringCloud专注于微服务架构生态。Dubbo的发布对SpringCloud有影响吗？国内的技术人员喜欢拿Dubbo和SpringCloud做比较，因为两者都是优秀的服务治理开源框架。但他们的出发点不同。Dubbo专注于服务治理，未来会继续往这个方向发展。SpringCloud专注于微服务治理的生态。因为微服务治理的方方面面都是它所关注的，而服务治理只是微服务生态的一部分。因此，可以大胆断定，未来Dubbo在服务治理上会更胜一筹，SpringCloud在微服务治理上无可匹敌。同时，根据Dubbo最新的更新技术，Dubbo也将积极拥抱开源和新技术。下个版本的Dubbo即将支持SpringBoot，让我们在享受高效开发的同时，也能支持高效的服务调用。Dubbo在国内各个互联网公司都有广泛的应用。现在阿里重新强调并发布了新版本和一系列计划。这对于正在使用Dubbo的企业来说是一个好消息，对于国内广大的开发??者来说也是一个好消息。一件很开心的事情。我们很高兴看到中国有一个非常好的开源框架，给了我们更多的选择和更好的支持。因此，两者不一定是竞争关系，如果使用得当，甚至可以互补；另外两个关注点也不一致，所以对SpringCloud影响不大。Dubbo和SpringCloud如何选择？很多人可能会犹豫，服务治理应该选择哪个框架呢？如果公司对效率要求特别高，推荐使用Dubbo，相比HTTP，RPC效率要高很多；如果团队不想对技术架构做大的改动。推荐使用Dubbo。Dubbo只需少量修改即可集成到内部系统架构中。但如果技术团队喜欢挑战新技术，还是建议选择SpringCloud。SpringCloud架构体系有有趣和酷炫的技术。如果企业选择微服务架构重构整个技术体系，那么SpringCloud是正确的选择。可以说它不是目前最好的微服务框架之一。最后，技术选型是一个综合性的问题，需要综合考虑团队情况、业务发展、公司产品特点。最酷最酷的技术不一定是最好的，最好的方案是选择适合自己团队和公司业务的框架。技术的发展永无止境，所以我们要保持空杯，保持饥饿，保持对技术的敬畏！张强，曾在互联网金融和第三方支付公司担任高级Java工程师、架构师、技术经理、技术总监等职。在互联网金融工作期间，他从无到有参与了公司技术平台的建设，并组织平台进行了四次重大架构升级。目前在一家第三方支付公司担任架构师，负责支付公司大数据平台建设。【原创稿件，合作网站转载请注明原作者和出处为.com】
