为什么不用feign而是用dubbo

Feign和Dubbo都是用于微服务架构中服务之间的通信的工具，但它们有不同的使用场景和优劣势。

Feign是一个基于HTTP协议的轻量级RESTful框架，它的主要作用是让开发者更容易地编写基于HTTP的API的客户端。如果你的应用程序使用的是RESTful架构，并且需要与其他的HTTP API进行通信，那么使用Feign是一个不错的选择。

Dubbo是一款高性能、轻量级的RPC框架，它主要用于构建分布式服务端和客户端。如果你的应用程序需要处理大量的服务调用，并且需要满足高性能、高可靠性和可扩展性的要求，那么使用Dubbo是一个不错的选择。

综上所述，Feign适用于基于HTTP协议的RESTful架构，而Dubbo适用于构建分布式服务端和客户端。选择哪种工具取决于你的具体需求和应用场景。

相关问题

什么时候用feign，什么时候用dubbo

Feign和Dubbo都是用于微服务架构中的远程调用框架，但它们的应用场景略有不同：

当应用采用了Spring Cloud微服务架构时，可以使用Feign进行微服务间的调用。Feign是一种声明式的Web服务客户端，可以让开发者使用Spring MVC注解来定义服务接口，并自动将服务接口转换为HTTP请求。它与Spring Cloud集成良好，可以与Eureka、Ribbon和Hystrix等组件协同工作，提供了完整的服务治理解决方案。

当应用需要高性能、高可靠性的远程调用时，可以使用Dubbo。Dubbo是一种高性能的RPC框架，提供了完善的服务治理功能，包括负载均衡、服务降级、容错机制等。它支持多种传输协议和序列化方式，适合于复杂的分布式系统架构。

总的来说，如果应用采用了Spring Cloud微服务架构，可以优先选择Feign进行微服务间的调用；如果应用需要高性能、高可靠性的远程调用，可以选择Dubbo。

feign对比dubbo

在选择远程调用框架时，B端使用Feign而不是Dubbo的原因是因为B端需要调用的营销服务是通过Nacos作为注册中心进行注册的，而Dubbo无法与Nacos集成。因此，B端选择了Feign来通过REST接口方式进行调用。另一方面，C端具有较高的并发量，适合使用Dubbo协议，同时也可以将Nacos作为注册中心进行整合，因此C端选择了Dubbo来调用营销服务。总结而言，B端选择Feign而不是Dubbo主要是基于架构的需求和注册中心的差异。<span class="em">1</span><span class="em">2</span><span class="em">3</span>
#### 引用[.reference_title]
- *1* *2* *3* [电商项目之Feign与Dubbo技术选型](https://blog.csdn.net/qq_40634846/article/details/129091413)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v92^chatsearchT0_1"}}] [.reference_item style="max-width: 100%"]
[ .reference_list ]