【案例分享】如何利用京东云建设高可用业务架构-京东云开发者社区

**作者：京东云 张久志**

本文以2022年一个实际项目为基础，来演示在京东云上构建高可用业务的整个过程。公有云及私有云客户可通过使用京东云的弹性IAAS、PAAS服务，创建高可用、高弹性、高可扩展、高安全的云上业务环境，提升业务SLA,提升运维自动化水平，降低资源成本及运维成本。有业务迁移上云需求，希望构建云上高可用业务架构的客户或对云上高可用架构规划有兴趣的读者可以一看。

客户业务为典型的web应用，在京东云上创建一个通过公网IP/域名访问的高可用的web网站，包含通用应用的标准框架，包括访问接入层、APP层、缓存层、数据库层。整体业务架构设计提供可用区(AZ)级别的高可用等级。

**本文演示场景包括**单AZ出现故障导致的主机故障、数据库故障、缓存故障场景下，业务能够提供持续访问能力。并保障数据的完整性和一致性，同时，能够在无人干预的条件下，实现业务的弹性扩展，保障业务高并发的场景下有良好的响应时间。

**说明：**

本文的架构为演示架构，_并未严格遵循生产环境_的业务性能及安全的整体规划步骤及要求，在生产环境中，至少应该对主机及CFS的存储性能进行压测，确保能够满足实际业务需求，同时，通过域名访问的web服务，建议使用WAF等安全防护产品，保障业务的入口安全。

# **1**、京东云高可用架构设计

业务架构以某单位的业务需求为基础，模拟其业务生产环境，规划京东云上的业务整体架构，其中，  NAT网关、负载均衡、堡垒机均创建在公网访问子网，其余主机及数据库等，创建在内部子网内。

![](https://oscimg.oschina.net/oscnet/up-ed9fcfb7fc2df9a859085e2df37cc05a49d.jpg)

其中应用主机使用高可用组创建， LB后端直接挂载高可用组。

使用高可用组的目标是实现业务高峰期故障时，计算资源能自动加入负载均衡后端，自动化扩展业务处 理能力。减少运维干预成本。

# **2**、****资源需****求（所有****IP****及****URL****均调整为非真实****IP****及****URL****）

![](https://oscimg.oschina.net/oscnet/up-259287eb0840e644e56a7dbe9d93248b3ba.png)

# **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 权限

![](https://oscimg.oschina.net/oscnet/up-32becc34daca700c7d868c21748700c118d.jpg)

到这里基础主机环境准备完成。

下一步，进行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高可用演示时，也可以登录到数据库做些常规 操作，不受高可用切换影响。

到此，基本的应用就安装完成了。

![](https://oscimg.oschina.net/oscnet/up-13ac03676bb9d225da74a6a6005d9ad0336.jpg)

配置**redis**动态缓存加速：

redis的角色，在这个案例里边，在wordpress里 redis 作为一个动态加速缓存使用，对加速网站访问， 减轻数据库压力起到一定作用。

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

下载后通过wordpress的管理页面-plugin --addnew 直接上传，然后依据插件操作手册安装配置即可。

![](https://oscimg.oschina.net/oscnet/up-d09eaeaed66140cc73352b3725580a731d6.png)

安装redis-cache以后，会在/wp/wp-content/plugins 目录下生成一个 redis-cache目录。需要同时在/wp/wp- content 下生成一个 object-cache.php文件，正常来讲，需要调整一个参数host改成redis的域名即可。如果配置了密码，就需要调整这个以及redis-cache目录下的配置文件把密码配置进去，这个因为是 演示环境，redis设置 了免密，生产环境一定要设置密码。

![](https://oscimg.oschina.net/oscnet/up-dec508da9ffab03761887713d8514c416b8.png)

安装配置完成后，在管理界面的setting里会有redis的配置选项，这个和版本有关系，有些版本可能会让 在这里做参数配置。直接改文件参数效果是一样的。

![](https://oscimg.oschina.net/oscnet/up-89e0da549ea8022147eb885a0178149da91.png)

**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里加入短代码实现：

![](https://oscimg.oschina.net/oscnet/up-e6b3ca158b19ad052f59254635484c9f454.png)

保存后，看到页面可以显示相关的IP及hostname信息了。

![](https://oscimg.oschina.net/oscnet/up-c2fee9a87d8e8a9320772e15b53f751283b.png)

到这里，  wordpress的应用环境配置完成。

下一步配置业务的高可用环境，实现跨AZ的高可用组及主机自动弹性伸缩。

## **3**.**3** 实例模板及高可用组、**LB**配置

单台主机配置完成后，重启能自动拉起应用，进行确认后， 将现有主机打一个镜像。作为高可用组的实例模板。后续LB后端的高可用组通过这个模板创建主机。

其余包括数据库配置、网站数据、redis缓存配置等，均实现了服务及数据的分离，因此，在后期进行动 态弹性扩容时，使用这个模板的高可用组，可以直接拉起服务，实现动态弹性伸缩。

实例模板：

![](https://oscimg.oschina.net/oscnet/up-9daf10bad8766e468ca9960cfa3adcb0696.png)

![](https://oscimg.oschina.net/oscnet/up-a8d9a526d7a9ee89028d468aa7abf860653.png)

高可用组：

高可用组使用制作好了wordpress的应用主机的镜像。做到高可用组自动弹性伸缩出新主机--新主机自动 拉起wordpress应用--新主机自动挂载到LB接收业务流量的模式。

![](https://oscimg.oschina.net/oscnet/up-9fb838e9629f2c48ac06d9d3c5b330a208e.png)

![](https://oscimg.oschina.net/oscnet/up-660e45ab0d5cdf2adc5fdd731aebf1fff33.png)

![](https://oscimg.oschina.net/oscnet/up-d7bf294e2c8ca641ed1f2bfa7ddcc003d50.png)

**LB**配置。

LB监听器选择后端服务为高可用组，并配置健康检查。

![](https://oscimg.oschina.net/oscnet/up-29f377d683e4c51b0ed246098f68e971357.png)

![](https://oscimg.oschina.net/oscnet/up-6485365ab7e2b7f9001f95ef8c62b3d557f.png)

高可用组挂载到LB后端以后，应用环境已经搭建完成。

可以访问LB入口，访问到网站，并且会轮询到不同服务器，同时，访问单台服务器的外网IP 也可以访问网站业务：

LB访问截图(2张，分别访问到了两个主机)

![](https://oscimg.oschina.net/oscnet/up-dfeaf2eb865ba86ef66638279ad907774ca.png)

![](https://oscimg.oschina.net/oscnet/up-413b025a387f7eb6402c64e7d0233b3e721.png)

单台主机访问截图（直接访问单台主机IP，刷新后不会轮询主机）：

![](https://oscimg.oschina.net/oscnet/up-2661a38b84a11dc277854cbf4d2b5c6a599.png)

演示环境就绪。

下一步，进行破坏性演练，检验高可用环境的效果。

# **4**、应用演示

高可用演示脚本：

![](https://oscimg.oschina.net/oscnet/up-8c700abce409be465886e18c6ac1e0fb55f.png)

高可用组信息，目前LB后端挂载的为高可用组：

测试页面信息（所有IP均为非真实IP）：

业务入口(LB)：   [http://100.126.35.4/](http://100.126.35.4/)

高可用组单台主机访问入口目前为：

[http://100.126.38.13/](http://100.126.38.13/)

[http://100.126.38.16](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}

curl 100.126.38.16

echo $i

echo $(date +%T)

sleep 3

done
```

演示过程中，高可用组自动伸缩功能，能正常扩容出新的主机并提供业务访问。

高可用组的自动伸缩，通过 stress模拟压力

> 安装stress后，直接运行（主机为2C）：
> 
> stress --CPU 2
> 
> 通过top命令可以看到CPU被打满。
> 
> 过2分钟（高可用组伸缩策略配置的时间），高可用组会自动扩展一台主机，并作为高可用组的一台主机自动挂载到LB的后端，可在LB及主机界面看到自动扩容的主机。

![](https://oscimg.oschina.net/oscnet/up-59a0dcce659b6ee3ba38782cd52d2997494.png)

在控制台将一台高可用组内主机关机，然后可见LB后端服务健康检查发现挂载的高可用组一台服务器异常，高可用组如配置最小的主机数量，则高可用组也自动扩出一台主机，继续提供服务。在此期间，流量会转发给后端正常主机，健康检查异常的主机不再接收流量，业务访问持续正常。

![](https://oscimg.oschina.net/oscnet/up-ed8136d5045f6442a6d0785020fcec77bf2.png)

![](https://oscimg.oschina.net/oscnet/up-1a2943a79ccbaeba787aad63030dfde06de.png)

**PAAS**服务的高可用：

本演示以MySQL及redis研发在底层直接杀docker，然后业务访问不中断，控制台上会出现主从切换现象在这个过程中对业务的访问不会中断。

云数据库及缓存的破坏性操作，底层操作由研发操作。

底层进行RDS主备切换（kill掉RDS主库），业务访问同样不会中断，研发提供截图可以看到主从切换过程。

![](https://oscimg.oschina.net/oscnet/up-212c01ffe55813fd848a6aaebf84e9cef99.png)

![](https://oscimg.oschina.net/oscnet/up-94fba27ba7823de35e1e4013d489b4e47ce.png)

本文实际部署环境为京东为客户搭建的私有云环境（JDSTACK），公有云与私有云为相同技术栈，搭建及验证过程相似。限于篇幅，redis验证部分及主机可访问性脚本结果未截图，感兴趣的读者可自行在云上通过本文指引过程搭建验证。