干货 | 京东云应用负载均衡（ALB）多功能实操

应用负载均衡（Application Load Balancer，简称ALB）是京东云自主研发的一款七层负载均衡产品，主要面向HTTP和HTTPS流量的WEB应用程序，提供灵活的功能配置。应用负载均衡在请求级别运行，能够为应用层业务提供更加出色的服务。

1、实操说明

自动伸缩功能将搭配京东云弹性伸缩产品与云主机进行实操，而后经过京东云应用型负载均衡（ALB）进行请求的分发；

会话保持/3种调度策略/健康检查功能将会利用京东云应用型负载均衡支持原生容器的特性进行实操；

2、环境搭建

1. 新建应用负载均衡（ALB）

打开京东云控制台：https://console.jdcloud.com/ 在左侧导航中找到网络-负载均衡，如图在华北-北京新建应用型负载均衡实例

如图，选择应用负载均衡后，点击肯定

配置以下：

• 计费类型：按配置

• 地域和可用区：华北-北京、可用区选择所有

• 网络：选择本身建立的私有网络，安全组开放所有端口（主要用于测试，生产环境请按照实际状况开放特定端口）

• 带宽：1Mbps

• 名称：alb_test

在负载均衡产品控制台点击上述咱们建立的应用型负载均衡实例alb_test

点击虚拟服务器组-新建虚拟服务器组

分组名称server_group（暂不添加后端服务器实例）

2. 制做自定义镜像

为方便后续操做，本步骤咱们须要有一个安装有Nginx服务的Centos 7.4的自定义镜像

首先建立云主机（制做完就能够删除了）；

制做自定义镜像环境建议配置以下：

• 计费类型：按配置

• 地域：华北-北京，可用区随意

• 镜像：官方-Centos 7.4 64位

• 规格：通用 标准型 1核4GB

• 存储：默认

• 网络：选择本身建立的私有网络，为方便测试，安全组选择默认安全组开放所有端口

• 带宽：1Mbps

• 名称：buildimg（自定义）

建立完云主机后，SSH远程链接，执行以下脚本

安装Nginx+PHP服务脚本：

1\wget  -O - https://pocenv-hcc.s3.cn-north-1.jdcloud-oss.com/JDCloud_LNP_test_Marin.Han.sh | bash

脚本执行完成后，咱们开始制做镜像，在云主机实例控制台找到咱们建立的云主机将其中止

中止成功后，咱们点击右侧更多选项，点击制做镜像

信息以下：

• 名称：LNP_Centos7

• 描述：包含Nginx+PHP的Centos7.4 64位镜像

定义镜像建立完成后，咱们上面建立的云主机就能够删除了

云主机删除成功后，其绑定的公网IP不会被自动删除，咱们须要手动删除，在左侧导航网络-私有网络-弹性公网IP，找到对应的公网IP删除

3. 新建弹性伸缩

在京东云控制台找到弹性伸缩产品页面，找到启动配置选项，在华北-北京地域建立启动配置，配置信息以下：

• 配置名称：JAS_test

• 地域：华北-北京

• 镜像类型：私有

• 私有镜像：选择咱们上面建立的私有镜像LNP_Centos7

• 规格类型：1核4GB

• 存储：默认

• 带宽：点击暂不购买

完成启动配置的建立后，左侧点击伸缩组，一样在华北-北京区域建立伸缩组，配置信息以下：

• 名称：JAS_group

• 初始实例数：1，在1-2个实例之间进行扩展

• 启动配置：选择上面建立好的启动配置

• 选择网络：选择你建立的VPC网络（选择你上面建立负载均衡所在的VPC）

• 安全组：为方便测试，选择默认安全组开放所有端口

• 支持可用区：选择所有可用区

• 移出策略：为效果明显，咱们选择移出最先建立的云主机（默认移出策略：移出指定数量云主机并让组内剩余云主机在物理位置上尽量均衡分布。）

• 负载均衡：从负载均衡接收流量，选择你上面建立的负载均衡alb_test和虚拟服务器组server_group，端口80

因为咱们设置的弹性伸缩初始实例数为1，因此在保存伸缩配置后会根据启动配置自动生成1台云主机（为方便观察效果，这里记录下内网IP：10.0.0.59）

在伸缩组-伸缩活动中也能够查看到伸缩记录

初始伸缩完成会进行冷却

咱们打开上面建立的负载均衡alb_test，找到虚拟服务器组server_group，可以看到弹性伸缩自动新建的云主机10.0.0.34已与负载均衡自动关联

4. 新建原生容器

这里运用自定义的DockerHub公共仓库镜像，咱们须要点击控制台左侧弹性计算-原生容器-镜像仓库认证信息-华北-北京-添加镜像仓库认证信息，配置以下：

• 名称：DockerHub

• 类型：docker-registry

• 仓库域名：https://index.docker.io

• 用户名/密码：不填写（由于是公共仓库，因此可不填写，写了也没用）

• 邮箱：不填写

点击左侧容器实例，如图在华北-北京新建容器实例

容器①配置：

• 计费类型：按配置

• 地域：华北-北京

• 可用区：默认

• 镜像：第三方镜像
  镜像仓库：DockerHub
  镜像名称：marin0224/alb_test:web01
  镜像信息：https://index.docker.io/marin0224/alb_test:web01（自动生成）

• 规格：1核4GB（默认）

• 存储：默认

• 网络：选择本身建立的私有网络（VPC）

• 带宽：暂不购买

• 高级设置：运行的命令 /run.sh

• 名称：alb_test_web01

如上，一样方式建立第二个原生容器

容器②配置：

• 计费类型：按配置

• 地域：华北-北京

• 可用区：默认

• 镜像：第三方镜像
  镜像仓库：DockerHub
  镜像名称：marin0224/alb_test:web02
  镜像信息：https://index.docker.io/marin0224/alb_test:web02（自动生成）

• 规格：1核4GB（默认）

• 存储：默认

• 网络：选择本身建立的私有网络（VPC）

• 带宽：暂不购买

• 高级设置：运行的命令 /run.sh

• 名称：alb_test_web02

两个容器建立完成后，以下图：

3、产品测试

1.自动扩缩容

咱们在伸缩组中的报警策略页面添加策略，配置以下：

• 策略名称：policy1

• 监听该规则：内存使用率-2分钟内-平均值-<-1%-连续2次（此规格镜像默认启动内存使用率大概4%左右，因此监听规则设置低于1%是必定会触发报警的。仅供测试）

• 伸缩规则：增长1台云主机，冷却1秒

等待伸缩组冷却完成（状态变为正常）后，咱们将建立伸缩组触发的云主机（10.0.0.59）中止来模拟故障

等待几分钟，可以再次自动成功弹出1台新的云主机（10.0.0.62），且最先建立的云主机（10.0.0.59）也被移除

咱们在找到伸缩组JAS_group,在伸缩活动页面查看伸缩动态，发现因为咱们中止云主机致使检测不健康而被移除，并成功建立了新的云主机

成功弹出的云主机（10.0.0.62）会自动与绑定的负载均衡alb_test实例关联，并移除原来不健康的云主机（10.0.0.59）实例

当伸缩组冷却结束后，咱们在伸缩组的定时任务中定时增长1台云主机，定时任务名称为add_vm（执行时间设置间隔是5分钟，因为是测试，选择当前时间以后最近的时间点就行），用来模拟业务量突增

若是在设置的定时任务时间伸缩组在冷却，则定时任务不会触发。

在伸缩活动中查看状态

在云主机控制台可以看到根据定时任务新弹出的云主机（内网IP10.0.0.4）

而且，在负载均衡的虚拟服务器组中咱们能够看到，新弹出的云主机自动与负载均衡关联

在新建的负载均衡实例alb_test上添加一个HTTP协议的监听器，以下图点击监听器-新建监听器：

前端监听配置：按照默认下一步便可

后端转发配置：新建一个后端服务backend_test，其余保持默认配置（加权轮询/不开启会话保持），而后点击下一步

健康检查：按照默认，下一步

添加服务器组：服务器组选择咱们上面新建的虚拟服务器组server_group，也就是说弹性伸缩会配合ALB实现伸缩功能，点击肯定

复制应用负载均衡的公网IP到浏览器查看效果，以下图（刚开始ALB配置生效中，可能会出现502属于正常现象）：

2.ALB的会话保持功能

京东云应用负载均衡（ALB）是支持云主机与原生容器的会话保持功能的，这里咱们实操对京东云原生容器的支持。

在负载均衡实例控制台找到咱们上面新建的负载均衡实例alb_test点进去，在虚拟服务器组里咱们编辑上面咱们新建的服务组server_group

咱们将原来的2台弹性伸缩生成的云主机删除，而后将上面建立的2台原生容器加进来，而后点击肯定

咱们复制负载均衡实例的公网IP到浏览器查看结果（刚开始负载均衡配置生效中，可能会报502，多刷新几遍）
因为咱们设置的是加权轮询规则，因此每次刷新浏览器就会在容器①与容器②之间切换

接下来咱们到负载均衡的后端服务编辑backend_test

将如图中的会话保持功能打开

复制负载均衡公网IP到浏览器后，不停刷新，发现请求会一直保持分发到某一台后端服务器（我这里是原生容器②）

因为咱们上面设置的会话保持超时时间是30秒，且转发规则为加权轮询，因此30秒事后，从新刷新浏览器后，请求会被分发到原生容器①

3.三种调度策略效果

调度策略一：加权最小链接数

在一个浏览器中（例如谷歌浏览器）打开多个窗口来对负载均衡发起请求，请求指向某一台后端服务器（我这里是原生容器①）；

接下来咱们到负载均衡的后端服务编辑backend_test，将如图中的会话保持功能关闭，并将调度算法更改成加权最小链接数；

为效果明显，在另外一个浏览器中（例如火狐浏览器）打开一个窗口对负载均衡发起请求，请求会被分发到另外一台处理请求数较少的后端服务器（我这里是原生容器②）；

调度策略二：加权轮询

咱们将调度算法改成加权轮询

在浏览器中输入负载均衡的公网IP，每刷新一次浏览器，请求就会轮询分发到后端原生容器（处理请求的后端会不停的换）

调度策略三：源IP

咱们将调度策略改成源IP

咱们打开3种不一样的浏览器（谷歌、火狐、Microsoft Edge）分别访问负载均衡，当第一个浏览器请求被分配到某一台后端机器的时候（我这里是原生容器①），其余的浏览器请求也都会被分配到这台机器

4.健康检查

确保负载均衡的状态检查功能为开启状态（默认状况下为开启），调度算法为加权轮询

咱们将负载均衡虚拟服务器组中对应的任意一台原生容器中止，用以模拟服务器故障

如今我访问负载均衡，刷新浏览器，发现即使调度策略为加权轮询，请求也只会分发到原生容器②，由于原生容器①已经被检测异常
打开负载均衡的后端服务详情，咱们能看到原生容器①的健康状态为异常

阅读原文