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

阿里云国内75折回扣微信号：monov8

阿里云国际，腾讯云国际，低至75折。AWS 93折免费开户实名账号代冲值优惠多多微信号：monov8 飞机：@monov6

使用 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 AdapterWordPressWooCommerce 以及其他必要插件打包成容器部署到 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 FunctionAPI 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测试运行完的统计结果。