slb配置详解

slb配置详解

我们一起来快速认识一下，负载均衡——SLB。负载均衡SLB是将访问流量根据转发策略分发到后端多台云服务器（ECS实例）的流量分发控制服务。

包含两种含义：一是通过流量分发，扩展应用系统的服务能力；二是消除单点故障，提高应用系统的可用性。

应用场景我们具体来看一看它的使用场景。第一个使用场景的是用于高访问量的业务。当你的应用访问量非常大，单台的服务器已经无法承载这个访问量的时候，就可以使用负载均衡，将流量分发到不同的服务器上去。第二个场景是横向扩张系统。

当你已经使用了负载均衡，在业务有波动时可以在后端非常方便的添加和减少ECS来调整自己应用的服务能力。第三个应用场景是消除单点故障。当我们在使用负载均衡时，后端有多台ECS在同时工作的。

一旦其中一台ECS上的应用发生了故障，那么负载均衡会通过一个健康检查的机制来及时的发现这个故障，并且能屏蔽对这台ECS的流量转发，然后将用户的请求转发到另一台正常工作的ECS实例上。同城的容灾阿里云负载均衡可以实现同地域多可用区之间同地域容灾，当主可用区出现故障是，可以在短时间内切换到另一备用可用区，以恢复服务能力。同时，主可用区恢复访问时，它会自动切换到主可用区。

跨地域容灾跨地域容灾通过云解析做智能DNS，将域名解析到不同地域的负载均衡实例地址下，以实现全局负载均衡，当某个地域出现不可用时，暂停对应解析即可实现所有用户访问不受影响。配置负载均衡下面我们来演示一下负载均衡该如何去配置。首先要做好准备工作，我们需要开通一台负载均衡实例和与负载均衡同一个地域的两台ECS服务器。

创建好以后，我们就可以在负载均衡的控制台看到这样一台实例了。接下来，我们要给这个负载均衡创建一个监听。“监听”可以简单的理解为对应后端服务器里面的一个应用，比如一个网站我们来点击监听，然后点击添加监听。假设我们的后端服务器里面有一个http的网站前端协议端口，我们可以将前后端协议端口TCP都写成80，然后根据自己的需要来选择调度算法，其实就是流量的转发方式。

下一步是健康检查，我们可以选择TCP方式。健康检查端口会默认的和后端服务器的端口保持一致，直接确认就好了。现在，一个监听就配置好了。接下来要去规定这台负载均衡的后端服务器是哪些。

点击后端服务器，然后点击未添加服务器，将我们刚才创建的两台服务器勾选，然后批量添加就可以了。这里有一个权重需要大家注意一下，这里的权重就是一个比例的概念，如果两台服务器写的都是100，流量将会以1:1的方式被转发到后端的两台服务器上。

负载均衡SLB

在软件系统的架构设计中，对集群的负载均衡设计是作为高性能系统优化环节中必不可少的方案。负载均衡本质上是用于将用户流量进行均衡减压的，因此在互联网的大流量项目中，其重要性不言而喻。

早期的互联网应用，由于用户流量比较小，业务逻辑也比较简单，往往一个单服务器就能满足负载需求。

随着现在互联网的流量越来越大，稍微好一点的系统，访问量就非常大了，并且系统功能也越来越复杂，那么单台服务器就算将性能优化得再好，也不能支撑这么大用户量的访问压力了，这个时候就需要使用多台机器，设计高性能的集群来应对。 那么，多台服务器是如何去均衡流量、如何组成高性能的集群的呢？ 此时就需要请出 「负载均衡器」 入场了。 负载均衡（Load Balancer）是指把用户访问的流量，通过「负载均衡器」，根据某种转发的策略，均匀的分发到后端多台服务器上，后端的服务器可以独立的响应和处理请求，从而实现分散负载的效果。负载均衡技术提高了系统的服务能力，增强了应用的可用性。

目前市面上最常见的负载均衡技术方案主要有三种： 基于DNS负载均衡 基于硬件负载均衡 基于软件负载均衡 三种方案各有优劣，DNS负载均衡可以实现在地域上的流量均衡，硬件负载均衡主要用于大型服务器集群中的负载需求，而软件负载均衡大多是基于机器层面的流量均衡。在实际场景中，这三种是可以组合在一起使用。下面来详细讲讲： 基于DNS负载均衡 基于DNS来做负载均衡其实是一种最简单的实现方案，通过在DNS服务器上做一个简单配置即可。

其原理就是当用户访问域名的时候，会先向DNS服务器去解析域名对应的IP地址，这个时候我们可以让DNS服务器根据不同地理位置的用户返回不同的IP。比如南方的用户就返回我们在广州业务服务器的IP，北方的用户来访问的话，我就返回北京业务服务器所在的IP。 在这个模式下，用户就相当于实现了按照「就近原则」将请求分流了，既减轻了单个集群的负载压力，也提升了用户的访问速度。

使用DNS做负载均衡的方案，天然的优势就是配置简单，实现成本非常低，无需额外的开发和维护工作。 但是也有一个明显的缺点是：当配置修改后，生效不及时。这个是由于DNS的特性导致的，DNS一般会有多级缓存，所以当我们修改了DNS配置之后，由于缓存的原因，会导致IP变更不及时，从而影响负载均衡的效果。

另外，使用DNS做负载均衡的话，大多是基于地域或者干脆直接做IP轮询，没有更高级的路由策略，所以这也是DNS方案的局限所在。 基于硬件负载均衡 硬件的负载均衡那就比较牛逼了，比如大名鼎鼎的 F5 Network Big-IP，也就是我们常说的 F5，它是一个网络设备，你可以简单的理解成类似于网络交换机的东西，完全通过硬件来抗压力，性能是非常的好，每秒能处理的请求数达到百万级，即 几百万/秒 的负载，当然价格也就非常非常贵了，十几万到上百万人民币都有。 因为这类设备一般用在大型互联网公司的流量入口最前端，以及政府、国企等不缺钱企业会去使用。一般的中小公司是不舍得用的。

采用 F5 这类硬件做负载均衡的话，主要就是省心省事，买一台就搞定，性能强大，一般的业务不在话下。而且在负载均衡的算法方面还支持很多灵活的策略，同时还具有一些防火墙等安全功能。但是缺点也很明显，一个字：贵。 基于软件负载均衡 软件负载均衡是指使用软件的方式来分发和均衡流量。

软件负载均衡，分为7层协议 和 4层协议。 网络协议有七层，基于第四层传输层来做流量分发的方案称为4层负载均衡，例如 LVS，而基于第七层应用层来做流量分发的称为7层负载均衡，例如 Nginx。这两种在性能和灵活性上是有些区别的。 基于4层的负载均衡性能要高一些，一般能达到 几十万/秒 的处理量，而基于7层的负载均衡处理量一般只在 几万/秒 。

基于软件的负载均衡的特点也很明显，便宜。在正常的服务器上部署即可，无需额外采购，就是投入一点技术去优化优化即可，因此这种方式是互联网公司中用得最多的一种方式。 上面讲完了常见的负载均衡技术方案，那么接下来咱们看一下，在实际方案应用中，一般可以使用哪些均衡算法？ 轮询策略 负载度策略 响应策略 哈希策略 下面来分别介绍一下这几种均衡算法/策略的特点： NO.1—— Random 随机 这是最简单的一种，使用随机数来决定转发到哪台机器上。

优点：简单使用，不需要额外的配置和算法。 缺点：随机数的特点是在数据量大到一定量时才能保证均衡，所以如果请求量有限的话，可能会达不到均衡负载的要求。 NO.2—— Round Robin 轮询 这个也很简单，请求到达后，依次转发，不偏不向。

每个服务器的请求数量很平均。 缺点：当集群中服务器硬件配置不同、性能差别大时，无法区别对待。引出下面的算法。 NO.3—— Weighted Round Robin 加权轮询 这种算法的出现就是为了解决简单轮询策略中的不足。

在实际项目中，经常会遇到这样的情况。 比如有5台机器，两台新买入的性能等各方面都特别好，剩下三台老古董。这时候我们设置一个权重，让新机器接收更多的请求。

物尽其用、能者多劳嘛！ 这种情况下，“均衡“就比较相对了，也没必要做到百分百的平均。 NO.4—— Least Connections 最少连接 这是最符合负载均衡算法的一个。需要记录每个应用服务器正在处理的连接数，然后将新来的请求转发到最少的那台上。 NO.5—— Source Hashing 源地址散列 根据请求的来源ip进行hash计算，然后对应到一个服务器上。

之后所有来自这个ip的请求都由同一台服务器处理。

关于阿里云SLB（负载均衡）配置HTTPS证书一些记录

因为业务背景问题，目前应用后端的接口和前端服务是放置在不同的服务器上，而前端页面现在说需要加上https,但是我们的前端页面目前请求应用后端的接口的时候使用的还是http，所以导致了，请求http的接口时候出现了异常！ 如图示： 解决的办法就是，我们的也给需要给我们的应用接口加上对应的https支持！ 之前已经给对应的接口的域名买好了对应的证书！ 问题描述： 因为忘了，我们的应用接口的域名是指向了阿里云SLB上的服务器，所以一开始的时候是在后端进行配置相关的SSL，可是配置来配置还是无法生效！ 请求的时候会说超时： 首先后端的集群的应用服务器NGINX的配置是： 后知后觉才记得，域名的指向的是负载服务器的IP，我们需要在负载层服务器那里进行配置。 于是乎打开了阿里云的负载均衡，查看一下对应的一些配置信息， 所以尝试了添加对应的新的监听处理！ 添加基本配置： 配置对应的监控检查： 然后再配置对应的转发策略： 结果： 第I一次添加的时候，我开启了对应 <使用虚拟服务组> 导致下面的问题的提示（理论上其实应该是没影响的，暂且没继续尝试）： 并且访问对应的后端接口返回的是502： 因为对于http还是没有什么问题，所以排除了后端问题的可能性！ 后来删除继续重新添加： 但是还是出现异常信息， 后来查阅各种资料，在阿里云的官方文档上有对应的排错步骤： 参考资料信息： https://help.aliyun.com/knowledge_detail/55201.html?spm=a2c4g.11186623.6.714.K0jKZY https://help.aliyun.com/knowledge_detail/55207.html?spm=a2c4g.11186623.6.721.FWDfvM 排查步骤 PS： 检查负载均衡状态，是否有后端ECS健康检查失败的情况，如果有健康检查失败，解决健康检查失败问题。

负载均衡进阶：SLB常见问题解决方法

摘要： 在由云栖社区和阿里云网络团队联合主办的2017阿里云网络技术在线高峰论坛上，阿里云技术专家添毅分享了网络产品部根据客户和阿里云运维的反馈提炼出的几大最主要和最常见的在使用SLB产品中发生的问题，并为大家介绍了针对这些常见问题的相应处理方法。摘要： 在由云栖社区和阿里云网络团队联合主办的2017阿里云网络技术在线高峰论坛上，阿里云技术专家添毅分享了网络产品部根据客户和阿里云运维的反馈提炼出的几大最主要和最常见的在使用SLB产品中发生的问题，并为大家介绍了针对这些常见问题的相应处理方法。

想知道如何借助SLB构建高可用系统以及健康检查是如何实现的，本文不容错过！ 本文内容根据演讲嘉宾分享视频以及PPT整理而成。

本次的分享将会主要围绕以下5个部分 基本概念回顾 如何构建高可用系统 选择性能共享型还是性能保障型实例 为什么健康检查异常 为什么负载不均衡 一、基本概念回顾 SLB是什么 SLB是阿里云推出的一款云负载均衡服务，其主要针对于多台云服务器进行流量分发，能够将业务流量分发到由多台云服务器所组成的后端服务器池上去，以此来提升系统的处理能力。负载均衡所解决的问题主要包括两点：第一点，SLB能够消除系统的单点故障，这是因为SLB的后面是由多台云服务器组成的服务器池，那么当其中某一台服务器出现故障的时候并不会影响整个系统的可服务性。第二点，由于后端的云服务器能够横向地进行扩展，所以也具有为海量业务提供服务的能力。那么，为什么要使用云上的负载均衡呢？这是因为云上负载均衡主要有这样的几个特点：高可靠、高性能、低成本、安全性、易用性。

SLB基本组件 阿里云的SLB主要包括了三个基本组件，这里也进行简单地介绍。第一个基本组件就是实例，每个实例都唯一地标识了云负载均衡器，并且每个实例都对应一个VIP，VIP唯一地标识了负载均衡实例，也是负载均衡对外提供服务的地址。第二个组件是监听，监听是由VIP+端口号来唯一标识的，一个监听中包含用户定制的负载均衡策略和转发规则。

最后一个基本组件就是后端挂载的服务器，也就是云服务器ECS，负责处理真正的业务请求。 二、如何构建高可用系统 多层次的高可用 如下图所示，阿里云的负载均衡是从四个层面上去构建高可用的。从底层往上层看，分别是应用级别的高可用、集群级别的高可用、可用区级别(AZ)的高可用以及地域级别(Region)的高可用。

应用级别的高可用主要是通过针对SLB后端的ECS实例的健康检查来实现的。当SLB发现后端不健康的或者不能正常工作的ECS的时候，会将这些不健康的ECS从SLB的转发路径中剔除掉，保证业务流量能够转发到正常的工作服务器当中。集群级别的高可用主要是通过集群中LVS机器间的session同步来保障任何一个用户的业务会话都能够在所有的LVS机器上是相互同步的，当其中某一台LVS出现故障时，可以由其他的LVS来接替出现故障的机器的工作。

同时，由于会话保持的存在，用户的业务是不会发生中断的。对于可用区级别的高可用和地域级别的高可用，在本文的后面会进行更加详细的介绍。 细说可用区级别容灾 这里详细地介绍一下可用区级别的容灾。可用区级别容灾的设计初衷是在当一个可用区出现重大灾情的时候，比如整个可用区的机房发生了掉电、光缆出现了中断、整个可用区机房中所有的物理机都无法正常工作的时候，也就是整个可用区都宕掉了的情况下，能够由备可用区来继续提供服务，这就是可用区级别容灾的设计初衷。

可用区级别的容灾并不是说某一个可用区中的某一个实例或者是某几个实例出现了故障就会发生可用区的切换，实例自动从可用区A切换到可用区B，这是一个比较常见的误区。而针对于这样的误区，阿里云也建议用户在构建可用区级别的高可用的时候采取以下两个步骤： 首先，建议用户在SLB实例的后端尽可能地去挂载多个可用区的ECS实例。SLB能够支持跨可用区地挂载ECS云服务器，这样可以避免某个可用区的ECS都出现故障的情况下，还有其他可用区的ECS能够接替工作，虽然跨可用区挂在ECS会存在大约2毫秒左右的延迟，但是却能够大大地提升服务的可用性。 第二步就是针对于一些特别重要的业务，建议在不同的可用区分别地去购买SLB的实例。

比如在可用区A和可用区B各自购买一个SLB实例，在此基础之上再使用全球负载均衡GSLB来进行实例间的调度。 跨地域容灾的实现 跨地域容灾这一部分与上面介绍的可用区级别容灾的第二步非常相似，也是借助于GSLB产品实现的，GSLB即 智能DNS实现了针对于后端的健康检查、路由调度的优化功能，能够实现在地域之间的负载均衡实例的调度。关于这部分的更详细的内容请参考：全球负载均衡跨地域容灾解决方案(https://promotion.aliyun.com/ntms/act/globalslb.html)。 三、选择性能共享型还是性能保障型实例 共享型vs保障型-WHY保障型 在如今这个共享经济的时代，像滴滴打车这样的模式是非常火的。

但是即便是有了滴滴打车，但是还有人会去买车，这是因为会出现如下两个大家可能曾经都碰到过的场景： 早晚高峰叫不到车？雨雪天气路边冻成狗？还大幅提价？ 假期想远离尘嚣，找个僻静旷野放空自我，叫个滴滴？也许有去，但保证无回！ 所以说共享和保障都是客户的需求。出于对于类似需求的考虑，阿里云的负载均衡也推出了性能保障型实例。以前所推出的SLB共享型实例是因为性能指标没有办法实现隔离，因为所有的共享型实例都处于同一个大共享资源池中，所以在高峰期的时候就会出现资源的争抢，这样就无法满足对于性能具有刚性需求的大客户的诉求。

除此之外，还有一些体量特别大的超级用户，他们对于性能的要求会是非常高的，但是由于共享型实例无法做到性能隔离，也支持不了大颗粒度的性能指标，所以也无法完成这样的工作。因此，阿里云推出了性能保障型的负载均衡实例。 超强性能 保障型实例的性能规格如上图所示，其并发连接数最大可以达到500万，每秒的新建链接数(CPS)可以达到50万，针对于七层负载均衡系统的QPS可以达到10万。

除此之外，性能保障型实例还具有以下的特点： 超强HTTPS性能。 性能保障型实例针对于七层系统，特别是HTTPS的业务进行了优化，实现了高性能硬加解卡，并且能够实现使HTTPS的业务单实例可达10万QPS。 超大并发连接数。 性能保障型实例的单实例的并发连接数可达500万，所以其可承载物联网场景的下海量连接，可以支撑共享自行车、智能手表等存在特别大量长连接的场景。

共享型实例平滑升级。 原有的共享型实例可以平滑升级至性能保障型实例，而无需更换VIP。 完善的业务监控系统。

在推出性能保障型实例之后，因为每个实例都有相应的性能规格和性能指标，所以阿里云也为用户提供了完整的业务指标监控系统，并支持电话、短信、钉钉企业群等方式的告警。 性能规格 上图所展现的是阿里云SLB性能保障型实例的规格参数。图中的最后两行规格7、8默认在控制台上是无法购买的，目前只针对企业级用户，而且需通过客户经理申请后，通过白名单开放。 如何选择规格 对于保障型实例而言，主要有如下几个性能指标： 最大连接数：一个实例可承载的最大连接数。

新建连接数：CPS表示一个实例每秒可以新建的链接数。 每秒查询数：QPS表示一个实例7层的像HTTP或者HTTPS系统的吞吐量。 通常一个4层SLB的性能好坏由最大连接数和新建连接数来衡量，它们表示了一个SLB系统的并发能力和处理突发连接的能力。

通常一个7层SLB的性能好坏主要由QPS决定，QPS表示了一个7层系统的吞吐量。这里需要注意的是QPS是7层独有概念。虽然每个规格都定义了三个性能指。