利用 AWS Lambda 构建独立站的优势及负载测试介绍

还在为传统电商在大型促销活动中的资源浪费和运维的繁琐问题而感到困扰吗？今天，我们将向您展示一种全新解决方案的显著优势，并分享其负载测试的具体情况。

无服务器服务方案的优势

这种方案与传统架构有着显著差异。在电商大促期间，传统架构需要提前储备计算资源以应对高流量访问。例如，某电商公司曾在促销前投入巨资扩充计算能力，但促销结束后，这些资源便闲置浪费，同时运维工作量也极为繁重。而本方案采用事件触发机制，仅在事件发生时调用资源，有效避免了资源的不必要浪费。此外，对于众多现有Web应用而言，代码改造往往十分繁琐，但本方案通过引入新功能和开源组件，使得应用无需修改代码即可运行。

无服务器服务在资源运用上更显高效与合理。相较传统方法，它无需持续占用大量资源。以一些小型电商企业为例，其业务流量呈现明显的高低起伏，采用无服务器服务后，资源可按需分配，有效降低了成本。同时，也解决了企业对于改变现有代码结构可能带来的风险等担忧。

新功能URL的意义

在这个方案中，新功能的URL扮演着核心角色。过去，在开发Web应用时，我们需要借助API来处理HTTP(s)请求。而现在，借助URL功能，我们能够直接通过HTTP(s)进行访问。以某电商平台为例，之前使用API的成本极高，而且许多高级功能并未得到充分利用。引入URL功能后，它能够替代API，不仅大幅降低了成本，而且操作起来也更加简单方便。

它在内部的作用独树一帜。URL能够在特定情况下取代API的功能，而且不会带来额外费用。在容器运行方面，容器映像中包含了必要的运行时API，用以管理交互。根据我们的应用测试，使用URL访问更加直接，效率也更高。

容器打包的高效之处

在这个方案里，容器打包的作用非常关键。它将多个必需的元素，比如插件等，打包后部署到指定位置。这就像把各种零散的零部件装进一个包裹里，便于管理。以我们自制的电商小插件为例，打包进容器后，不仅便于在系统中安装，而且其稳定性也得到了显著提升。

容器打包有助于资源的有效整合。在同一个容器中，多个插件可以相互协作，效率更高。比如，电商领域常用的图片处理插件和订单处理插件，在打包后的容器中能够更顺畅地协同运作，减少了插件间的沟通障碍，从而提高了应用的整体性能。

负载测试场景简介

负载测试是评估该方案性能的关键方法。基于上篇所构建的Site，我们在test/k6文件夹中放置了性能测试的k6脚本。脚本中的main.js定义了特定的测试场景。它模拟了不同时间段内在线用户数量的变化，例如，前5分钟有100名用户在线，接着的10分钟增至1000名用户，最后5分钟又回到100名用户。

这种测试场景几乎包括了现实中的高峰和低谷用户状况。以某电商APP为例，在推广初期，用户数量可能不多，但随着推广力度加大，用户数量会逐渐增多，最终进入稳定期，用户量又会回落。这种情况与我们的测试场景颇为相似，能够有效检验方案在各类流量情况下的表现。

对运维成本的影响

make diff
make deploy

该方案对运维成本产生了积极影响。以往，运维工作需投入大量人力物力，诸如全天候监控设备状态，保证资源调用顺畅。然而，采用无服务器服务方案后，它可自动应对流量波动，无需额外运维操作。

这相当于雇佣了一位让人放心的管家，不用时刻盯着，家中也能打理得井井有条。在不少客户案例里，企业在使用之前，运维团队常需加班应对突发的资源问题，而使用后，团队便能将更多精力转向业务创新。

测试的可扩展性

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 < 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= main.js

这里的测试项目具备良好的扩展能力。读者可以根据个人需求调整测试脚本，从而进行更大范围的性能评估。以一个拥有众多用户的电商集团为例，它能够调整相关参数，模拟出更大规模的用户在线状况。例如，前10分钟有1000名用户在线，接着30分钟内用户数量增至5000，最后10分钟又恢复到1000名用户在线的状态。

这有助于不同规模的企业通过自行调整来深入挖掘方案与自身需求的匹配度。你们是否也想赶紧尝试这种方案，以降低成本并提高性能？期待大家点赞、分享，并在评论区交流你的看法。