作者：京东云 张久志
本文以 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 验证局部及主机可拜访性脚本后果未截图，感兴趣的读者可自行在云上通过本文指引过程搭建验证。