标签：Dubbo Feign 轮询 TCP RPC 连接 客户端
手动实现一个RPC框架系列文章
在上一篇章的文章中描述了一个PRC（远程调用服务）分为哪些部分，远程调用的流程是怎么样的，还简单的实现了一个RPC的过程，当然，这不是我们最终的实现框架，只是一个简单的流程而已。然而在完成第一篇章的文章后，我发现自己漏掉了一个非常重要的问题。
前面提到过，我是因为学习了尚硅谷SpringCloud课程，并且完成了尚医通项目后了解到Feign和远程调用的。那么既然Feign能实现远程调用，现在市面上常见的RPC框架还有Dubbo，那么Dubbo和Feign的区别是什么，我们什么时候适合用哪个框架，这些都是我在这一篇章会去学习然后记录的问题。
目录
前言
本篇文章先会介绍一下Dubbo和Feign，以及它们的区别，对比。同时在对比的过程中会引入一些计算机网络协议方面的内容，本人也是从各博客，网站上学习得知的，如有出错，还望不吝赐教指正我，谢谢各位。
一、Feign是什么？
Feign是Spring Cloud提供的一个声明式的伪Http客户端，它使得调用远程服务就像调用本地服务一样简单，只需要创建一个接口并添加一个注解即可。
Nacos注册中心很好的兼容了Feign，Feign默认集成了Ribbon，所以在Nacos下使用Fegin默认就实现了负载均衡的效果。
二、Dubbo是什么？
Dubbo是阿里巴巴开源的基于Java的高性能RPC分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。
Spring-cloud-alibaba-dubbo是基于SpringCloudAlibaba技术栈对dubbo技术的一种封装，目的在于实现基于RPC的服务调用。
三、对比
Feign和Dubbo都可以实现远程调用，他们都依赖注册中心，他们都支持负载均衡，服务熔断。
然而Feign是基于Http协议。服务提供者需要对外暴露Http接口供消费者调用（例如我们用@openFeign注解来标识远程调用服务的接口时，需要加@RequestMapping）服务粒度是http接口级的。通过短连接的方式进行通信，不适合高并发的访问。Feign追求的是简洁，少侵入（因为就服务端而言，在SpringCloud环境下，不需要做任何额外的操作，而Dubbo的服务端需要配置开放的Dubbo接口)。
至于Dubbo，Dubbo支持多传输协议(Dubbo、Rmi、http、redis等等)，可以根据业务场景选择最佳的方式，非常灵活。默认的Dubbo协议：利用Netty，TCP传输，单一、异步、长连接，适合数据量小、高并发和服务提供者远远少于消费者的场景。Dubbo通过TCP长连接的方式进行通信，服务粒度是方法级的。
从协议层选择看，Dubbo是配置化的，更加灵活。Dubbo协议更适合小数据高并发场景。
欸，不要急，肯定有人看到这里会有问题，长连接和短连接区别是什么，为什么基于短连接的Feign就不适合高并发的访问呢，为什么长连接的Dubbo就可以。
四、长连接和短连接
说到长连接和短连接，很多人都会想到Http长连接和短连接的相关知识，例如Http1.0默认使用短连接，Http1.1默认使用长连接呀之类的，但经过笔者学习和阅读一些文章之后，实际上Http根本不分长连接和短连接，或者说“ Http的长短连接，其实是在Tcp连接中实现的 ”。
HTTP协议的长连接和短连接，本质上是TCP协议的长连接和短连接。HTTP属于应用层协议，在传输层使用TCP协议，在网络层使用IP协议。 IP协议主要解决网络路由和寻址问题，TCP协议主要解决如何在IP层之上可靠地传递数据包，使得网络上接收端收到发送端所发出的所有包，并且接受顺序与发送顺序一致。TCP协议是可靠的、面向连接的。TCP才负责连接，只有负责传输的这一层才需要建立连接！！！！！
在HTTP/1.0中默认使用短连接。也就是说，客户端和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。当客户端浏览器访问的某个HTML或其他类型的Web页中包含有其他的Web资源（如JavaScript文件、图像文件、CSS文件等），每遇到这样一个Web资源，浏览器就会重新建立一个HTTP会话。
而从HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头加入这行代码（但要服务器和客户端都设置）：Connection:keep-alive
那么综合长短连接来说呢，Feign是短连接的，那我们面对高并发的请求的时候，每请求一次数据都要建立一次连接，那肯定就不适用了。所以，Feign和Dubbo都能实现远程调用的功能，但是要看我们具体的需求去使用哪个。
补充一点：
在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的TCP连接。也就是说在长连接情况下，多个HTTP请求可以复用同一个TCP连接，这就节省了很多TCP连接建立和断开的消耗。
Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接需要客户端和服务端都支持长连接。
五、长轮询，短轮询
既然前面已经提到了长连接和短连接，那么其实我们在实际应用开发的过程中，还会碰到长轮询和短轮询的选择，所以在这里也一并进行学习和记录啦。
首先我们想象一个业务场景，现在有一个商品正在销售（正常网购场景，并非秒杀）。商品的旁边要显示它的库存量，并且这个库存量是要时实变化的，那我们该怎么处理。
首先短轮询的方法，我们可以去编写一个JS函数，每一秒就去查询一次数据，然后把得到的结果在界面中渲染，进行刷新。我们使用短轮询的方法，所以每次去请求一次数据，都会建立一个连接，请求完毕再关闭连接，再请求，再建立，再关闭。
这种短轮询肯定是会造成网络资源的浪费的，因为如果有几万个用户，他就是在浏览界面，然后忘了关闭，也不下单，那就同时有几个万个请求在创建连接，关闭连接。。。
长轮询这个时候就出现了，其实长轮询和短轮询最大的区别是，短轮询去服务端查询的时候，不管库存量有没有变化，服务器就立即返回结果了。而长轮询则不是，在长轮询中，服务器如果检测到库存量没有变化的话，将会把当前请求挂起一段时间（这个时间也叫作超时时间，一般是几十秒）。在这个时间里，服务器会去检测库存量有没有变化，检测到变化就立即返回，否则就一直等到超时为止。
而对于客户端来说，不管是长轮询还是短轮询，客户端的动作都是一样的，就是不停的去请求，不同的是服务端，短轮询情况下服务端每次请求不管有没有变化都会立即返回结果，而长轮询情况下，如果有变化才会立即返回结果，而没有变化的话，则不会再立即给客户端返回结果，直到超时为止。
这样一来，客户端的请求次数将会大量减少（这也就意味着节省了网络流量，毕竟每次发请求，都会占用客户端的上传流量和服务端的下载流量），而且也解决了服务端一直疲于接受请求的窘境。
但是长轮询也是有坏处的，因为把请求挂起同样会导致资源的浪费，假设还是1000个人停留在某个商品详情页面，那就很有可能服务器这边挂着1000个线程，在不停检测库存量，这依然是有问题的。
因此，从这里可以看出，不管是长轮询还是短轮询，都不太适用于客户端数量太多的情况，因为每个服务器所能承载的TCP连接数是有上限的，这种轮询很容易把连接数顶满。哪怕轮询解决不了获取库存这个问题，但只要大家明白了长短轮询的区别，这就足够了。
六、Feign和Dubbo其他方面的区别
好了，言归正传，最后再介绍一些Feign和Dubbo在其他方面的区别。
负载均衡方面：
Feign默认使用Ribbon作为负载均衡的组件。
Dubbo和Ribbon（Feign默认集成Ribbon）都支持负载均衡策略，但是Dubbo支持的更灵活。
Dubbo和Ribbon对比：
Ribbon的负载均衡策略：随机、规则轮询、空闲策略、响应时间策略。
Dubbo的负载均衡策略：Dubbo支持4种算法，随机、权重轮询、最少活跃调用数、一致性Hash策略。而且算法里面引入权重的概念。
Dubbo可以使用路由策略，然后再进行负载均衡。
Dubbo配置的形式不仅支持代码配置，还支持Dubbo控制台灵活动态配置。
Dubbo负载均衡的算法可以精准到某个服务接口的某个方法，而Ribbon的算法是Client级别的。Ribbon需要进行全局配置，个性化配置比较麻烦。
容错机制方面：
Feign默认使用Hystix作为服务熔断的组件。Hystix提供了服务降级，服务熔断，依赖隔离，监控（Hystrix Dashboard）等功能。Feign是利用熔断机制来实现容错的，与Dubbo处理的方式不一样。
Dubbo支持多种容错策略，FailOver、FailFast、Failsafe、FailBack、Aviailable、Broadcast、Forking策略等，以及Mock。也引入了retry次数，timeout等配置参数。Dubbo自带了失败重试的功能。
总结
Dubbo支持更多功能、更灵活、支持高并发的RPC框架。
SpringCloud全家桶里面（Feign、Ribbon、Hystrix），特点是非常方便。Ribbon、Hystrix、Feign在服务治理中，配合Spring Cloud做微服务，使用上有很多优势，社区也比较活跃，看将来更新发展。
业务发展影响着架构的选型，当服务数量不是很大时，使用普通的分布式RPC架构即可，当服务数量增长到一定数据，需要进行服务治理时，就需要考虑使用流式计算架构。Dubbo可以方便的做更精细化的流量调度，服务结构治理的方案成熟，适合生产上使用，虽然Dubbo是尘封后重新开启，但这并不影响其技术价值。
如果项目对性能要求不是很严格，可以选择使用Feign，它使用起来更方便。
如果需要提高性能，避开基于Http方式的性能瓶颈，可以使用Dubbo。
Dubbo Spring Cloud的出现，使得Dubbo既能够完全整合到Spring Cloud的技术栈中，享受Spring Cloud生态中的技术支持和标准化输出，又能够弥补Spring Cloud中服务治理这方面的短板。
参考
微服务中远程调用Dubbo与Feign对比 - 悬铃木pp - 博客园 (cnblogs.com)
标签：Dubbo,Feign,轮询,TCP,RPC,连接,客户端 来源： https://blog.csdn.net/weixin_56032340/article/details/123619132
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。