标签：负载 场景 服务 Eureka 详解 均衡器 services SLB
本质上，Eureka 就是一个负载均衡器，可能有的人会说，它是一个服务注册中心，用来注册服务的，这种说法有点片面。
在这篇博客里，将尽可能循序渐进、图文并茂地回答下面的几个问题。至于 Eureka 的使用、配置、源码分析、集群配置等等，这些后续博客再补充。
- 为什么要用负载均衡器？
- 一个合格的负载均衡器是怎样的？
- mid-tier services 的负载均衡器？
- 为什么使用 Eureka？
为什么要用负载均衡器
那么，先从一个例子开始。
假设我有一个网上商城的项目，在项目初期，它是一个传统的单体应用，没有集群，没有微服务。显然，这个时候我不需要考虑所谓的负载均衡。
随着应用的推广，我的用户越来越多，当达到流量高峰时，服务器经常会扛不住。这样下去可不行，于是，我试着加了两台机器。现在，有了三台服务器，我不就能处理原来三倍的流量了吗？
想法是挺好的，但这需要一个前提：要让请求平摊到多台服务器上面，即实现简单的负载均衡。
那么，要怎么做才能将请求平摊到三台服务器呢？我尝试在 DNS 服务器加上两台新服务器的地址，不出所料，真的可以这么做。因为 DNS 会基于轮循负载算法返回地址，只要用户拿到每个地址的机会是均衡的，请求到我服务器也会是均衡的。于是，我的目的间接达到了。
一个合格的负载均衡器是怎样的
上面的方案看起来挺好的，我自己不需要增加多余的机器，就轻易实现了负载均衡。但是，我还是遇到了问题。
有一天，用户访问商城服务出现大量报错，原因是第三台服务器的服务突然挂掉了，但是 1/3 的请求还是落到这一台。因为一时排查不出问题的根源，而且重启没多久又会马上挂掉，我试着把这台服务器的地址从 DNS 上剔除出来。然而，另一个问题出现了，DNS 的更新并没有生效，我剔除了故障机器的地址，请求还是会落到这一台······
经历了这一回，我总算明白，单纯使用 DNS 做负载均衡还是不靠谱。一个合格的负载均衡器至少要做到：当部分服务出现故障时，自动将其屏蔽，当服务恢复后，再将屏蔽放开。显然，DNS 不能很好地满足。经过研究，我发现了 nginx、SLB、ALB 等等负载均衡器，它们都可以做到这一点。最后，我选择了 SLB 作为负载均衡器。
SLB 配置上要比传统的 nginx 简单很多，只要配置好监听就行。SLB 会检查后端服务器的健康状态，当后端某台服务器出现异常时，SLB 会自动将它隔离。 除此之外，它还有很多其他功能，这里就不再扩展了。
有人可能会问，既然要用负载均衡器，为什么不用 Eureka？其实，还真的不能用，原因后面会说到。我希望能够说明一点，一个工具再怎么优秀，它也有不适用的场合。
mid-tier services的负载均衡器
这里涉及到两个名词，有必要解释一下：
- edge services：向终端用户开放的服务。例如，用户通过浏览器直接访问到的接口都属于 edge services。
- mid-tier services：向其他后端服务开放的服务。有时，我们会说这种服务的调用是内部调用。
还是接着上面的例子。
我的商城业务变得越来越复杂，用户规模也越来越大，传统单体应用的缺点开始暴露出来：开发维护难以及数据库瓶颈。于是，我重构了整个项目，做法比较简单。显然，我开始搞微服务了。
但是，不管我怎么拆分，后端服务都不能做到完全独立，例如，处理订单业务时需要查询客户信息，促销活动有时也需要查询客户信息。这个时候，每个服务都需要开放出对应的 mid-tier services 供其他后端服务调用，另外，为了安全以及方便管理，这部分的服务需要和 edge services 区分开（不在同一个应用）。
这个时候，我需要一个针对 mid-tier services 的负载均衡器。
使用SLB做负载均衡器
理所当然地，我首先想到的还是 SLB。我可以再加一台 SLB，用于后端服务器请求 mid-tier services。当然，mid-tier services 之间也可以相互调用，只是图中不好表示出来。
使用Eureka做负载均衡器
后来，我发现了一个更好的方案，那就是 Eureka。和 SLB 不同，Eureka 是专门针对 mid-tier services 的负载均衡器。它主要包含三个部分：
- Eureka Server：存放服务名和服务对应地址的映射表，这就是我们常说的服务注册中心。开篇的时候我说过，“Eureka 是一个服务注册中心”这种说法是片面的，这里就能知道原因了吧。
- Eureka Client for application service：服务提供方，向 Eureka Server 注册自己的地址。例如，mid-tier services 所在应用就属于这一类。
- Eureka Client for application client：服务消费方，从 Eureka Server 获取 application service 的地址，并消费对应的服务，它包含内置的负载均衡器。例如，订单服务调用客户服务的 mid-tier services，那么订单服务就是一个 application client。
当然，这三个部分都可以进行横向的扩展。
下图只画出了订单服务调用客户服务的示例，其他的是一样的。
通过 Eureka 的结构可以知道，它并不适合作为 edge services 的负载均衡器，Eureka Client 需要具备和 Eureka Server 进行通信的能力，而终端用户并不具备这一点。
为什么使用Eureka
Eureka 作为一个专门针对 mid-tier services 的负载均衡器，相比 SLB 等，还是存在很多优点。
- Eureka 的服务注册是无状态。如果我新增了一百个新的服务，SLB 需要配置一百个对应的监听，而 Eureka Server 什么都不需要做，你只要注册上来就行，扩展起来非常方便。说的直白一点，SLB 知道自己将处理哪些服务，而 Eureka Server 不会事先知道。
- Eureka Server 挂了，Eureka Client 还可以正常消费服务。Eureka Client 本地会缓存服务地址，即使 Eureka Server 挂了，它还是能够正常消费服务。
以上基本讲完负载均衡器的内容，作为开篇，它让我们思考：一个工具的本质是什么？为什么我们要用它？不用它行不行？
标签：负载,场景,服务,Eureka,详解,均衡器,services,SLB 来源： https://www.cnblogs.com/johnvwan/p/15577485.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。