曾风靡国内的开源 RPC 服务框架 Dubbo 在重启维护后,令许多用户为之雀跃,但同时,也迎来了一些质疑的声音。互联网技术发展迅速,Dubbo 是否还能跟上时代?Dubbo 与 Spring Cloud 相比又有何优势和差异?是否会有相关举措保证 Dubbo 的后续更新频率?带着这些疑问,本期开源访谈邀请到了主导 Dubbo 重启维护开发的刘军,解答大家最想了解的相关问题。
刘军,阿里巴巴中间件高级研发工程师,主导了 Dubbo 重启维护以后的几个发版计划,专注于高性能 RPC 框架和微服务相关领域。曾负责网易考拉 RPC 框架的研发及指导在内部使用,参与了服务治理平台、分布式跟踪系统、分布式一致性框架等从无到有的设计与开发过程。
对于这个问题社区的用户比较关心,我们在之前的一些渠道也专门做了解答,我在此引用如下:
Dubbo 自 2011 年开源以來,深受国内友商和开源爱好者的青睐,虽然一直陆续在维护,但是由于 Dubbo 用户群体庞大,日常维护根本无法完全满足社区的旺盛需求。随着集团内部技术水平的迅速发展,如今不仅能够保证集团及客户的系统高效运行,还能抽调更多精力将技术赋能给全社会。
开源就是阿里巴巴集团在技术层面赋能的重要领域。阿里巴巴中间件团队今后不仅要聆听社区的声音,及时修复问题,及时合并优秀的 pull request,还会力争将 Dubbo 打造成有国际影响力的 RPC 框架。
从集团层面看,阿里为国内甚至国际开源社区贡献了大量优秀开源项目,如大家熟知的 RocketMQ、JStorm、Fastjson、Dubbo、Weex 等。在今年的云栖大会上,阿里集团公开宣布了将加大技术投入、拥抱开源的发展策略。正是由于以上几个原因,阿里巴巴中间件团队决定 Dubbo 的下一步计划是持续发展,并走向国际化。
Dubbo 自开源以后,被国内很多互联网公司用作服务化基础框架,经历了在阿里内部及很多大型互联网公司长时间生产环境实践,已经被证明是一个高度可靠、经受得住大规模流量考验的服务治理框架,这些成功的实践案例,在服务化框架选型时能给予架构师足够的信心与经验。
另外,相比很多开源 RPC 框架,Dubbo 在服务治理功能集上可谓非常完善:不仅提供了服务注册发现、负载均衡及路由等面向分布式集群的基础能力,还设计了面向开发测试阶段的 mock、泛化调用等机制,同时也提供了服务治理、监控的可视化平台。
Dubbo 是一个高度可扩展的框架,几乎所有核心功能都被设计为一个扩展点,因此从用户的角度,即使之前在 Dubbo 的官方社区支持不足的情况下,使用者仍可以很容易的对 Dubbo 进行裁剪或扩展以满足组织内部的需求。
首先从 RPC 的角度来说,RPC 是一个相对成熟的方向,Dubbo 在协议、网络通信等层面的设计已经保证了稳定性与高性能,在这个层面 Dubbo 已经做得非常好了;而从服务治理的角度,Dubbo 已经对很多集群场景下的服务治理特性提供了支持,同时随着近两年微服务架构的流行,Dubbo 在某些功能上确实需要加强:比如社区关心的熔断功能,Dubbo 虽有容错支持但却还没有融入熔断的理念。我们计划在接下来的几个版本中会重点对这些缺失的功能逐步增强。
Dubbo 本身的定位只是一个 RPC 框架,基于 Dubbo 开发的应用还是要依赖周边的平台与生态,所以 Dubbo 自然要去积极的适配周边生态的发展趋势。比如你提到的以容器技术为代表的 Cloud Native 生态,这个确实是 Dubbo 要去积极跟进的方向,Dubbo 也已经在行动,比如近期的版本中支持了 Docker 容器等隔离网络环境的部署,同时对 OpenTracing、Spring Boot 的支持也在进行中,而对于底层调度平台及周边生态的变化,我们也在积极关注,总之 Dubbo 会积极的融入到这些健康发展的生态中去,以支持基于 Dubbo 开发的系统可以更顺畅的走向云化。
Dubbo 自 2017 年 8 月份重启维护以来,已经连续发布了 5 个版本,基本维持了每月一个版本的发版节奏,而发版内容上以优先解决社区呼声较高的需求为主。2.5.8 版本开始,之前社区累积报告的 bug 基本都已得到了修复,另外还对 netty4 的支持、annotation 的增强、java 8 的支持、docker 的支持等进行了增强。Dubbo 做出的一系列改进,让社区再次沸腾起来。
接下来,我们将继续投入一定的精力关注社区的使用反馈与需求,建立更完善的发版机制,做到影响版本稳定性的 bug 随时修复,用户关心的功能及时在 feature 版本予以支持。当前已经在我们规划中的,近期将会提供支持的功能点包括:spring boot 的集成、RESTful、优雅部署、容错增强、路由策略增强以及异步化增强等。
当然,我们会考虑在合适的时机,陆续的将阿里在 HSF 框架以及在大规模服务化场景下的服务治理经验通过 Dubbo 输出到社区。HSF 本身完全兼容 Dubbo ,和阿里内部的很多系统结合比较紧密并且做了一些定制化的工作,这使得 HSF 更适合于阿里内部的超大规模集群场景,相信 HSF 在超大规模连接管理、智能路由、服务管控等方面的经验能帮助到 Dubbo 社区的用户。
值得一提的是,当前维护 Dubbo 的团队成员很多也同时参与 HSF 的维护,除此之外,还有一些来自阿里中间件其他团队的同学参与进来,这样更利于形成良性循环,做到真正意义上的内外统一。
关于 Dubbo 和 Spring Cloud 间的关系,我们在 开源中国年终盛典 的 Dubbo 分享中也作了简单阐述,首先要明确的一点是 Dubbo 和 Spring Cloud 并不是完全的竞争关系,两者所解决的问题域并不一样:Dubbo 的定位始终是一款 RPC 框架,而 Spring Cloud 的目标是微服务架构下的一站式解决方案。如果非要比较的话,我觉得 Dubbo 可以类比到 Netflix OSS 技术栈,而 Spring Cloud 集成了 Netflix OSS 作为分布式服务治理解决方案,但除此之外 Spring Cloud 还提供了包括 config、stream、security、sleuth 等等分布式问题解决方案。
当前由于 RPC 协议、注册中心元数据不匹配等问题,在面临微服务基础框架选型时 Dubbo 与 Spring Cloud 是只能二选一,这也是为什么大家总是拿 Dubbo 和 Spring Cloud 做对比的原因之一。Dubbo 之后会积极寻求适配到 Spring Cloud 生态,比如作为 Spring Cloud 的二进制通信方案来发挥 Dubbo 的性能优势,或者 Dubbo 通过模块化以及对 http 的支持适配到 Spring Cloud 。
首先,我想结合时下流行的容器调度平台简单说一下,以 kubernetes 为例,它不仅提供了容器的部署、调度等生命周期管理能力,还抽象出了服务的概念,能实现服务地址的动态注册发现、负载均衡、health check、动态配置等,可以说服务治理的能力在往底层平台层面下沉,而类似 Dubbo 的服务治理框架本身可以变得更轻量。
另一个方面,跨多语言的服务治理一直是开源服务治理框架面临的问题。有些 RPC 框架提供了完善跨语言的通信支持,但是服务治理能力有限,如 gRPC、thrift 等;而有丰富服务治理功能的框架往往局限于某一个特定的开发语言,如 Netflix、Dubbo 仅限定于 java 。最近兴起的 Service Mesh 方案看似是未来解决跨语言问题的完美方案,它接管了所有的网络流量,因此能实现流量调度和管控相关的功能。更进一步,类似 istio、conduit 等框架又与底层调度平台的服务注册发现等能力进行对接,同时也对微服务周边解决方案的适配提供了统一抽象,RPC 通信和服务治理能力不再耦合在一起,业务应用只需要面向基础的 RPC 通信框架编程。
从 Dubbo 自身来说,未来主要会着重向 Cloud Native 、多语言增强、微服务支持等几个方向演进,同时不断建设生态系统、社区、以及国际影响力。
首先,感谢开源社区对 Dubbo 项目的支持与信赖,重启维护以来我们收到了大量来自社区的 issue 反馈或 Pull Request ,包括对问题修复、功能增强、方案讨论等,对 Dubbo 项目的发展起到了很大的推动作用。
接下来 Dubbo 将得到官方团队的持续维护,我们会从围绕 Dubbo 的功能特性增强做起,逐步推动 Dubbo 的架构调整、模块化等,同时积极的融入周边微服务生态、推动 Dubbo 走向国际化。同时我们期望有更多的社区力量参与进来,如果您期望加入 Dubbo 团队或想对 Dubbo 团队提供建议,欢迎发邮件联系我们:dubbo.alibaba@gmail.com。
感谢开源中国能提供这样的交流机会,开源中国已经是国内影响力最大的开源社区,希望开源中国与源创汇越办越好。
转自 https://www.oschina.net/question/2896879_2272652