文章目录
- 1 问题背景
- 2 前言
- 3 思路
- 4 Feign与Dubbo的区别
- 5 总结
- 6 真实案例
1 问题背景
电商项目，B端以consul作为注册中心。重构了一个营销服务，以Nacos作为注册中心。B端需要调用营销服务。关于远程调用框架，营销服务用了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。
