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

一、实操说明

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

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

二、环境搭建

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

两个容器创建完成后，如下图：

三、产品测试

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.健康检查

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

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

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