应用 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 diffmake 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.rpmsudo yum -y install --nogpgcheck k6sudo yum -y install git git clone https://github.com/aws-samples/serverless-woocommerce-workshop.gitcd ~/serverless-woocommerce-workshop/test/k6sudo yum install -y amazon-cloudwatch-agentcat << EOF > cw-statsd.json{    "metrics": {        "namespace": "k6",        "metrics_collected": {            "statsd": {                "service_address": ":8125",                "metrics_collection_interval": 1,                "metrics_aggregation_interval": 0            }        }    }}EOFsudo amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c file:./cw-statsd.jsonK6_STATSD_ENABLE_TAGS=true k6 run --out statsd -e HOSTNAME=<your WooCommerce website domain name> main.js

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

在 CloudWatch 的 k6 metrics 中能看到每秒实现的订单数和 Lambda 的并发量。能够看出，随着随着申请/订单量的减少，Lambda 会主动进行扩大。能够看出，Lambda 可能应答对于流量的高下峰，无需任何运行操作。

总结

本篇博客在上一篇的根底上，介绍了 Serverless 建站计划的劣势，并对基于 Serverless 服务的 WordPress 进行负载测试，可能看出 Lambda 可能主动应答流量高下峰而无需任何运维操作，大大节俭运维老本。读者也能够依据本身需要，批改测试脚本，进行更大规模的性能测试。

附录

* 基于亚马逊云科技无服务器服务疾速搭建电商平台——部署篇

  • 无服务器独立站工作坊：https://catalog.workshops.aws/serverless-woocommerce/zh-CN?tr...
  • Github code：https://github.com/aws-samples/serverless-woocommerce-workshop?trk=cndc-detail

本篇作者


汪其香 Amazon 解决方案架构师，负责基于 Amazon 云计算计划的架构征询和设计实现，具备丰盛的解决客户理论问题的教训，同时热衷于深度学习的钻研与利用。

许昌月 Amazon 解决方案架构师，负责基于 Amazon 的云计算计划架构征询和设计，施行和推广，善于软件开发，具备丰盛的解决客户理论问题的教训。

文章起源：https://dev.amazoncloud.cn/column/article/630b30932ecbae73705...