阿里云服务器负载均衡（阿里云服务器负载均衡怎么调）

今天给各位分享阿里云服务器负载均衡的知识，其中也会对阿里云服务器负载均衡怎么调进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、阿里云通过服务网格自动创建负载均衡一坑
• 2、阿里云自建k8s集群使用slb负载均衡
• 3、负载均衡SLB
• 4、负载均衡基本介绍
• 5、关于阿里云SLB（负载均衡）配置HTTPS证书一些记录
• 6、阿里云ECS服务器SLB负载均衡实践

阿里云通过服务网格自动创建负载均衡一坑

昨天晚上突然发现流量上不去。开始以为不会是负载均衡的规格问题，因为之前已经升级过。后来发现负载均衡链接数上不去，发现规格已经降低到未升级前的配置。查记录也未发现认为修改的痕迹，最后发现是server mesh 修改的配置，这时候才想起来昨天上午修改过virtual service配置。后来发现service mesh gateway的配置文件里带有最初负载均衡规格的配置，估计可能是修改virtual service时，刷新gateway的配置，使负载均衡配置恢复到了原本的规格。

阿里云自建k8s集群使用slb负载均衡

环境：

阿里云坑爹的文档，害我搞了3天才搞定

添加 --cloud-provider=external --provider-id=region_id.instance_id替换为上面获取到的id（provider-id是阿里云控制器用来识别ecs，添加路由表，添加负载均衡监听和虚拟服务器组）

不需要--hostname-override，会导致kubeadm join无法正常结束

（未验证）如果是已经加入集群的node，只修改kubectl并重启没用，估计可以直接修改node的spec，添加 providerID: cn-hongkong.i-xxxx

获取阿里云账户access_key，需要负载均衡和专用网络VPC路由表权限

官方资源文档：

需要修改下面3项

云控制器镜像版本目前是：cloud-controller-manager-amd64:v1.9.3.10-gfb99107-aliyun

有几个问题

注解文档：

注意！！！老版注解前缀为alicloud，很多网上的其他文档用的是新版前缀alibaba-cloud（坑爹）

将云控制器配置文件调整为ConfigMap挂载方式（推荐）

也可以按照官方文档创建etc/kubernetes/cloud-controller-manager.conf，改为下面data的内容

修改${ca_data}替换为下面的证书内容

修改${k8s_master_url} 为集群地址

安装

负载均衡SLB

为了应对高并发，我们引入了负载均衡，就是将原本需要一台服务器处理的业务，分配给了多台服务器进行处理，而分配的规则就是SLB算法。

SLB(server load balance)是负载均衡的缩写。

负载均衡主要有三种算法：

①轮训法

通过将用户的请求轮流分配给配置好的服务器进行解析

②随机法

通过随机因子分配给不同的服务器，通过分散性，达到均衡

③最小连接法

通过选择最少连接的服务器进行分配，就是能者多劳

负载均衡主要有三种实现方法：

①dns轮训

通过dns解析到不同的ip来进行负载均衡

②反向代理

一般通过nginx进行代理解析，服务请求先到达nginx代理服务器，然后又nginx进行转发

③NAT(LVS)

该技术通过一个地址转换网关将每个外部连接均匀转换为不同的内部服务器地址，因此外部网络中的计算机就各自与自己转换得到的地址上的服务器进行通信，从而达到负载均衡的目的.

目前阿里云提供的SLB服务还是很方便使用的，只需要登录管理后台，然后选择开通SLB服务，然后添加配置对应的ECS服务器就可以使用了。

负载均衡基本介绍

【负载均衡架构部分转自】 58沈剑 [架构师之路](

负载均衡： 是分布式系统架构设计中必须考虑的因素之一，它通常是指，将请求/数据【均匀】分摊到多个操作单元上执行，负载均衡的关键在于【均匀】

常见的负载均衡方案：

【客户端层】到【反向代理层】的负载均衡，是通过“DNS轮询”实现的：DNS-server对于一个域名配置了多个解析ip，每次DNS解析请求来访问DNS-server，会轮询返回这些ip，保证每个ip的解析概率是相同的。这些ip就是nginx的外网ip，以做到每台nginx的请求分配也是均衡的。

【反向代理层】到【站点层】的负载均衡，是通过“nginx”实现的。通过修改nginx.conf，可以实现多种负载均衡策略：

【站点层】到【服务层】的负载均衡，是通过“服务连接池”实现的。

上游连接池会建立与下游服务多个连接，每次请求会“随机”选取连接来访问下游服务。（也即是rpc框架实现的）

在数据量很大的情况下，由于数据层（db，cache）涉及数据的水平切分，所以数据层的负载均衡更为复杂一些，它分为“数据的均衡”，与“请求的均衡”。

数据的均衡是指 ：水平切分后的每个服务（db，cache），数据量是差不多的。

请求的均衡是指 ：水平切分后的每个服务（db，cache），请求量是差不多的。

（1）按照range水平切分

（2）按照id哈希水平切分

[图片上传中...(-6b2508-1561902875888-0)]

常见的负载均衡系统包括 3 种：DNS 负载均衡、硬件负载均衡和软件负载均衡。

硬件负载均衡是通过单独的硬件设备来实现负载均衡功能，这类设备和路由器、交换机类似，可以理解为一个用于负载均衡的基础网络设备。比如业界非常出名的F5

缺点：

（1）价格实在非常昂贵

（2）扩展性不强

软件负载均衡通过负载均衡软件来实现负载均衡功能，常见的有 Nginx 和 LVS。

nginx和F5：

nginx和lvs比较：

lvs：

ELB：

SLB：

题目：日活跃用户 1000 万的论坛的负载均衡集群，该如何设计呢？

（1）评估流量

1000万DAU，换算成秒级（一天12小时），平均约等于232。

考虑每个用户操作次数，假定10，换算成平均QPS=2320。

考虑峰值是均值倍数，假定5，换算成峰值QPS=11600。

考虑静态资源、图片资源、服务拆分等，流量放大效应，假定10，QPS 10=116000。

（2）容量规划

考虑高可用、异地多活，QPS 2=232000。

考虑未来半年增长，QPS*1.5=348000。

（3）方案设计

可以用三级导流：

第一级，DNS，确定机房，以目前量级，可以不考虑。

第二级，确定集群，扩展优先，则选Haproxy/LVS，稳定优先则选F5。

第三级，Nginx+KeepAlived，确定实例。

（4）架构图

接入层技术：

缺点：

优点：

缺点：

优点：

缺点：

缺点：

nginx毕竟是软件，性能比tomcat好，但总有个上限，超出了上限，还是扛不住。lvs就不一样了，它实施在操作系统层面；f5的性能又更好了，它实施在硬件层面；它们性能比nginx好很多，例如每秒可以抗10w，这样可以利用他们来扩容。

99.9999%的公司到这一步基本就能解决接入层高可用、扩展性、负载均衡的问题。 假设还扛不住的话，就要考虑使用硬件设备f5等。如果还是扛不住，那么只有DNS来扩容了。

水平扩展，才是解决性能问题的根本方案，能够通过加机器扩充性能的方案才具备最好的扩展性。 facebook，google，baidu的PV是不是超过80亿呢，它们的域名只对应一个ip么，终点又是起点，还是得通过DNS轮询来进行扩容：

比如购买了阿里云或者aws。那么基本会使用云厂商提供的负载均衡中间件，比如aws（elb）、阿里云（slb）。这个负载均衡软件可以认为是 lvs+keepalived的高可用负载均衡服务

后端的service有可能部署在硬件条件不同的服务器上：

1）如果对标最低配的服务器“均匀”分摊负载，高配的服务器的利用率不足；

2）如果对标最高配的服务器“均匀”分摊负载，低配的服务器可能会扛不住；

（1）通过“静态权重”标识service的处理能力

优点： 简单，能够快速的实现异构服务器的负载均衡。

缺点： 权重是固定的，无法自适应动态调整，而很多时候，服务器的处理能力是很难用一个固定的数值量化。

（2）通过“动态权重”标识service的处理能力

提问：通过什么来标识一个service的处理能力呢？

回答：其实一个service能不能处理得过来，能不能响应得过来，应该由调用方说了算。调用服务，快速处理了，处理能力跟得上；调用服务，处理超时了，处理能力很有可能跟不上了。

动态权重设计：

例如：

（1）设置一个阈值，超过阈值直接丢弃

（2）借助“动态权重”来实施过载保护

案例策略：

1）service的负载均衡、故障转移、超时处理通常是RPC-client连接池层面来实施的

2）异构服务器负载均衡，最简单的方式是静态权重法，缺点是无法自适应动态调整

3）动态权重法，可以动态的根据service的处理能力来分配负载，需要有连接池层面的微小改动

4）过载保护，是在负载过高时，service为了保护自己，保证一定处理能力的一种自救方法

5）动态权重法，还可以用做service的过载保护

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

因为业务背景问题，目前应用后端的接口和前端服务是放置在不同的服务器上，而前端页面现在说需要加上https,但是我们的前端页面目前请求应用后端的接口的时候使用的还是http，所以导致了，请求http的接口时候出现了异常！

如图示：

解决的办法就是，我们的也给需要给我们的应用接口加上对应的https支持！

之前已经给对应的接口的域名买好了对应的证书！

问题描述：

因为忘了，我们的应用接口的域名是指向了阿里云SLB上的服务器，所以一开始的时候是在后端进行配置相关的SSL，可是配置来配置还是无法生效！

请求的时候会说超时：

首先后端的集群的应用服务器NGINX的配置是：

后知后觉才记得，域名的指向的是负载服务器的IP，我们需要在负载层服务器那里进行配置。

于是乎打开了阿里云的负载均衡，查看一下对应的一些配置信息，

所以尝试了添加对应的新的监听处理！

添加基本配置：

配置对应的监控检查：

然后再配置对应的转发策略：

结果：

第I一次添加的时候，我开启了对应 使用虚拟服务组

导致下面的问题的提示（理论上其实应该是没影响的，暂且没继续尝试）：

并且访问对应的后端接口返回的是502：

因为对于http还是没有什么问题，所以排除了后端问题的可能性！

后来删除继续重新添加：

但是还是出现异常信息，

后来查阅各种资料，在阿里云的官方文档上有对应的排错步骤：

参考资料信息：

排查步骤

PS：

检查负载均衡状态，是否有后端ECS健康检查失败的情况，如果有健康检查失败，解决健康检查失败问题。

后来觉得应该有可能是原因是健康检查检查引起的问题异常：

，因为默认他应该是会在对应的server下的一个默认的路径去检查服务的情况，由于我没指定对应的检查URL地址，所有在转到80的时候就异常了！！

后来直接的关闭健康检查！就可以了！！

阿里云ECS服务器SLB负载均衡实践

负载均衡构建在原有网络结构之上，它提供了一种透明且廉价有效的方法扩展服务器和网络设备的带宽、加强网络数据处理能力、增加吞吐量、提高网络的可用性和灵活性。

拥有大量用户的企业，经常会面临如下的难题：在高并发的情况下，经常会导致服务器响应速度慢，严重的情况会直接导致服务器停止服务。此时，会导致企业的业务中断，影响客户的正常访问。

负载均衡应运而生

u需求：本次实验最低需求两台云服务器ECS/u

上图创建了两台云服务器ECS实例和一个负载均衡实例，它们各自拥有各自的弹性IP地址

在浏览器两个页面分别输入两台云服务器ECS的弹性IP访问

比较两台ECS的访问结果，发现部署的网站内容相同，只是显示的后端服务器IP不同。

在阿里云登陆界面选择用RAM用户登录

使用实验提供的 子用户名称 和 子用户名密码 登陆阿里云管理控制台

img src="" alt="4.登陆.png" style="zoom:50%;" /

img src="" alt="5.登陆.png" style="zoom:50%;" /

登录后点击左侧 导航栏的 产品与服务 选择 负载均衡

img src="" alt="6.png" style="zoom: 67%;" /

a. 在控制台点击左侧 实例管理 ，在右侧页面中的红框处看到负载均衡的 公网服务地址

该公网服务地址即为负载均衡实例的弹性IP地址

b.在浏览器上输入a的公网服务地址并访问

可见后端服务器IP尾数为131（ECS-2)，但当我们刷新一遍后，如下图

后端服务器IP尾数变为130(第二台ECS-1)

当我们不停的刷新，会发现后端服务器IP 实在这两台ECS的 内外地址 之间轮流转换

因为我们在第二步配置的两台ECS的权重是相同的

下一步我们试着改变两台ECS的权重不相同看看效果如何

a.进入控制台--选择负载均衡--实例管理--点击进入实例--默认服务器组，进入如下图所示

b.勾选两台服务器--点击修改权重

c.设置权重 30，90，效果如下图

d.在浏览器中，刷新多次 负载均衡服务地址 的页面，统计页面的 后端服务器IP 。

可以发现：每 4 次刷新，将有 3 次访问 权重 为 90 的 ECS实例， 1 次访问权重为 30 的 ECS实例。

用户可以根据实际情况调整负载均衡器的请求分发，一般将 配置高的服务器设置的权重调高 ， 配置较低的服务器设置的权重调低 。这样可以避免在高并发时，配置较低的服务器因为压力较大服务异常的发生。

a.实例管理界面---监听---修改监听配置

b.点击修改

c.开启会话保持、可选择修改会话保持超时时间

d.依次点击下一步，不修改

e. 再次在浏览器中输入 负载均衡 的 IP地址 ， 多次刷新 ，发现在会话保持的超时时间内请求 只会分发到某一台 ECS 上（究竟是哪一台 ECS 没有规定），时间超出后，重新按照权重比例分发。

a.进入实例

b.点击停止

img src="" alt="28.png" style="zoom:67%;" /

c.返回，显示如下图所示，ECS-2已关闭

d.在监听页面和实例管理页面，健康状态显示异常

e. 再次刷新浏览器中 负载均衡 的 IP地址 ，此时，请求发送到 健康检查状态 为 正常 的ECS-1上。

阿里云服务器负载均衡的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于阿里云服务器负载均衡怎么调、阿里云服务器负载均衡的信息别忘了在本站进行查找喔。