一個簡單的 Serverless 架構例子

Serverless 不是一顆銀彈，它是一種架構理念，有它自己的優勢和適用場景。本文以使用 AWS Serverless 技術構建一個簡單的 microservice 為例，談談這種架構如何節省開發和運維成本。作為該專欄的第一篇文章，筆者也希望能以此拋磚引玉，為此專欄帶來更成熟的觀點和更優秀的文章。

應用場景

首先假設一個場景：公司 A 是做某個垂直領域的電商，剛剛起步，流量不是特別大，但發展勢頭不錯。他們需要一個管理優惠碼的 service，做幾件事情：

1. 添加優惠碼

2. 刪除優惠碼

3. 驗證優惠碼

目前預計上線時需要處理的請求最多每秒 1 個，但隨著公司業務規模擴大，特別是驗證優惠碼的請求量，估計會增長很快。

傳統方案 vs Serverless 方案

實現這個 service 可以有多種方案，先說說非 Serverless 中的一種的解決辦法：

這個方案通過 ELB 將請求分發到處理業務邏輯的 EC2 上，數據則是存儲在 DyanmoDB 里。為保證 High Availability，一開始使用分布在 3 個不同 Availability Zones 的 3 台 EC2，考慮到公司業務增長很快，使用 Auto-scaling Group 確保在需要時能自動添加 EC2 去處理請求。以上為大體架構方面的工作，此外還需要做的事情包括：管理EC2的密匙、定時更新 EC2 系統確保安全性、配置防火牆及 Security Group 確保安全性等等。

搭建這個 service 的費用，拋開網路流量和存儲，單單看 EC2 運行的費用。假設一開始使用的是通用類型實例中的 m4.xlarge，On-demand 的費用一個月一台 EC2 接近 80 美元（EC2 費用計算器）。至少有3台 EC2 一直在跑，也就至少 240 美元。這是剛上線時的預計，隨著業務擴大，整個系統的 scale 也會擴大，成本也會更高。

再來看看 Serverless 的解決方案：

這個方案通過 API Gateway 將不同操作請求觸發相應的 Lambda 函數，並使用 DynamoDB 作為數據存儲。Lambda 函數即業務邏輯的實現。API Gateway 會自動 scale 去應對流量，同樣 Lambda 也會根據流量自動 scale。開發方面，只需要實現 Lambda 函數即可。運維方面，省去了上一個方案中管理密匙、打安全補丁等工作——因為根本沒有機器需要去維護。

使用這個方案的成本，同上一個方案一樣，會隨著公司業務規模的增大而增加。然而不同的是，上一個方案，只要有 EC2 在跑，就需要付錢，不管有沒有請求進來。使用 API Gateway 和 Lambda，是按流量和請求量計費的。拋開網路流量和存儲來算，100萬個請求，API Gateway 目前的收費 3.5 美元。Lambda 則是按照請求量和每個函數的執行時間計費，即使上線第一個月內平均每秒達到 1 個請求（共 60 * 60 * 60 * 24 * 30 = 2592000 個），每個請求運行 10ms，那麼 Lambda 的花費也只是 0.57 美元（Lambda 費用計算器）。總體算下來，第一個月大概成本小於 10 美元。

實際成本會更複雜些，需要將許多其他因素考慮在內。小 scale 的、業務簡單的 service，Serverless 架構帶來的好處很明顯，但如果是一個 scale 很大、業務很複雜的 service，就得從成本、可維護性和可控性方面考慮權衡下了。

總結

總體來看，對於一個低流量的 service，使用 Serverless 明顯得比非 Serverless 節省開發、部署和運維成本。整個流程少了機器，便少了許多工作量。Serverless 在這方面體現出來的優勢，不單單是對剛剛起步的公司成立，對運維著眾多每秒請求量不到 1 的 microservices 的大公司也同樣適用。

目前 Serverless 處於早期發展階段，已經有一些公司（Netflix 使用 Lambda 管理基礎設施，在線課程網站 A Cloud Guru 整站使用 Lambda 及其他 AWS services 搭建）將這種方案運用到實際的 Production 環境里。簡單、低流量的場景目前來看 使用 Serverless 的優勢明顯。隨著這種架構理念的普及推廣和雲服務提供商生態的完善，Serverless 在更多、更複雜領域的實踐值得期待。

A Serverless Pro
推薦閱讀：