icp备案网站信息查询,大庆seo公司,红色扁平化网站,2023重大新闻事件10条2016年#xff0c;我在博客中发表过一篇《微服务架构的基础框架选择#xff1a;Spring Cloud还是Dubbo#xff1f;》获得了很大的阅读量和转载量。在这篇文章中#xff0c;我主要对比了Spring Cloud与Dubbo所具备的能力#xff0c;并阐述了个人推崇Spring Cloud的原因。但… 2016年我在博客中发表过一篇《微服务架构的基础框架选择Spring Cloud还是Dubbo》获得了很大的阅读量和转载量。在这篇文章中我主要对比了Spring Cloud与Dubbo所具备的能力并阐述了个人推崇Spring Cloud的原因。但是最近各大技术社区出现了不少类似的文章观点比较激进对于Spring Cloud的褒扬远胜于Dubbo但是这些评价很多都忽略了Spring Cloud与Dubbo在设计视角上的不同。其实在前文中我也说明了Dubbo与Spring Cloud的对比本身就不公平因为两者产出的目标格局是不一样的。所以就目前阶段来说大家对于框架的选择上还是要综合考虑自身团队与遗留业务系统的特点来确定更合适的技术栈而不是盲从于“时髦”的架构体系。 昨天看到了开源中国对Dubbo社区维护者的访谈内容非常不错。所以这里分享给大家。其实在最近一年多的时间里结合实际的生产实践我也有了更多的理解与感悟。或许在后面的一段时间里以博文或GitChat的方式与大家分享一下我对Dubbo与Spring Cloud的“爱恨情仇” 以下内容经授权转载自公众号“开源中国” 曾风靡国内的开源 RPC 服务框架 Dubbo 在重启维护后令许多用户为之雀跃但同时也迎来了一些质疑的声音。互联网技术发展迅速Dubbo 是否还能跟上时代Dubbo 与 Spring Cloud 相比又有何优势和差异是否会有相关举措保证 Dubbo 的后续更新频率带着这些疑问本期开源访谈邀请到了主导 Dubbo 重启维护开发的刘军解答大家最想了解的相关问题。
【本期嘉宾】
刘军阿里巴巴中间件高级研发工程师主导了 Dubbo 重启维护以后的几个发版计划专注于高性能 RPC 框架和微服务相关领域。曾负责网易考拉 RPC 框架的研发及指导在内部使用参与了服务治理平台、分布式跟踪系统、分布式一致性框架等从无到有的设计与开发过程。 【访谈内容】
1、为什么会在三年后重新维护 Dubbo
对于这个问题社区的用户比较关心我们在之前的一些渠道也专门做了解答我在此引用如下
Dubbo 自 2011 年开源以來深受国内友商和开源爱好者的青睐虽然一直陆续在维护但是由于 Dubbo 用户群体庞大日常维护根本无法完全满足社区的旺盛需求。随着集团内部技术水平的迅速发展如今不仅能够保证集团及客户的系统高效运行还能抽调更多精力将技术赋能给全社会。
开源就是阿里巴巴集团在技术层面赋能的重要领域。阿里巴巴中间件团队今后不仅要聆听社区的声音及时修复问题及时合并优秀的 pull request还会力争将 Dubbo 打造成有国际影响力的 RPC 框架。
从集团层面看阿里为国内甚至国际开源社区贡献了大量优秀开源项目如大家熟知的 RocketMQ、JStorm、Fastjson、Dubbo、Weex 等。在今年的云栖大会上阿里集团公开宣布了将加大技术投入、拥抱开源的发展策略。正是由于以上几个原因阿里巴巴中间件团队决定Dubbo的下一步计划是持续发展并走向国际化。
2、Dubbo 在停更后还能一直受到喜爱和广泛使用的原因是什么其优势在哪
Dubbo 自开源以后被国内很多互联网公司用作服务化基础框架经历了在阿里内部及很多大型互联网公司长时间生产环境实践已经被证明是一个高度可靠、经受得住大规模流量考验的服务治理框架这些成功的实践案例在服务化框架选型时能给予架构师足够的信心与经验。
另外相比很多开源 RPC 框架Dubbo 在服务治理功能集上可谓非常完善不仅提供了服务注册发现、负载均衡及路由等面向分布式集群的基础能力还设计了面向开发测试阶段的 mock、泛化调用等机制同时也提供了服务治理、监控的可视化平台。
Dubbo 是一个高度可扩展的框架几乎所有核心功能都被设计为一个扩展点因此从用户的角度即使之前在 Dubbo 的官方社区支持不足的情况下使用者仍可以很容易的对 Dubbo 进行裁剪或扩展以满足组织内部的需求。
3、互联网技术发展迅速云、容器等技术的快速应用是否已经让 Dubbo 存在掉队倾向后续要如何解决
首先从 RPC 的角度来说RPC 是一个相对成熟的方向Dubbo 在协议、网络通信等层面的设计已经保证了稳定性与高性能在这个层面 Dubbo 已经做得非常好了而从服务治理的角度Dubbo 已经对很多集群场景下的服务治理特性提供了支持同时随着近两年微服务架构的流行Dubbo 在某些功能上确实需要加强比如社区关心的熔断功能Dubbo 虽有容错支持但却还没有融入熔断的理念。我们计划在接下来的几个版本中会重点对这些缺失的功能逐步增强。
Dubbo 本身的定位只是一个 RPC 框架基于 Dubbo 开发的应用还是要依赖周边的平台与生态所以 Dubbo 自然要去积极的适配周边生态的发展趋势。比如你提到的以容器技术为代表的 Cloud Native 生态这个确实是 Dubbo 要去积极跟进的方向Dubbo 也已经在行动比如近期的版本中支持了 Docker 容器等隔离网络环境的部署同时对 OpenTracing、Spring Boot 的支持也在进行中而对于底层调度平台及周边生态的变化我们也在积极关注总之 Dubbo 会积极的融入到这些健康发展的生态中去以支持基于 Dubbo 开发的系统可以更顺畅的走向云化。
4、是否会有相关举措保证 Dubbo 的后续更新频率以解决用户的担忧
Dubbo 自 2017 年 8 月份重启维护以来已经连续发布了 5 个版本基本维持了每月一个版本的发版节奏而发版内容上以优先解决社区呼声较高的需求为主。2.5.8 版本开始之前社区累积报告的 bug 基本都已得到了修复另外还对 netty4 的支持、annotation 的增强、java 8 的支持、docker 的支持等进行了增强。Dubbo 做出的一系列改进让社区再次沸腾起来。
接下来我们将继续投入一定的精力关注社区的使用反馈与需求建立更完善的发版机制做到影响版本稳定性的 bug 随时修复用户关心的功能及时在 feature 版本予以支持。当前已经在我们规划中的近期将会提供支持的功能点包括spring boot 的集成、RESTful、优雅部署、容错增强、路由策略增强以及异步化增强等。
5、Dubbo 和 HSF 都是阿里自研的 RPC 服务框架Dubbo 后续是否会吸取 HSF 上的一些特性以满足业务拓展需求
当然我们会考虑在合适的时机陆续的将阿里在 HSF 框架以及在大规模服务化场景下的服务治理经验通过 Dubbo 输出到社区。HSF 本身完全兼容 Dubbo 和阿里内部的很多系统结合比较紧密并且做了一些定制化的工作这使得 HSF 更适合于阿里内部的超大规模集群场景相信 HSF 在超大规模连接管理、智能路由、服务管控等方面的经验能帮助到 Dubbo 社区的用户。
值得一提的是当前维护 Dubbo 的团队成员很多也同时参与 HSF 的维护除此之外还有一些来自阿里中间件其他团队的同学参与进来这样更利于形成良性循环做到真正意义上的内外统一。
7、目前 Dubbo 被拿来比较最多的就是 Spring Cloud 您怎么看待二者的关系业务上是否有所冲突
关于 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 。
7、现阶段的服务治理框架方案是否存在瓶颈如何看待其后续发展方向
首先我想结合时下流行的容器调度平台简单说一下以 kubernetes 为例它不仅提供了容器的部署、调度等生命周期管理能力还抽象出了服务的概念能实现服务地址的动态注册发现、负载均衡、health check、动态配置等可以说服务治理的能力在往底层平台层面下沉而类似 Dubbo 的服务治理框架本身可以变得更轻量。
另一个方面跨多语言的服务治理一直是开源服务治理框架面临的问题。有些 RPC 框架提供了完善跨语言的通信支持但是服务治理能力有限如 gRPC、thrift 等而有丰富服务治理功能的框架往往局限于某一个特定的开发语言如 Netflix、Dubbo 仅限定于 java 。最近兴起的 Service Mesh 方案看似是未来解决跨语言问题的完美方案它接管了所有的网络流量因此能实现流量调度和管控相关的功能。更进一步类似 istio、conduit 等框架又与底层调度平台的服务注册发现等能力进行对接同时也对微服务周边解决方案的适配提供了统一抽象RPC 通信和服务治理能力不再耦合在一起业务应用只需要面向基础的 RPC 通信框架编程。
从 Dubbo 自身来说未来主要会着重向 Cloud Native 、多语言增强、微服务支持等几个方向演进同时不断建设生态系统、社区、以及国际影响力。 原文https://www.oschina.net/question/2896879_2272652
