1,177
关于Dubbo和Feign其实两者都是基于服务的远程调用，这两种调用方式我基本都用过，在前些年那时候Dubbo比较火，微服务远程调用方面使用Dubbo比较多，并且也支持多种传输协议Dubbo、Rmi、http、redis等，如今已经慢慢演变成Dubbo3.0的版本，在看官方文档中得知，Dubbo3 在易用性、超大规模微服务实践、云原生基础设施适配、安全性等几大方向上进行了全面升级。
在现在因为Spring Cloud的出现，为了适应全家桶式的开发模式，在远程调用也在使用Spring Cloud - feign，为了更好的集成全家桶，后面又相继出现了open feign+okhttp3，让远程调用的效率更高，现在有了Cloud全家桶，难道dubbo就会一点一点地被淘汰么，让我一起来看下。
Dubbo
首先看下RPC，它是一种通信协议，是基于TCP的通信协议，在耦合程度上是比较强的，是服务端（provider）和消费端（consumer）的一种交互方式，在OSI的七层协议下，Dubbo属于传输层的协议，这里就不自己画图了，借一下官方文档的图。
可以清晰的看出，同步和异步都是支持的，包括服务端的异步执行和消费端的异步请求，服务的注册与监控。
Dubbo核心特性
基本就是这几大点
首先作为RPC框架，必须支持高性能的RPC通信，保证调用者每次调用能拿到正确的结果。
服务发现机制，Dubbo本身自带的Client-Based服务发现机制，但是一般企业都会集成独立的服务注册中心的组件，这里包括Nacos、Zookeeper、Conusl等，这里我用过的就这几个注册中心，官方推荐使用Zookeeper。
当然dubbo现在也可以适配原声的微服务，如适配Spring Cloud平台，相当于异构体系，这种架构我目前还未尝试过，后面有时间自己去尝试搭建下这种架构。
集成k8s平台，现如今在k8s很火热的时候，Dubbo也是适应微服务体系模式，将Dubbo服务可以注册到k8s列表。
动态扩展组件，dubbo在与其他微服务组件也实现了兼容，包括SPI扩展的方案。
⚠️：其实很多开发者都会去拿Spring cloud 和Dubbo做比较，这里其实是不太严谨的，Dubbo主要是实现是基于RPC的远程调用，通过Netty长连接进行TCP传输，而Spring Cloud的FeignClient远程调用只是一方面，更加注重的是全家桶里面的更多功能，所以一般来说只能Dubbo和Feign去做比较。
Feign
Feign作为全家桶的一员，提供着Rest服务，传输协议是http，主要作用在osi七层协议中的应用层，当然应用层其实更加面向与用户，与用户交互，用户通过访问客户端拿到想要的结果，剩下就是客户端打包客户的请求经过传输层来进行传输。
具体了解Feign的远程调用过程，可以参考之前的文章
juejin.cn/post/717804…
Feign的调用方式相比Dubbo还是比较简单的，通过@FeginClient注解即可。
虽说在性能上传输层要大于应用层的，但是Feign经过不断的演化，出现了升级版Open Feign支持SpringMVC的注解，OpenFeign默认是使用JDK的HttpURLConnection，没有连接池是很大的弊端，可以采用OkHttp3进行性能优化。
Okhttp3
Okhttp3是支持HTTP2和SPDY ，而SPDY就是基于TCP传输的，内设连接池，支持连接复用减少开销，并且提供了http响应缓存机制，可以避免不必要的网络请求，其他优点功能就不一一介绍了。
这么一看，OpenFeign+ Okhttp3其实也是非常不错的，也是现在使用较多的远程调用方式。
这么一看来，其实不论是Open feign还是Dubbo，还需要去根据业务长远发展的情况去考虑，但是Dubbo是支持高并发的RPC框架，并且有很多高级用法和特性，这里就不一一列举了，有兴趣的朋友可以去官方SDK手册去看下。
Spring Cloud全家桶可以快速将微服务构建起来，并且现在社区的活跃度较高，很多公司目前都在用Spring Cloud+Nacos+Docker容器化这套体系，总之各有千秋，没有最好的架构，只有针对业务场景去匹配最合适的架构，随着技术框架不断的升级，我们也需要针对自己的项目进行不断的优化升级。
