微服务RPC框架:Feign和Dubbo

简介: 微服务RPC框架:Feign和Dubbo

一、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中服务治理这方面的短板。



相关实践学习
部署高可用架构
本场景主要介绍如何使用云服务器ECS、负载均衡SLB、云数据库RDS和数据传输服务产品来部署多可用区高可用架构。
负载均衡入门与产品使用指南
负载均衡(Server Load Balancer)是对多台云服务器进行流量分发的负载均衡服务,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。 本课程主要介绍负载均衡的相关技术以及阿里云负载均衡产品的使用方法。
相关文章
|
21天前
|
监控 负载均衡 Dubbo
Dubbo 框架揭秘:分布式架构的精髓与魔法【一】
Dubbo 框架揭秘:分布式架构的精髓与魔法【一】
16 0
|
21天前
|
负载均衡 Dubbo Java
Dubbo 3.x:探索阿里巴巴的开源RPC框架新技术
随着微服务架构的兴起,远程过程调用(RPC)框架成为了关键组件。Dubbo,作为阿里巴巴的开源RPC框架,已经演进到了3.x版本,带来了许多新特性和技术改进。本文将探讨Dubbo 3.x中的一些最新技术,包括服务注册与发现、负载均衡、服务治理等,并通过代码示例展示其使用方式。
32 9
|
2月前
|
Dubbo Java 应用服务中间件
阿里巴巴资深架构师深度解析微服务架构设计之SpringCloud+Dubbo
软件架构是一个包含各种组织的系统组织,这些组件包括Web服务器,应用服务器,数据库,存储,通讯层),它们彼此或和环境存在关系。系统架构的目标是解决利益相关者的关注点。
|
4天前
|
XML JSON Java
RPC框架之Thrift—实现Go和Java远程过程调用
RPC框架之Thrift—实现Go和Java远程过程调用
25 1
|
21天前
|
负载均衡 监控 Dubbo
探秘Dubbo Registry:微服务架构的核心【十二】
探秘Dubbo Registry:微服务架构的核心【十二】
12 0
|
24天前
|
存储 Dubbo 应用服务中间件
SpringCloud | Dubbo 微服务实战——注册中心详解
SpringCloud | Dubbo 微服务实战——注册中心详解
|
1月前
|
负载均衡 Dubbo Java
Dubbo 第一节_ Dubbo框架介绍与手写模拟Dubbo 第二节_ Dubbo的基本应用与高级应用
官⽹地址:http://dubbo.apache.org/zh/docs/v2.7/user/examples/generic-service/官⽹地址:http://dubbo.apache.org/zh/docs/v2.7/user/examples/local-mock/官⽹地址:http://dubbo.apache.org/zh/docs/v2.7/user/examples/async-call/
|
1月前
|
Cloud Native Dubbo 应用服务中间件
Apache Dubbo 下一代云原生微服务挑战赛启动报名!五大赛题 50 万奖金池
Apache Dubbo 下一代云原生微服务挑战赛启动报名!五大赛题 50 万奖金池
|
1月前
|
Prometheus 监控 Cloud Native
SpringCloud微服务实战——搭建企业级开发框架(四十五):【微服务监控告警实现方式二】使用Actuator(Micrometer)+Prometheus+Grafana实现完整的微服务监控
无论是使用SpringBootAdmin还是使用Prometheus+Grafana都离不开SpringBoot提供的核心组件Actuator。提到Actuator,又不得不提Micrometer,从SpringBoot2.x开始,Actuator的功能实现都是基于Micrometer的。
|
1月前
|
Dubbo Java 应用服务中间件
【从零开始学微服务】07.微服务常用的开发框架
大家好,欢迎来到万猫学社,跟我一起学,你也能成为微服务专家。
34 1

相关产品

  • 云迁移中心