你好Ribbon一:SpringCloud微服务的客户端负载均衡利器

Posted 你好JAVA

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了你好Ribbon一:SpringCloud微服务的客户端负载均衡利器相关的知识,希望对你有一定的参考价值。

序言

欢迎大家来到“你好JAVA”系列课程,我是作者coredy。从本系列课程开始我们进入Netflix-Ribbon的学习。考虑到文章篇幅太长容易让大家犯困,所以后面的文章尽量“短小”精悍。笔者也是经常阅读技术博客 可谓是深有体会。记得有一段时间失眠 我就是每天晚上睡不着的时候拿出手机看看博客给治愈的。所以我写这个系列的文章的时候我也在犹豫 到底是以什么样的方式呈现给大家,是以文章还是视频?我纠结了很久最后决定文章,因为笔者确实不善言谈 所以一切有关说的还是逃避算了,但是后续有时间我会把专栏里面的文章录制成视频。我们这个系列的文章是研究源码的 肯定会有大量的源码贴出来。但是我会尽量加多注释 争取把我懂的都说明白了,不懂得或者写的有问题的还望大家在留言区不吝赐教。好了前面的“矫情”就到这吧,一看马上就不“短小”了还是就此停住吧。

回答一下很多小伙伴心中会有疑虑:当下学习Netflix Ribbon还有没有用?
有这个疑问无外乎两个原因:
其一,是Netflix Ribbon已经宣布项目进入维护阶段
其二,SpringCloud在最新的 2019年发布Hoxton.M2 版本中发布了Spring-Cloud-Loadbalancer作为替代Ribbon的解决方案
我从几个方面来回答这个问题:
第一,从应用的角度来讲目前生产项目中大部分SpringCloud应用基本上还是在用Ribbon。它在负载均衡这一块已经足够成熟
第二,仔细看过Spring-Cloud-Loadbalancer的小伙伴 其实不难发现 它还有一段路要走 但是,但是,但是 它毕竟是SpringCloud的嫡系 所以不管需要多长时间 最后一定会取代Ribbon这个是毫无疑问的 所以我们专栏最后还是会拿出一些时间来讲一下Spring-Cloud-Loadbalancer
第三,笔者认为我们学习任何一个开源组件不只是学习它如何使用,更重要的是深入去学习其设计思想并应用到我们的软件中去

负载均衡

我们知道每一个技术都有自己解决的一个问题领域,例如Feign解决了远超调用问题 让我们请求更easy、Hystrix提供了服务的熔断降级能力、Eureka提供了服务发现能力,那么Ribbon在微服务中的定位就是负载均衡。有人可能会说 what?负载均衡 我之前不是听说什么F5 、A10、ng、lvs等等哪有什么Ribbon。
没错F5,A10是从硬件层面来解决的,这些设备贵的离谱。ng、lvs为软件负载均衡。ribbon也是软件负载均衡 只不过是它工作在客户端。所以负载均衡(load balance 简称LB) 有分为服务端负载均衡和客户端负载均衡。

客户端负载均衡

客户端LB 那就是客户端维护着服务列表咯, 然后按照一定的策略分发请求到不同的服务器。目前的客户端负载还是比较少的,或许这就是为什么Ribbon一停更 SpringCloud急了的原因。如下图

服务端负载均衡

服务端LB 前面说了F5 A10这些硬件设备 ng,lvs这些软件负载 都是工作在服务端的。当请求某一个后端服务时 这个请求首先被转到负载设备上面,通过一定的负载策略分发到应用服务器。这个对客户端完全透明。如下图:

Ribbon简介

Ribbon官网(https://github.com/Netflix/ribbon) ,目前状态已停止更新 进入维护阶段。最新的发布版本2.7.18

不仅仅是负载

上面说了Ribbon是做客户端Lb的,但其实它的能力远不止这一块,作为一个第三方库提供了以下的功能:

  1. 负载均衡

  2. 容错能力

  3. 异步和反应模型中的多种协议(HTTP,TCP,UDP)支持

  4. 缓存和批处理

注意:除了负载均衡模块其他的忽略吧!

模块

Ribbon由多个组件组成,其中一些组件在内部用于生产,随着时间的推移,其中的一些组件已被非OSS解决方案所取代。这是因为Netflix开始着手于针对单一职责模块的RPC更加组件化的体系结构。因此,此时每个Ribbon功能区组件都会受到不同程度的关注。具体的组件和其使用情况如下:

  • ribbon-core:在生产中大量部署

  • ribbon-loadbalancer:在生产中大规模部署。

  • ribbon-eureka: 在生产中大规模部署

  • ribbon-evcache:不使用

  • ribbon-guice:不使用

  • ribbon-httpclient:基本不使用

  • ribbon-transport:不使用

  • ribbon:不使用
    所以从上面官网的叙述 我们其实只需要关心 ribbon-core、ribbon-loadbalancer、ribbon-eureka这几个模块即可。而这几个模块都是和负载均衡有关。本专栏先讲这几个模块然后再讲和SpringCloud的整合,先基础后应用。

官网说

即使对于在生产环境中部署的组件,我们也将它们包装在Netflix内部的http客户端中,并且由于它们已经稳定了一段时间,因此我们没有添加新功能。任何新功能都已添加到功能区顶部的内部包装器中(例如请求跟踪和指标)。我们尚未努力使Ribbon下的这些组件与Netflix无关。

认识到这些现实和缺陷,我们将Ribbon置于维护模式。这意味着,如果外部用户提交了大型功能请求,则在内部,我们不会将其优先级高。但是,如果有人独自工作并提交完整的请求请求,我们很乐意进行审核并接受。相反,我们的团队已开始在gRPC之上构建RPC解决方案。我们之所以进行这种过渡,主要有两个原因:多语言支持以及通过请求拦截器提供更好的可扩展性/可组合性。那就是我们当前的计划。

目前,我们定期为gRPC代码库做出贡献。为了帮助我们的团队在生产中迁移到基于gRPC的解决方案(并对其进行测试),我们还添加了负载平衡和发现拦截器,以实现功能区与Ribbon和Eureka提供的功能对等。拦截器目前在Netflix内部。当我们达到那种信心时,我们希望开源这种新方法。我们预计这种情况不会在2016年第三季度之前发生。

Ribbon和Spring-Cloud-Loadbalancer

前面简单的聊了一下Spring-Cloud-Loadbalancer,其实他的发展史是这样的:

  1. 2017年开始尝试开发spring-cloud-loadbalancer 替代Ribbon,项目托管在spring-cloud-incubator孵化器

  2. 经过N个月的不维护,突然把项目标记成归档 迁移到了spring-cloud-commons了

  3. 之后随着spring-cloud-commons工程版本一起发布

  4. SpringCloud Hoxton.M2 是第一个负载均衡器客户端的版本,作为Netflix Ribbon的替代方案。

在文章的一开始也说了 其实Spring-Cloud-Loadbalancer作为Spring的嫡长子 总有一天会完全替代Ribbon,只是时间问题。所以大家也不用担心 我们在专栏的最后几篇文章也会和各位小伙伴一起对Spring-Cloud-Loadbalancer进行探讨学习。

结束语

Ribbon的介绍总算是完了,每次写博客的时候最害怕的就是这种啰里啰嗦的话语。总体来讲还是不用担心学完没有意义。到目前为止客户端LB这一块还没有哪一个组件能和Ribbon媲美。再说了 我们不是还要写SCLB的吗。

以上是关于你好Ribbon一:SpringCloud微服务的客户端负载均衡利器的主要内容,如果未能解决你的问题,请参考以下文章

微服务架构SpringCloud之Ribbon

SpringCloud微服务负载均衡器Ribbon

springcloud 微服务Spring Cloud Ribbon 负载均衡使用策略详解

SpringCloud微服务负载均衡器Ribbon

微服务-SpringCloud学习系列:负载均衡Ribbon

微服务架构整理-(六SpringCloud实战之Ribbon)