Spring Cloud Dubbo组件去留问题讨论

[steverao]

Spring Cloud Dubbo组件去留问题讨论

由于Spring Cloud Dubbo组件社区做了一些调研发现真正深度使用的用户不多，另外该模块设计本身存在一些问题成熟度不够，复杂度很高，长期缺乏维护答疑同学，因此为了降低社区维护成本，社区第4次双周会讨论觉得将Spring Cloud Dubbo从社区主干分支中移除可能更适合社区当前发展规划。社区未来的工作中心将在维护现有其他组件的稳定性的前提下，提升Spring Cloud Alibaba的微服务治理能力上，对相关建设感兴趣的同学也可以参与到社区的相关功能的建设上来，具体可参见：建设文档。你是否支持社区从主干中移除Spring Cloud Dubbo模块呢？无论是否支持都可以在本issue下进行留言，你的宝贵意见也是Spring Cloud Alibaba社区规划决策的重要信息来源！

Discussion on the problem of leaving and leaving Spring Cloud Dubbo components

We has done some research and found the Spring Cloud Dubbo component there are not many users who really use it deeply, and there are some problems in the design of the module itself, the maturity is not enough, the complexity is high, and there is a long-term lack of maintenance and answering contributors. Therefore, in order to reduce the cost of community maintenance, the community The 4th biweekly meeting discussed that it may be more suitable for the current development plan of the community to remove Spring Cloud Dubbo from the main branch of the community. The future work of the community will improve the microservices governance capabilities of Spring Cloud Alibaba on the premise of maintaining the stability of other existing components.People who are interested in related construction can also participate in the construction of related functions of the community. See: Construction Documentation. Do you support the community to remove the Spring Cloud Dubbo module from repository? Whether you support it or not, you can leave a comment under this issue. Your valuable opinions are also an important source of information for the planning and decision-making of the Spring Cloud Alibaba community!

[steverao]

如果希望实现 Spring Cloud 应用调用 Dubbo 服务，建议先直接通过 Spring Boot 将 Dubbo 服务暴露为 RESTful API 的方式以供对外调用。这样两个组件互相都是独立的出现问题也方便排查，比较推荐使用。

[galaxy-sea]

如果希望实现 Spring Cloud 应用调用 Dubbo 服务，建议先直接通过 Spring Boot 将 Dubbo 服务暴露为 RESTful API 的方式以供对外调用。这样两个组件互相都是独立的出现问题也方便排查，比较推荐使用。

那为何不用 sofa 呐，sofa这方面比Spring Cloud Alibaba成熟很多

[kevinw66]

我们是从feign迁移到dubbo的，dubbo的稳定性比feign要高一些。

[mercyblitz]

首先，给这位热心的楼主同学说声抱歉，自个人离职后，投入维护的时间就不多了。我个人的看法是，Spring Cloud Dubbo 组建希望更多社区的人参与进来，逐步地完善，在社区群或者 issues 里面讨论。实际上，Spring Cloud Dubbo 出自身有些问题外，外部变化也会导致不稳定，比如 Spring Cloud 版本升级以及 Apache Dubbo 内部升级，同时底层涉及面比较广，所以也需要社区的小伙伴了解相关技术，当然我也会尽量地拖入时间参与维护～

[mercyblitz]

我们是从feign迁移到dubbo的，dubbo的稳定性比feign要高一些。

我所知道的部分公司使用 Spring Cloud Dubbo 后，性能和稳定性提升不少，不过目前在 K8s 环境下，网络地址变化的问题可能还是存在。

[frlzk]

Dubbo的RPC实现方式是独特的，不适合使用Feign或RESTful直接替换，因此我认为应该保留。

[imhuzi]

一般不会存在 很多 dubbo与 spring cloud 混用的情况，毕竟维护两套技术栈 不是中小团队能负担的，而且随着云原生和 dubbo3.0 确实 没有存在的必要了，而且这东西非常不成熟，当成基于 Spring Cloud Gateway 做内部网关，基于 Spring Cloud Dubbo 来有用后端dubbo服务踩了非常多的坑，简直就是个鸡肋，最终选择了 dubbo 泛化 搞定，所以还是去掉吧

[HaojunRen]

未来Spring Cloud很多组件都是通过Reactor方式展开的，Dubbo在此方面是否有一些考量

[Ericj100]

如果去掉spring cloud alibaba dubbo，那只能自己使用spring boot dubbo与spring cloud相集成，会不会导致更多的兼容问题等？我们考虑spring cloud alibaba就是考虑到这是一个spring cloud全家桶，直接集成就好了

[niuzhiweimr]

其实集成dubbo+feign是SCA的一个优势,但是目前dubbo一直存在一个No provider问题修复了很多个版本依然没有修复导致很多人慢慢放弃掉SCA,不是应该集中力量着重修复这个问题吗?

[wadezyj]

我觉得Spring Cloud Dubbo 是 Spring Cloud alibaba的最大卖点。

[galaxy-sea]

我觉得Spring Cloud Dubbo 是 Spring Cloud alibaba的最大卖点。

也是最大的痛点呀

[ghy545163777]

不准， 退朝

[tan-zhuo]

目前我在项目中很好的使用了 dubbo 模块，对于 rest 方面来说，dubbo 有 apache-dubbo-rpc-rest 模块可以很好的支持 rest 协议并注册入nacos中与spring-gateway网关进行协调组合使用。另外对于dubbo 多协议的特点，我们完全可以在service中 对外进行 rest 协议，对内部上游服务进行 rpc dubbo协议调用 从而最大化发挥dubbo 的功能。就此而言，虽然dubbo 的功能中存在些许瑕疵，但仍希望dubbo会越来越好，而不是舍去它。

[mengxuan37]

不支持移除Spring Cloud Dubbo模块，没有这个模块为何还用 cloud alibaba

[steverao]

我觉得Spring Cloud Dubbo 是 Spring Cloud alibaba的最大卖点。

欢迎你介绍一下自己在什么场景下使用过Spring Cloud Dubbo，欢迎跟社区沟通你的想法！

[steverao]

看到上面很多同学的发言，感觉大家对Spring Cloud Dubbo（后文简称SCD）的作用不是特别清楚，这里稍微说明一下：

• SCD这个组件仅仅是作为阿里微服务解决方案中的一个模块而已，Spring Cloud Alibaba的价值在于将阿里巴巴内部成熟微服务解决方案比如：注册配置中心、限流降级、分布式事务、分布式消息等等这些能力贡献给开源社区，丰富Spring Cloud生态，没有了SCD组件完全不影响大家使用上述相关能力，SCD仅仅是为了实现Spring Cloud应用便捷地调用Dubbo服务，但在设计过程中由于一系列原因这个想法没能力实现，外部用户比较少，而且反而给当前的社区带来了较大的运维负担，因此才发起该讨论。
• 另外没有SCD组件，对大部分用户来说，使用RESTful API暴露Dubbo服务的方式已经完全满足一般需求了，使用SCD反而给应用带来了一定复杂性，可能得不偿失。

[HaojunRen]

是否继续维护，先暂时搁置讨论。先讨论一个我上面曾提过的问题，Spring Cloud 2020，2021等新版本在不断迭代，新的发展历程中，Reactor方式是未来重要的发展方向，对于非阻塞式的调用方式，Dubbo是否可以无缝良好的适配这个技术栈？我猜想应该需要改动Dubbo源码，那么，这部分工作由Dubbo核心开发人员去做，还是sca社区人员来做？

[DanielLiu1123]

Dubbo 实现非阻塞这个应该是 Dubbo 开发人员需要做的工作, 将 Dubbo 非阻塞整合进 Spring Cloud, SCA 也要做工作, 而且这个工作量会特别大

[DanielLiu1123]

Spring Cloud 是一个微服务框架, 而微服务所定义的通信方式是 Http, 想要整合 Dubbo 在 RPC 上的优势和 Spring Cloud 的生态, 很难做到完美的契合, 也不是标准的体现

[tnessn]

dubbo包可以放在spring cloud alibaba里面进行管理这个没毛病，别去做过度整合就好了，单纯用dubbo-spring-boot-starter是没问题的

[RainElohim]

我们是从feign迁移到dubbo的，dubbo的稳定性比feign要高一些。

我所知道的部分公司使用 Spring Cloud Dubbo 后，性能和稳定性提升不少，不过目前在 K8s 环境下，网络地址变化的问题可能还是存在。

小马哥 这个不得不吐槽下 k8s下这个问题发现快两年了 一直都没人管 = =！

[rottenmu]

我心里虽然还是比较抗拒，长远来看，还是移除的好，一个技术团队采用不同类别的通讯协议，维护成本较高，并且到后面集成其他中间件一旦遇到问题，解决成本会很高。springcloud dubbo可以说是探索，小弟认为可能是不健康的，这也维护团队带来很多困扰。

[Fox2210]

我相信大部分使用Spring Cloud Alibaba框架或多或少都是因为dubbo，其他组件很棒但并不是选择该框架的主因，服务丢失问题从20年底发现时就开始关注，中间也是各种尝试但是还是存在丢失问题，形势所逼把dubbo改成open-feign调用，问题倒是解决但是写起来不优雅（就算是feign接口继承基础api接口，控制层实现api接口觉得还是不太漂亮），在这点上dubbo确实有优势，spring cloud dubbo组件可以换成阿里基础dubbo版本，一方面维护成本小毕竟dubbo3.0都出来了，另一方面组件分离好排查问题

[ghost]

我相信大部分使用Spring Cloud Alibaba框架或多或少都是因为dubbo，其他组件很棒但并不是选择该框架的主因，服务丢失问题从20年底发现时就开始关注，中间也是各种尝试但是还是存在丢失问题，形势所逼把dubbo改成open-feign调用，问题倒是解决但是写起来不优雅（就算是feign接口继承基础api接口，控制层实现api接口觉得还是不太漂亮），在这点上dubbo确实有优势，spring cloud dubbo组件可以换成阿里基础dubbo版本，一方面维护成本小毕竟dubbo3.0都出来了，另一方面组件分离好排查问题

非常同意你的说法，我现在把open-feign 换成了SCD.也是觉得open-feign 写起来不太优雅。dubbo3.0出来以后不是就可以service-name 去依赖应用了吗。 现阶段把所有接口信息暴露在nacos 个人觉得也不太好。

[steverao]

经过社区的讨论，决定暂时先将Spring Cloud Dubbo从主干分支移除到其他单独的分支进行维护，待后续稳定以后再随主干分支迭代发布，大家对相关模块感兴趣也可以参与到相关模块的维护中来哈

[mailingfeng]

"将Spring Cloud Dubbo从社区主干分支中移除可能更适合社区当前发展规划"

同意以上观点 Spring Cloud 和 Apache Dubbo 版本升级相对频繁，社区要同时保证对两者的兼容性, 时间成本和复杂度都很大，对最新特性的支持和bug修复也就变慢，稳定性也没法保障。

Spring Cloud Dubbo剥离为独立项目进行更新维护。

[steverao]

对于Spring Cloud Dubbo模块感兴趣的同学，后续可以在该分支参与Spring Cloud Dubbo模块的维护：https://github.com/alibaba/spring-cloud-alibaba/tree/spring-cloud-dubbo

[ooooo-youwillsee]

feign 的兼容完全可以去掉, 用 dubbo 基本上就是 dubbo 协议

[AlbumenJ]

其实集成dubbo+feign是SCA的一个优势,但是目前dubbo一直存在一个No provider问题修复了很多个版本依然没有修复导致很多人慢慢放弃掉SCA,不是应该集中力量着重修复这个问题吗?

关于 no provider 问题的排查 Dubbo 在最近的几个版本（3.x）做了一些增强 ( https://github.com/apache/dubbo/issues/9826 )，具体使用文档还在补充中，后续 Dubbo 社区也会着重对 Dubbo 的使用上的疑难问题做解决，也欢迎到 Dubbo 去提 issue

[steveguoshao]

目前我在项目中很好的使用了 dubbo 模块，对于 rest 方面来说，dubbo 有 apache-dubbo-rpc-rest 模块可以很好的支持 rest 协议并注册入nacos中与spring-gateway网关进行协调组合使用。另外对于dubbo 多协议的特点，我们完全可以在service中 对外进行 rest 协议，对内部上游服务进行 rpc dubbo协议调用 从而最大化发挥dubbo 的功能。就此而言，虽然dubbo 的功能中存在些许瑕疵，但仍希望dubbo会越来越好，而不是舍去它。

对于 rest 方面来说，dubbo 有 apache-dubbo-rpc-rest 模块可以很好的支持 rest 协议并注册入nacos中与spring-gateway网关进行协调组合使用，这种方式你试验过吗？我弄了，貌似不行

[wangketao2010]

NO! NO! NO! save dubbo! save dubbo! save dubbo!

[steverao]

NO! NO! NO! save dubbo! save dubbo! save dubbo!

Please give some reasons to community instean of your feeling!

[warmonipa]

需要考虑下已经使用了sca dubbo的客户，他们相信sca的背书能力，如果就这样stop了sca-dubbo，那以后谁还敢用sca的框架呢。

[steverao]

这个我们已经在这个issues讨论了很久，发现很少有同学真正在自己的生产环境使用Spring Cloud Dubbo的核心内容(基本没看到有同学说有使用)。另外这块因为设计过程中未达到功能的设计初衷所以推荐可能有使用的同学使用更简单的通过restful api方式暴露dubbo服务给spring cloud 服务调用，这是我们社区现在推荐的使用方法。我们是经过了很多内部核心贡献者间的讨论之后才做出这个决定的，具体可以参见社区会议纪要。另外开源社区根据自身情况做出适合项目发展的决定肯定是没有问题的，这块你可以了解一下Spring Cloud社区在新版本中移除Ribbon等组件的决定等。如果你对相关模块设计有兴趣也欢迎你参与进来贡献相关模块的设计，待相关模块真正成熟我们也会考虑看是否融入主分支再推荐外界用户使用。

[gundamff]

需要考虑一下正在从Spring Cloud 向 dubbo迁移的情况，项目中的许多微服务，肯定是逐步迁移的，过程中存在Spring Cloud 和dubbo共存的情况是必然的

[steverao]

需要考虑一下正在从Spring Cloud 向 dubbo迁移的情况，项目中的许多微服务，肯定是逐步迁移的，过程中存在Spring Cloud 和dubbo共存的情况是必然的

迁移不建议这样迁移，现在用Spring cloud dubbo只会带来更大复杂性，如果需要迁移就用我们推荐的使用restful api暴露dubbo服务给Spring Cloud 服务进行调用进行迁移就好了。

[warmonipa]

SC本身也代表了高质量，SCD组件dubbo核心成员没有参与吗？原以为是他们维护呢，如果是两个团队维护，两边的迭代协调还是很难，那出现各种问题就不奇怪了。

[gundamff]

需要考虑一下正在从Spring Cloud 向 dubbo迁移的情况，项目中的许多微服务，肯定是逐步迁移的，过程中存在Spring Cloud 和dubbo共存的情况是必然的

迁移不建议这样迁移，现在用Spring cloud dubbo只会带来更大复杂性，如果需要迁移就用我们推荐的使用restful api暴露dubbo服务给Spring Cloud 服务进行调用进行迁移就好了。

迁移的主要原因是性能因素，结果迁移完了还走http, 这不是南辕北辙吗？

[steverao]

需要考虑一下正在从Spring Cloud 向 dubbo迁移的情况，项目中的许多微服务，肯定是逐步迁移的，过程中存在Spring Cloud 和dubbo共存的情况是必然的

迁移不建议这样迁移，现在用Spring cloud dubbo只会带来更大复杂性，如果需要迁移就用我们推荐的使用restful api暴露dubbo服务给Spring Cloud 服务进行调用进行迁移就好了。

迁移的主要原因是性能因素，结果迁移完了还走http, 这不是南辕北辙吗？

如果是Spring Cloud应用迁移Dubbo，迁移过程中临时使用Spring Cloud 服务调用改造后的部分应用的 Dubbo 服务，等迁移完后再全部切换成Dubbo服务间调用是没有问题的，又不需要迁移完以后仍然使用http协议。

[HelloToGithub]

    <!-- Dubbo Spring Cloud Starter -->
    <dependency>
        <groupId>com.alibaba.cloud</groupId>
        <artifactId>spring-cloud-starter-dubbo</artifactId>
    </dependency>
    还能使用吗 还是要换成独立依赖org.apache.dubbo

[steverao]

    <!-- Dubbo Spring Cloud Starter -->
    <dependency>
        <groupId>com.alibaba.cloud</groupId>
        <artifactId>spring-cloud-starter-dubbo</artifactId>
    </dependency>
    还能使用吗 还是要换成独立依赖org.apache.dubbo

如果你要在一个应用里面使用Dubbo直接用引入dubbo项目原生的依赖吧，不要再使用spring-cloud-starter-dubbo依赖了

[HelloToGithub]

    <!-- Dubbo Spring Cloud Starter -->
    <dependency>
        <groupId>com.alibaba.cloud</groupId>
        <artifactId>spring-cloud-starter-dubbo</artifactId>
    </dependency>
    还能使用吗 还是要换成独立依赖org.apache.dubbo

如果你要在一个应用里面使用Dubbo直接用引入dubbo项目原生的依赖吧，不要再使用spring-cloud-starter-dubbo依赖了

明白 我们原本是用dubbo 后面想要转Spring Cloud 所以使用了 Spring Cloud Dubbo进行无缝切换。如果按照目前情况看 那之后是不是就要考虑相关dubbo服务 切换成Feign。您有什么好的建议。

[steverao]

    <!-- Dubbo Spring Cloud Starter -->
    <dependency>
        <groupId>com.alibaba.cloud</groupId>
        <artifactId>spring-cloud-starter-dubbo</artifactId>
    </dependency>
    还能使用吗 还是要换成独立依赖org.apache.dubbo

如果你要在一个应用里面使用Dubbo直接用引入dubbo项目原生的依赖吧，不要再使用spring-cloud-starter-dubbo依赖了

明白 我们原本是用dubbo 后面想要转Spring Cloud 所以使用了 Spring Cloud Dubbo进行无缝切换。如果按照目前情况看 那之后是不是就要考虑相关dubbo服务 切换成Feign。您有什么好的建议。

将Dubbo服务暴露RESTful API供新的Spring Cloud服务进行调用，可以作为临时的折中方案，然后慢慢去改造dubbo服务直到全部迁移至Spring Cloud就好了

[tan-zhuo]

目前我在项目中很好地使用了 dubbo 模块，对于 rest 方面来说，dubbo 有 apache-dubbo-rpc-rest 模块可以很好的支持 rest 协议并注册入nacos中与spring-gateway网关进行协调组合使用。另外对于dubbo 多协议的特点，我们完全可以在service中 对外进行 rest 协议，对内部上游服务进行 rpc dubbo 协议调用 从而最大化发挥dubbo 的功能。就此而言，虽然dubbo 的功能中存在些许瑕疵，但仍希望dubbo会越来越好，而不是舍去它。

对于 rest 方面来说，dubbo 有 apache-dubbo-rpc-rest 模块可以很好的支持 rest 协议并注册入nacos中与spring-gateway网关进行协调组合使用，这种方式你试验过吗？我弄了，貌似不行

完全可以的，dubbo 的 rest 模块是使用 Jboos 的 RESTEasy 进行暴露 http，目前项目已经正常上线了。整个调用流程会是：gateway（网关）-> dubbo-rest-service（RESTEasy）-> dubbo-rpc-service（内部rpc服务），不过由于社区已经不再进行兼容了，后续会完全迁移到 apache dubbo 3.0 上做处理

[15168326318]

未来Spring Cloud很多组件都是通过Reactor方式展开的，Dubbo在此方面是否有一些考量

dubbo底层是netty呀，netty就是Reactor实现的一种吧？

[15168326318]

如果去掉spring cloud alibaba dubbo，那只能自己使用spring boot dubbo与spring cloud相集成，会不会导致更多的兼容问题等？我们考虑spring cloud alibaba就是考虑到这是一个spring cloud全家桶，直接集成就好了

你觉得有什么问题呢？ 限流，熔断这些是不是就要单独实现了。

[15168326318]

需要考虑一下正在从Spring Cloud 向 dubbo迁移的情况，项目中的许多微服务，肯定是逐步迁移的，过程中存在Spring Cloud 和dubbo共存的情况是必然的

迁移不建议这样迁移，现在用Spring cloud dubbo只会带来更大复杂性，如果需要迁移就用我们推荐的使用restful api暴露dubbo服务给Spring Cloud 服务进行调用进行迁移就好了。

直接在Spring Cloud 里用 @Reference 调用dubbo不是更合适吗 ？

[steverao]

需要考虑一下正在从Spring Cloud 向 dubbo迁移的情况，项目中的许多微服务，肯定是逐步迁移的，过程中存在Spring Cloud 和dubbo共存的情况是必然的

迁移不建议这样迁移，现在用Spring cloud dubbo只会带来更大复杂性，如果需要迁移就用我们推荐的使用restful api暴露dubbo服务给Spring Cloud 服务进行调用进行迁移就好了。

直接在Spring Cloud 里用 @reference 调用dubbo不是更合适吗 ？

你说的应该是在Spring Boot基础上Dubbo服务调用Dubbo服务吧？

[yisirman]

看了大家讨论了这么多 有实际了解过spring-cloud-starter-dubbo存在的意义么？

我的理解这个依赖主要是负责处理兼容 Feign 的 Dubbo 代理配置 通过 Feign 做服务发现 项目中 如果统一使用 Dubbo 则不需要使用这个依赖 况且 Dubbo 3.x 已经支持 基于应用服务的发现机制 故完全没必要与 Feign 做兼容处理

我们公司所有的服务都是dubbo服务，所以我直接修改为使用dubbo-spring-boot-starter 目前来看好像也没有任何问题