基于亚马逊云科技无服务器服务快速搭建电商平台——性能篇

标签：URL 亚马逊 Amazon API WordPress k6 服务器电商 Lambda

使用 Serverless 构建独立站的优势

在传统架构模式下，如果需要进行电商大促需要提前预置计算资源以支撑高并发访问，会造成计算资源浪费并且增加运维工作量。本文介绍一种新的部署方式，将 WordPress 和 WooCommerce 部署在 Amazon Lambda 中。Lambda 是无服务器的计算方式，无需预置资源就可以运行代码，自动响应任何规模的代码执行请求，从每天十几个事件到每秒数十万个事件，按计算时间付费（以毫秒为单位），真正做到按使用量计费，从而达到节省预置资源和运维成本。Lambda 的这种特性，让 Lambda 越来越受欢迎，越来越多的客户选择 Lambda 来部署应用，其中也包含 web 应用。了解 Lambda 的客户可能清楚，Lambda 是基于事件触发的方式，对于 web 应用，需要使用 API Gateway，接收 HTTP 请求，把 HTTP 请求转化为 Lambda 事件触发 Lambda 运行。

亚马逊云科技开发者社区为开发者们提供全球的开发技术资源。这里有技术文档、开发案例、技术专栏、培训视频、活动与竞赛等。帮助中国开发者对接世界最前沿技术，观点，和项目，并将中国优秀开发者或技术推荐给全球云社区。如果你还没有关注/收藏，看到这里请一定不要匆匆划过，点这里让它成为你的技术宝库！

在以前，对于已有的 Web 应用，需对应用代码进行轻量级的改造以处理 Lambda 事件。对于很多使用像 WordPress 和 WooCommerce 这样的成熟组件的电商客户来讲，进行代码改造不太可能，是不是就不能利用 Lambda 的优势了呢？答案是否定的。利用 Lambda 的新功能 Lambda container images 和开源组件 Amazon Lambda adapter 可以让 WordPress 在 Lambda 中运行且无需进行任何代码的修改。本解决方案通过将 Lambda Adapter，WordPress，WooCommerce 以及其他必要插件打包成容器，部署到 Lambda。同时本解决方案也利用了 Lambda 的新功能，Function URL，来代替 API Gateway，可以直接通过Function URL 来通过 HTTP(s) 访问 Lambda，从而节省 API Gateway 带来的成本。用户的动态请求，通过 CloudFront 回源到 Lambda URL 触发 Lambda 运行，在 Lambda 内部，Lambda Adapter 接收到 Lambda 事件并将其转换成 WordPress 能处理的 HTTP 请求。这样就实现了无需修改代码就能在 Lambda 中运行 WordPress。

本文着重介绍 Lambda container image 和 Lambda Function URL，关于 Lambda Adapter 的实现细节请参考这篇博客。

Lambda container image

要将容器运行在 Lamabda，容器映像需包含运行时 API 的 runtime interface clients，用于管理 Lambda 和函数代码之间的交互。客户可以自行将 runtime interface client 包含在自己的映像以支持在 Lambda 运行。Amazon 提供了一组可用于创建容器映像的开源基础映像。这些基本映像包括runtime interface clients 。Lambda 映像是只读的，但函数代码可以访问具有 512 MB 存储空间的可写 /tmp 目录。本方案使用 Docker 来创建映像。Dockerfile 里使用 Amazon 提供的基础映像Amazon Linux 2，并使用 bedrock 来管理 WordPress 和插件的安装。本方案中预配置了一些必要插件，客户可以修改 bedrock 的配置添加所需要的插件。

Lambda Function URL

现在可以通过创建 Function URL，支持使用 HTTP(s) 来访问这个 URL 来触发 Lambda 运行。在 Function URL 这个功能没有发布的时候，基于 Lambda 构建 Web 应用需要结合 API Gateway 来接收 HTTP(s) 请求。但是在 Lambda 上部署 WooCommerce 的场景下，因为是把 WordPress 等打包成一个容器，因此只需要单个 Lambda Function，API gateway 的作用只是把 HTTP 请求转化为 Lambda 事件，而 API Gateway 提供的高级功能，例如 API 管理，请求验证等，并不需要。因此有了 Function URL 的功能，就能够取代 API Gateway 在此场景下的作用，并且不会增加 Lambda 的费用，同时也节省了 API Gateway 的费用。

负载测试

在上一篇博客的基础上，我们使用 WordPress 的插件 Blocksy 快速构建一个 Starter Site，并使用这个 Site 来作为测试对象。

本方案已经开源在 Github，访问此 [Repo] (https://github.com/aws-samples/serverless-WooCommerce-workshop)可获得完整代码。

在 test/k6文件夹内，本方案也提供了进行性能测试的 k6脚本。模拟了用户进入主页，选择商品，并加入购物车，更新地址，到提交订单的完整流程。具体说明参考 test/readme.md 文件。

main.js 作为测试的入口文件，模拟了前5分钟100个用户在线，中间10分钟1000个用户在线，后5分钟100个用户在线的场景。读者可根据测试需要修改 main.js 文件。

因为默认 CDK 模版预置的 RDS Aurora mysql 实例和 Elasticahe Redis cluster 规模过小，不适合用来做测试。这里修改 CDK 代码cdk/lib/woocommerce-stack.ts，将 RDS Aurora mysql 的 r5.4xlarge。Elasticahe Redis cluster 修改为 r5.xlarge。客户也可以自行改大规模进行更大范围的测试。

通过以下命令更新资源。

make diff
make deploy
复制代码

在这里我们使用一台 c5.xlarge 的 Amazon Linux 2 EC2来进行测试。并安装 CloudWatch Agent，将 k6生成的指标上传到 CloudWatch 进行可视化。注意 EC2需要有权写入 CloudWatch Metrics，这里我们使用 EC2 Role 来赋予权限。通过创建 Role，选择下图的托管策略 CloudWatchAgentAdminPolicy，并且把这个 Role 绑定给EC2。

通过以下命令安装、配置 k6和 CloudWatch Agent，并运行 k6进行测试。

sudo yum -y install https://dl.k6.io/rpm/repo.rpm
sudo yum -y install --nogpgcheck k6
sudo yum -y install git 
git clone https://github.com/aws-samples/serverless-woocommerce-workshop.git
cd ~/serverless-woocommerce-workshop/test/k6
sudo yum install -y amazon-cloudwatch-agent
cat << EOF > cw-statsd.json
{
    "metrics": {
        "namespace": "k6",
        "metrics_collected": {
            "statsd": {
                "service_address": ":8125",
                "metrics_collection_interval": 1,
                "metrics_aggregation_interval": 0
            }
        }
    }
}
EOF
sudo amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c file:./cw-statsd.json
K6_STATSD_ENABLE_TAGS=true k6 run --out statsd -e HOSTNAME=<your WooCommerce website domain name> main.js

下图是 k6测试运行完的统计结果。