應用負載均衡（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/marin...:web01（自動生成）
規格：1核4GB（默認）
存儲：默認
網絡：選擇自己創建的私有網絡（VPC）
帶寬：暫不購買
高級設置：運行的命令 /run.sh
名稱：alb_test_web01
如上，同樣方式創建第二個原生容器
容器②配置：
計費類型：按配置
地域：華北-北京
可用區：默認
鏡像：第三方鏡像
鏡像倉庫：DockerHub
鏡像名稱：marin0224/alb_test:web02
鏡像信息：https://index.docker.io/marin...: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.健康檢查
確保負載均衡的狀態檢查功能爲開啓狀態（默認情況下爲開啓），調度算法爲加權輪詢
我們將負載均衡虛擬服務器組中對應的任意一臺原生容器停止，用以模擬服務器故障
現在我訪問負載均衡，刷新瀏覽器，發現即便調度策略爲加權輪詢，請求也只會分發到原生容器②，因爲原生容器①已經被檢測異常
打開負載均衡的後端服務詳情，我們能看到原生容器①的健康狀態爲異常
加入→"京東雲"瞭解更多詳情
