Dubbo 与 OpenFeign 介绍
区别和特点
OpenFeign和Dubbo都是用于构建分布式系统中的服务调用和远程通信的框架，但它们有一些区别和特点。
1、协议
Dubbo：
- 支持多传输协议(Dubbo、Rmi、http、redis等等)，可以根据业务场景选择最佳的方式。非常灵活。
- 默认的Dubbo协议：利用Netty，TCP传输，单一、异步、长连接，适合数据量小、高并发和服务提供者远远少于消费者的场景。
Feign：
- 基于Http传输协议，短连接，不适合高并发的访问。
2、负载均衡
Dubbo：
- 支持4种算法（随机、轮询、活跃度、Hash一致性），而且算法里面引入权重的概念。
- 配置的形式不仅支持代码配置，还支持Dubbo控制台灵活动态配置。
- 负载均衡的算法可以精准到某个服务接口的某个方法。
Feign：
- 只支持N种策略：轮询、随机、ResponseTime加权。
- 负载均衡算法是Client级别的。
3、容错策略
Dubbo：
- 支持多种容错策略：failover、failfast、brodecast、forking等，也引入了retry次数、timeout等配置参数。
Feign：
- 利用熔断机制来实现容错的，处理的方式不一样。
总结
OpenFeign和Dubbo各有其优点和适用场景。OpenFeign更适合于构建基于HTTP/REST的微服务架构，简化了接口定义和服务调用的过程，并与Spring Cloud生态系统紧密集成。Dubbo则是一个全功能的RPC框架，适合于构建高性能、分布式的服务架构，具备更丰富的服务治理和远程通信能力。选择使用哪个框架要根据具体需求、技术栈和架构设计来决定。
Dubbo 大文件传输 问题
单连接模型问题
除了内存占用问题之外，Dubbo（这里指 Dubbo 协议）的单连接模型也不适合文件传输。
Dubbo 协议默认是单连接的模型，也就是一个 provider 的所有请求都是用一个 TCP 连接。默认使用 Netty 来进行传输，而 Netty 中为了保证 Channel 线程安全，会将写入事件进行排队处理。那么在单连接下，多个请求都会使用同一个连接，也就是同一个 Channel 进行写入数据；当多个请求同时写入时，如果某个报文过大，会导致 Channel 一直在发送这个报文，其他请求的报文写入事件会进行排队，迟迟无法发送，连数据都没有发送过去，那么其他的 consumer 也自然会处于阻塞等待响应的状态中，一直无法返回了。
所以在单连接下，如果报文过大，将会导致 Netty 地写入事件处理阻塞，数据将无法及时发送至服务端，从而造成请求白白阻塞的问题。
那有的朋友可能会问，单连接模型缺点都这么大了， Dubbo 为什么还要采用单连接呢？
很简单，因为省资源，TCP 连接这样的资源可是很宝贵的，如果单连接可以满足绝大多数场景，那么也就完全没必要为每个请求准备一个连接。
总结
其实 Dubbo 不光是不适合传输文件，大报文场景下都不太合适，Dubbo 的设计更适合小业务报文的传输（默认报文大小只有8MB）。
所以如果有文件上传的场景，尽可能地用客户端直传的方式吧，节省资源又友好！
文章持续更新中、希望对各位有所帮助、有问题可留言 大家共同学习 !
