乾貨 | 京東雲應用負載均衡（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.健康檢查

確保負載均衡的狀態檢查功能爲開啓狀態（默認狀況下爲開啓），調度算法爲加權輪詢

咱們將負載均衡虛擬服務器組中對應的任意一臺原生容器中止，用以模擬服務器故障

如今我訪問負載均衡，刷新瀏覽器，發現即使調度策略爲加權輪詢，請求也只會分發到原生容器②，由於原生容器①已經被檢測異常
打開負載均衡的後端服務詳情，咱們能看到原生容器①的健康狀態爲異常

閱讀原文