還在為傳統(tǒng)電商在大型促銷(xiāo)活動(dòng)中的資源浪費(fèi)和運(yùn)維的繁瑣問(wèn)題而感到困擾嗎？今天，我們將向您展示一種全新解決方案的顯著優(yōu)勢(shì)，并分享其負(fù)載測(cè)試的具體情況。

無(wú)服務(wù)器服務(wù)方案的優(yōu)勢(shì)

這種方案與傳統(tǒng)架構(gòu)有著顯著差異。在電商大促期間，傳統(tǒng)架構(gòu)需要提前儲(chǔ)備計(jì)算資源以應(yīng)對(duì)高流量訪(fǎng)問(wèn)。例如，某電商公司曾在促銷(xiāo)前投入巨資擴(kuò)充計(jì)算能力，但促銷(xiāo)結(jié)束后，這些資源便閑置浪費(fèi)，同時(shí)運(yùn)維工作量也極為繁重。而本方案采用事件觸發(fā)機(jī)制，僅在事件發(fā)生時(shí)調(diào)用資源，有效避免了資源的不必要浪費(fèi)。此外，對(duì)于眾多現(xiàn)有Web應(yīng)用而言，代碼改造往往十分繁瑣，但本方案通過(guò)引入新功能和開(kāi)源組件，使得應(yīng)用無(wú)需修改代碼即可運(yùn)行。

無(wú)服務(wù)器服務(wù)在資源運(yùn)用上更顯高效與合理。相較傳統(tǒng)方法，它無(wú)需持續(xù)占用大量資源。以一些小型電商企業(yè)為例，其業(yè)務(wù)流量呈現(xiàn)明顯的高低起伏，采用無(wú)服務(wù)器服務(wù)后，資源可按需分配，有效降低了成本。同時(shí)，也解決了企業(yè)對(duì)于改變現(xiàn)有代碼結(jié)構(gòu)可能帶來(lái)的風(fēng)險(xiǎn)等擔(dān)憂(yōu)。

新功能URL的意義

在這個(gè)方案中，新功能的URL扮演著核心角色。過(guò)去，在開(kāi)發(fā)Web應(yīng)用時(shí)，我們需要借助API來(lái)處理HTTP(s)請(qǐng)求。而現(xiàn)在，借助URL功能，我們能夠直接通過(guò)HTTP(s)進(jìn)行訪(fǎng)問(wèn)。以某電商平臺(tái)為例，之前使用API的成本極高，而且許多高級(jí)功能并未得到充分利用。引入U(xiǎn)RL功能后，它能夠替代API，不僅大幅降低了成本，而且操作起來(lái)也更加簡(jiǎn)單方便。

它在內(nèi)部的作用獨(dú)樹(shù)一幟。URL能夠在特定情況下取代API的功能，而且不會(huì)帶來(lái)額外費(fèi)用。在容器運(yùn)行方面，容器映像中包含了必要的運(yùn)行時(shí)API，用以管理交互。根據(jù)我們的應(yīng)用測(cè)試，使用URL訪(fǎng)問(wèn)更加直接，效率也更高。

容器打包的高效之處

在這個(gè)方案里，容器打包的作用非常關(guān)鍵。它將多個(gè)必需的元素，比如插件等，打包后部署到指定位置。這就像把各種零散的零部件裝進(jìn)一個(gè)包裹里，便于管理。以我們自制的電商小插件為例，打包進(jìn)容器后，不僅便于在系統(tǒng)中安裝，而且其穩(wěn)定性也得到了顯著提升。

容器打包有助于資源的有效整合。在同一個(gè)容器中，多個(gè)插件可以相互協(xié)作，效率更高。比如，電商領(lǐng)域常用的圖片處理插件和訂單處理插件，在打包后的容器中能夠更順暢地協(xié)同運(yùn)作，減少了插件間的溝通障礙，從而提高了應(yīng)用的整體性能。

負(fù)載測(cè)試場(chǎng)景簡(jiǎn)介

負(fù)載測(cè)試是評(píng)估該方案性能的關(guān)鍵方法。基于上篇所構(gòu)建的Site，我們?cè)趖est/k6文件夾中放置了性能測(cè)試的k6腳本。腳本中的main.js定義了特定的測(cè)試場(chǎng)景。它模擬了不同時(shí)間段內(nèi)在線(xiàn)用戶(hù)數(shù)量的變化，例如，前5分鐘有100名用戶(hù)在線(xiàn)，接著的10分鐘增至1000名用戶(hù)，最后5分鐘又回到100名用戶(hù)。

這種測(cè)試場(chǎng)景幾乎包括了現(xiàn)實(shí)中的高峰和低谷用戶(hù)狀況。以某電商APP為例，在推廣初期，用戶(hù)數(shù)量可能不多，但隨著推廣力度加大，用戶(hù)數(shù)量會(huì)逐漸增多，最終進(jìn)入穩(wěn)定期，用戶(hù)量又會(huì)回落。這種情況與我們的測(cè)試場(chǎng)景頗為相似，能夠有效檢驗(yàn)方案在各類(lèi)流量情況下的表現(xiàn)。

對(duì)運(yùn)維成本的影響

make diff
make deploy

該方案對(duì)運(yùn)維成本產(chǎn)生了積極影響。以往，運(yùn)維工作需投入大量人力物力，諸如全天候監(jiān)控設(shè)備狀態(tài)，保證資源調(diào)用順暢。然而，采用無(wú)服務(wù)器服務(wù)方案后，它可自動(dòng)應(yīng)對(duì)流量波動(dòng)，無(wú)需額外運(yùn)維操作。

這相當(dāng)于雇傭了一位讓人放心的管家，不用時(shí)刻盯著，家中也能打理得井井有條。在不少客戶(hù)案例里，企業(yè)在使用之前，運(yùn)維團(tuán)隊(duì)常需加班應(yīng)對(duì)突發(fā)的資源問(wèn)題，而使用后，團(tuán)隊(duì)便能將更多精力轉(zhuǎn)向業(yè)務(wù)創(chuàng)新。

測(cè)試的可擴(kuò)展性

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

這里的測(cè)試項(xiàng)目具備良好的擴(kuò)展能力。讀者可以根據(jù)個(gè)人需求調(diào)整測(cè)試腳本，從而進(jìn)行更大范圍的性能評(píng)估。以一個(gè)擁有眾多用戶(hù)的電商集團(tuán)為例，它能夠調(diào)整相關(guān)參數(shù)，模擬出更大規(guī)模的用戶(hù)在線(xiàn)狀況。例如，前10分鐘有1000名用戶(hù)在線(xiàn)，接著30分鐘內(nèi)用戶(hù)數(shù)量增至5000，最后10分鐘又恢復(fù)到1000名用戶(hù)在線(xiàn)的狀態(tài)。

這有助于不同規(guī)模的企業(yè)通過(guò)自行調(diào)整來(lái)深入挖掘方案與自身需求的匹配度。你們是否也想趕緊嘗試這種方案，以降低成本并提高性能？期待大家點(diǎn)贊、分享，并在評(píng)論區(qū)交流你的看法。