电商项目之Feign与Dubbo技术选型

Android_la

已于 2023-02-27 22:01:58 修改

阅读量1.8k

点赞数 2

分类专栏：解决方案文章标签： dubbo java 开发语言

于 2023-02-21 21:59:47 首次发布

本文链接：https://blog.youkuaiyun.com/qq_40634846/article/details/129091413

版权

解决方案专栏收录该内容

38 篇文章

订阅专栏

文章探讨了在一个电商项目中，B端使用Feign（基于Nacos注册中心）而C端使用Dubbo（基于Consul注册中心）的原因。主要区别在于Feign是SpringCloud的一部分，适合RESTful接口，而Dubbo更注重服务调用效率，适用于内部服务间通信。选择依据包括项目需求、框架特点、性能和生态因素。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

在这里插入图片描述

1 问题背景

电商项目，B端以consul作为注册中心。重构了一个营销服务，以Nacos作为注册中心。B端需要调用营销服务。关于远程调用框架，C端调用营销服务用了Dubbo，而B端用了Feign，笔者今天来研究下为什么要这么选，为什么B端不用Dubbo，要搞这样的差异化。

关于Feign和Dubbo的特点，参考自：

面试官：谈谈 Spring Cloud 与 Dubbo 有什么区别？
【dubbo系列】dubbo协议与http协议对比

2 前言

笔者阐述的都是真实案例场景，不是八股文或者面试题。如果作为后端开发技术人员，怎么独立思考去做决策呢？怎么做技术选型，要考虑什么东西？今天来理顺并总结一下。

3 思路

根据项目所处的环境去挖掘有什么痛点、冲突点
了解这两种框架的特点（优缺点）
选择适合项目的框架，不一味追求高大上

4 Feign与Dubbo的区别

初始定位不同：Feign是Spring Cloud中的一个组件，Spring Cloud定位为微服务架构下的一站式解决方案；Dubbo是SOA时代的产物，他关注服务的调用和治理。
生态环境不同：Spring Cloud依托于Spring平台，具备更加完善的生态体系；而Dubbo一开始只是做RPC远程调用，生态相对匮乏，现在逐渐丰富起来。
调用方式：Spring Cloud采用http协议做远程调用，接口一般是rest风格，比较灵活。Dubbo是采用Dubbo协议，接口一般是Java的Service接口，调用时采用Netty的NIO方式，性能较好。
报文格式不同：通过浏览器发送http://localhost:8080/index.html?userName=123的http请求，我们只需要请求index.html，并且携带userName=123，即可发现浏览器发送了很多数据，浏览器类型，cookie等等。通过dubbo客户端发送一个简单的dubbo请求，比如访问com.nacos.dubbo.service.IUserService接口中的getUserInfo方法并且入参为哈哈，实际只需发送调用的方法信息、入参等。http协议数据量要大很多。
传输方式不同：http协议是应用层协议，HTTP/1.0在交互之前需要进行tcp三次握手，握手成功之后才能进行数据传输。HTTP/1.1中，引入了重用连接的机制，就是在http请求头中加入Connection: keep-alive来告诉对方这个请求响应完成后不要关闭，下一次咱们还用这个请求继续交流。 dubbo默认使用socket长连接，即首次访问建立连接以后，后续网络请求使用相同的网络通道。

5 总结

dubbo协议追求的是数据量小，小则快，协议的设计也符合dubbo框框架的理念，适用与内部服务之间的数据交互。既然dubbo协议适用于服务之间的互相调用。spring cloud的feign内部为什么使用http协议呢？大概是架构的需要，例如服务A是java写的，服务B是python写的。这个时候dubbo协议就跑不通了。只能用http这种标准协议来交互。

6 真实案例

在这里插入图片描述
如上图所示，User服务往Consul注册中心注册，B端要调用User服务，必须使用Consul注册中心。因此B端无法整合Nacos注册中心进而使用Dubboo调用。因此选择了Feign，通过rest接口方式调用营销服务。而C端并发量高，适合使用发送的数据量很小的Dubbo协议，C端也可以整合Nacos作为注册中心，最终C端调用营销服务选择了Dubbo。