序言

欢迎大家来到“你好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的吗。