?作者：京東云 張久志

本文以 2022 年一個實際項目為基礎，來演示在京東云上構建高可用業務的整個過程。公有云及私有云客戶可通過使用京東云的彈性 IAAS、PAAS 服務，創建高可用、高彈性、高可擴展、高安全的云上業務環境，提升業務 SLA, 提升運維自動化水平，降低資源成本及運維成本。有業務遷移上云需求，希望構建云上高可用業務架構的客戶或對云上高可用架構規劃有興趣的讀者可以一看。

客戶業務為典型的 web 應用，在京東云上創建一個通過公網 IP/ 域名訪問的高可用的 web 網站，包含通用應用的標準框架，包括訪問接入層、APP 層、緩存層、數據庫層。整體業務架構設計提供可用區 (AZ) 級別的高可用等級。

本文演示場景包括單 AZ 出現故障導致的主機故障、數據庫故障、緩存故障場景下，業務能夠提供持續訪問能力。并保障數據的完整性和一致性，同時，能夠在無人干預的條件下，實現業務的彈性擴展，保障業務高并發的場景下有良好的響應時間。

說明：

本文的架構為演示架構，并未嚴格遵循生產環境的業務性能及安全的整體規劃步驟及要求，在生產環境中，至少應該對主機及 CFS 的存儲性能進行壓測，確保能夠滿足實際業務需求，同時，通過域名訪問的 web 服務，建議使用 WAF 等安全防護產品，保障業務的入口安全。

1、京東云高可用架構設計

業務架構以某單位的業務需求為基礎，模擬其業務生產環境，規劃京東云上的業務整體架構，其中， NAT 網關、負載均衡、堡壘機均創建在公網訪問子網，其余主機及數據庫等，創建在內部子網內。

其中應用主機使用高可用組創建， LB 后端直接掛載高可用組。

使用高可用組的目標是實現業務高峰期故障時，計算資源能自動加入負載均衡后端，自動化擴展業務處 理能力。減少運維干預成本。

2、資源需求（所有IP及URL均調整為非真實IP及URL）

3、應用部署

3.1基礎環境準備

業務以一個典型的 wordpress 的網站為例，業務容器化部署于云主機上，高可用依賴京東云的云主機高可用組，主機安裝 docker，并配置 docker 服務自動啟動。

#創建應用數據目錄 配置目錄權限、安裝docker等

 mkdir -p /wp

 chmod 777 /wp

 yum install docker vim -y

 systemctl enable docker

 systemctl start docker

 #掛載CFS文件作為應用數據目錄

 yum install nfs-utils -y

 systemctl enable rpcbind    

 systemctl start rpcbind

 mount -t nfs -o vers=3 -o noresvport 10.0.0.200:/cfs /wp

#配置啟動自動掛載CFS及啟動服務，通過rc.local實現：

#[root@wpha0 wp]# cat /etc/rc.local

#!/bin/bash

# THIS FILE IS ADDED FOR COMPATIBILITY PURPOSES

#

# It is highly advisable to create own systemd services or udev rules

# to run scripts during boot instead of using this file.

#

# In contrast to previous versions due to parallel execution during boot

# this script will NOT be run after all other services.

#

# Please note that you must run 'chmod +x /etc/rc.d/rc.local' to ensure

# that this script will be executed during boot.

touch /var/lock/subsys/local

mount -t nfs -o vers=3 -o noresvport 10.0.0.200:/cfs /wp

#（說明，生產環境可在/etc/fstab掛載）

bash /root/start.sh

start.sh見以下代碼

[root@wpha0 wp]# cat /root/start.sh

docker stop wordpress

sleep 3

docker rm wordpress

sleep 3

docker run -d --name=wordpress --restart=unless-stopped -p 443:443 -p 80:80 -v /wp:/var/www/html wordpress

#[root@wpha0 wp]#

#啟動腳本編輯完成后，并寫入rc.local后，rc.local調整成可執行，以實現啟動主機運行腳本， rc.local實現了主機啟動后自動掛載CFS到指定目錄，然后，通過start.sh自動清除舊數據，重新拉起wordpress服務。

chmod +x /etc/rc.d/rc.local

#拉取應用所需鏡像

 docker pull wordpress

#拉取鏡像后，運行服務。

docker run -d --name=wordpress --restart=unless-stopped    -p 443:443 -p 80:80  -v /wp:/var/www/html  wordpress

注意，這個場景下，主要調整了幾個位置：

1、掛載 CFS 為 wordpress 的工作目錄，這樣，調整頁面內容以及拉起新主機后，網站內容都保持一致。相關自動掛載方式為在 /etc/rc.local 加入掛載命令，同時 chmod +x /etc/rc.d/rc.local 把這個文件加一下可執行權限。

2、需要把 wp 目錄的權限改為 777 （或 docker 內部的 33 tape 等，不過不同版本可能有區別，改成 777 相對穩妥）， 否則掛載后，docker 內部的 wordpress 無法獲取目錄讀寫權限。

3、NFS 掛載需要安裝 nfs 插件 yum install nfs-utils -y 并啟動 rpc 服務 systemctl enable rpcbind systemctl start rpcbind

WP 目錄為 777 權限

到這里基礎主機環境準備完成。

下一步，進行 wordpress 應用的配置，實現高可用可視化的演示效果。

3.2業務側wordpress配置

web 應用使用 wordpress 部署。通過 docker 部署，并實現高可用組主機自動伸縮自動化拉起。

通過 docker 拉取 wordpress

docker pull wordpress

拉取鏡像后

docker run -d --name=wordpress --restart=unless-stopped -p 443:443 -p 80:80 -v /wp:/var/www/html wordpress

其中 /wp 是掛載的 CFS，作為多個應用主機共同掛載，作為 wordpress 的應用的應用文件目錄。

啟動 wordpress 容器，并掛載 CFS 目錄為 WP 的應用目錄。

以上部署在 3.1 中已經完成。

前置準備工作 - 負載均衡：

配置一個帶公網 IP 的負載均衡，并配置監聽器，監聽器后端暫時配置一個已經拉起了 docker 的這臺主機

前置準備工作 - 數據庫：

在配置網站前，需要首先在云控制臺的 RDS 那里為 wordpress 創建一個賬戶：wordpress，并設置密碼，建立一個庫：wordpress（因為后續演示方案有調整，我又創建了一個新庫 wordpressbackup，實際正常來講一個庫就可以了），并授權 wordpress 庫給 wordpress 用戶。

前置準備工作 - redis：

在控制臺購買一個 redis，記錄 redis 的 URL，為后續配置 redis 緩存做準備。

這樣，基本的應用環境就緒了。

通過瀏覽器訪問負載均衡 (注意訪問 LB，不直接訪問主機) 的 IP 的 80 端口，即可進入 wordpress 的配置 頁面， wordpress 的配置，主要是數據庫的地址以及數據庫前綴的配置，輸入正確的數據庫的 host 地址及密碼即可，其余保持默認，其他依據官網手冊指導保持默認配置即可。

配置完成后，wordpress 會自動為網站創建相關的表，并提示配置 wordpress 的 admin 以及管理密碼。

安裝完成后，可以登錄數據庫查看創建的表，后續 MySQL 高可用演示時，也可以登錄到數據庫做些常規 操作，不受高可用切換影響。

到此，基本的應用就安裝完成了。

配置 redis 動態緩存加速：

redis 的角色，在這個案例里邊，在 wordpress 里 redis 作為一個動態加速緩存使用，對加速網站訪問， 減輕數據庫壓力起到一定作用。

下載 wordpress 的 redis 插件，redis-cache。

下載后通過 wordpress 的管理頁面 -plugin --addnew 直接上傳，然后依據插件操作手冊安裝配置即可。

安裝 redis-cache 以后，會在 /wp/wp-content/plugins 目錄下生成一個 redis-cache 目錄。需要同時在 /wp/wp- content 下生成一個 object-cache.php 文件，正常來講，需要調整一個參數 host 改成 redis 的域名即可。如果配置了密碼，就需要調整這個以及 redis-cache 目錄下的配置文件把密碼配置進去，這個因為是 演示環境，redis 設置 了免密，生產環境一定要設置密碼。

安裝配置完成后，在管理界面的 setting 里會有 redis 的配置選項，這個和版本有關系，有些版本可能會讓 在這里做參數配置。直接改文件參數效果是一樣的。

mysql 及 redis 管理及相關登錄方式介紹：

• MySQL 的登錄，沒有安裝 client，使用了一個 mysql 的 docker
• 相關命令：
• docker run --name mysql -p 3306:3306 --restart=unless-stopped -v /root/dbackup/:/db -e MYSQL_ROOT_PASSWORD=123456 -d mysql:5.7
• 進入 mysql 的 docker 中：
• docker exec -it mysql bash
• 連接 wordpress 使用的數據庫：
• mysql -h mysql-xxxea04fc4c52.jdcloud.com -u wordpress -p
• use wordpressbackup;
• show tables;
• select id from wpbackup_posts;
• -- 中間因為做了多次演練和數據庫切換，中間做了 wordpress 數據庫導出和導入操作
• mysql 數據庫導出（均在 mysql 的 docker 容器中執行命令）：
• mysqldump -h mysql-xxxa04fc4c52.jdcloud.com -uwordpress -p --databases wordpressbackup >/db/wordpressbackup-0322.sql
• 數據導入：
• 進入數據庫，
• use wordpressbackup;
• source /db/wordpressbackup-0322.sql;
• ----redis 驗證
• redis 驗證，同樣是沒有安裝 client，通過 docker 里的命令行去連接：
• docker run -d --name redis --memory=1G -p 7379:6379 redis
• docker exec -it redis bash
• redis-cli -h redis-j49rpxxx.jdcloud.com
• 登入后，查看信息：
• KEYS *

wordpress 配置主頁顯示 hostname 及來源 IP

--- 讓 wordpress 獲取 hostname 并在頁面展示 + 獲取訪客地址，以增強演示效果，明確看到訪問的實際主 機位置。

為了讓訪問者看到訪問的 IP 是哪個（證實高可用組的自動擴容及業務的自動拉起），需要在所使用的 theme 目錄的 function 里加入相關代碼。 /wp/wp- content/themes/twentytwentytwo/function.php

[root@AG-wordpress- HA-group1-c8705-2 twentytwentytwo]# vim /wp/wp-content/themes/twentytwentytwo/function.php

在里邊加入以下代碼，一個是 show_ip 函數，一個是 show_hostname 函數。

function get_the_user_ip() {
if ( ! empty( $_SERVER["HTTP_CLIENT_IP"] ) ) {
//check ip from share internet
$ip = $_SERVER["HTTP_CLIENT_IP"];
} elseif ( ! empty( $_SERVER["HTTP_X_FORWARDED_FOR"] ) ) {
//to check ip is pass from proxy
$ip = $_SERVER["HTTP_X_FORWARDED_FOR"];
} else {
$ip = $_SERVER["REMOTE_ADDR"];
}
return apply_filters( "wpb_get_ip", $ip );
}
add_shortcode("show_ip", "get_the_user_ip");

function get_hostname()
{
     $hostname = gethostname();
          echo "$hostname\n";
      return apply_filters( "hostname", $hostname );
}

add_shortcode("show_hostname", "get_hostname");

然后，在 wordpress 的 site 里加入短代碼實現：

保存后，看到頁面可以顯示相關的 IP 及 hostname 信息了。

到這里， wordpress 的應用環境配置完成。

下一步配置業務的高可用環境，實現跨 AZ 的高可用組及主機自動彈性伸縮。

3.3實例模板及高可用組、LB配置

單臺主機配置完成后，重啟能自動拉起應用，進行確認后， 將現有主機打一個鏡像。作為高可用組的實例模板。后續 LB 后端的高可用組通過這個模板創建主機。

其余包括數據庫配置、網站數據、redis 緩存配置等，均實現了服務及數據的分離，因此，在后期進行動 態彈性擴容時，使用這個模板的高可用組，可以直接拉起服務，實現動態彈性伸縮。

實例模板：

高可用組：

高可用組使用制作好了 wordpress 的應用主機的鏡像。做到高可用組自動彈性伸縮出新主機 -- 新主機自動 拉起 wordpress 應用 -- 新主機自動掛載到 LB 接收業務流量的模式。

LB 配置。

LB 監聽器選擇后端服務為高可用組，并配置健康檢查。

高可用組掛載到 LB 后端以后，應用環境已經搭建完成。

可以訪問 LB 入口，訪問到網站，并且會輪詢到不同服務器，同時，訪問單臺服務器的外網 IP 也可以訪問網站業務：

LB 訪問截圖 (2 張，分別訪問到了兩個主機)

單臺主機訪問截圖（直接訪問單臺主機 IP，刷新后不會輪詢主機）：

演示環境就緒。

下一步，進行破壞性演練，檢驗高可用環境的效果。

4、應用演示

高可用演示腳本：

高可用組信息，目前 LB 后端掛載的為高可用組：

測試頁面信息（所有 IP 均為非真實 IP）：

業務入口 (LB)： http://100.126.35.4/

高可用組單臺主機訪問入口目前為：

http://100.126.38.13/

http://100.126.38.16

主機的高可用及自動伸縮：

演示所需的一些腳本：

一個是模擬生產環境，對業務主入口的 LB 持續訪問，這個在測試過程中，一直可以訪問到，不會中斷。

#!/bin/bash
#for ((i=1;i<=10;i++))
for i in {1..15000}
 do
curl 100.126.35.4
echo $i
echo $(date +%T)
sleep 3
  done

一個是模擬單機環境，對業主機入口的持續訪問，這個在測試過程中，當針對單機關機時，訪問會卡住。

#!/bin/bash

#for ((i=1;i<=10;i++))

for i in {1..15000}

 do

curl 100.126.38.16

echo $i

echo $(date +%T)

sleep 3

  done

演示過程中，高可用組自動伸縮功能，能正常擴容出新的主機并提供業務訪問。

• 高可用組的自動伸縮，通過 stress 模擬壓力
• 安裝 stress 后，直接運行（主機為 2C）：
• stress --CPU 2
• 通過 top 命令可以看到 CPU 被打滿。
• 過 2 分鐘（高可用組伸縮策略配置的時間），高可用組會自動擴展一臺主機，并作為高可用組的一臺主機自動掛載到 LB 的后端，可在 LB 及主機界面看到自動擴容的主機。

在控制臺將一臺高可用組內主機關機，然后可見 LB 后端服務健康檢查發現掛載的高可用組一臺服務器異常，高可用組如配置最小的主機數量，則高可用組也自動擴出一臺主機，繼續提供服務。在此期間，流量會轉發給后端正常主機，健康檢查異常的主機不再接收流量，業務訪問持續正常。

PAAS 服務的高可用：

本演示以 MySQL 及 redis 研發在底層直接殺 docker，然后業務訪問不中斷，控制臺上會出現主從切換現象在這個過程中對業務的訪問不會中斷。

云數據庫及緩存的破壞性操作，底層操作由研發操作。

底層進行 RDS 主備切換（kill 掉 RDS 主庫），業務訪問同樣不會中斷，研發提供截圖可以看到主從切換過程。

本文實際部署環境為京東為客戶搭建的私有云環境（JDSTACK），公有云與私有云為相同技術棧，搭建及驗證過程相似。限于篇幅，redis 驗證部分及主機可訪問性腳本結果未截圖，感興趣的讀者可自行在云上通過本文指引過程搭建驗證。?