花了 1000G，我終於弄清楚了 Serverless （上）：Serverleress 是什麼

花了 1000G，我終於弄清楚了 Serverless 是什麼？

在過去的 24 小時，我通過微信公號的『電子書』一事，大概處理了 8000 個請求：

大部分的請求都是在 200ms 內完成的，而在最開始的請求潮裡（剛發推送的時候，十分鐘裡近 1500 個請求），平均的響應時間都在 50ms 內。

這也表明了，Serverless 相當的可靠。顯然，當請求越多的時候，響應時間越快，這簡直有違常理——一般來說，隨著請求的增加，響應時間會越來越慢。

毫無疑問，在最近的幾年裡，微服務漸漸成為了一個相當流行的架構風格。微服務大致從 2014 年起，開始流行開來，如下圖所示：

而微服務是從 2016 年起，開始受到開發者的關注。並且從其發展趨勢來看，它大有可能在兩年後，擁有今天微服務一樣的地位。可見，它是一個相當具有潛力的架構。

什麼是 Serverless 架構？？

為了弄清 Serverless 究竟是什麼東西？Serverless 到底是個什麼？我使用 Serverless 嘗試了一個又一個示例，我自己也做了四五個應用，總算是對 Serverelss 有了一個大致上的認識。

虛擬化與隔離

開發人員為了保證開發環境的正確（即，這個 Bug 不是環境因素造成的），想出了一系列的隔離方式：虛擬機器、容器虛擬化、語言虛擬機器、應用容器（如 Java 的 Tomcat）、虛擬環境（如 Python 中的 virtualenv），甚至是獨立於語言的 DSL。^full_stack

從最早的物理伺服器開始，我們都在不斷地抽象或者虛擬化伺服器。

• 我們使用 XEN、KVM等虛擬化技術，隔離了硬體以及執行在這之上的作業系統。
• 我們使用雲端計算進一步地自動管理這些虛擬化的資源。
• 我們使用 Docker 等容器技術，隔離了應用的作業系統與伺服器的操作。

現在，我們有了 Serverless，我們可以隔離作業系統，乃至更底層的技術細節。

為什麼是花了 200G ？

現在，讓我簡單地解釋『花了 200G，我終於弄清楚了 Serverless 是什麼？』這句話，來說說 Serverless 到底是什麼鬼？

在實踐的過程中，我採用的是 AWS Lambda 作為 Serverless 服務背後的計算引擎。AWS Lambda 是一種函式即服務（Function-as-a-Servcie，FaaS）的計算服務，簡單的來說就是：開發人員直接編寫執行在雲上的函式、功能、服務。由雲服務產商提供作業系統、執行環境、閘道器等一系列的基礎環境，我們只需要關注於編寫我們的業務程式碼即可。

是的，你沒聽錯，我們只需要考慮怎麼用程式碼提供價值即可。我們甚至連可擴充套件、藍綠部署等一系列的問題都不用考慮，Amazon 優秀的運營工程師已經幫助我們打造了這一系列的基礎設施。並且與傳統的 AWS 服務一樣，如 Elastic Compute Cloud（EC2），它們都是按流量算錢的。

那麼問題又來了，它到底是怎麼對一個函式收錢的。我在 Lambda 函式上執行一個 Hello, world 它會怎麼收我的錢呢？

如果要對一個執行的函式收費，那麼想必只有執行時間、CPU、記憶體佔用、硬碟這幾個條件。可針對於不同的需求，提供不同的 CPU 是一件很麻煩的事。對於程式碼來說，一個應用佔用的硬碟空間幾乎可以忽略不計。當然，這些應用會在你的 S3 上有一個備份。於是，諸如 AWS 採用的是執行時間 + 記憶體的計算方式。

| 記憶體 (MB) | 每個月的免費套餐秒數 | 每 100ms 的價格 (USD) | |----------|---------------------|----------------------| | 128 | 3,200,000 | 0.000000208 | | 192 | 2,133,333 | 0.000000313 | | 256 | 1,600,000 | 0.000000417 | | ... | ... | ... |
| 1024 | 400,000 | 0.000001667 | | ... | ... | ... |

在執行程式的時候，AWS 會統計出一個時間和記憶體，如下所示：

REPORT RequestId: 041138f9-bc81-11e7-aa63-0dbab83f773d Duration: 2.49 ms Billed Duration: 100 ms Memory Size: 1024 MB Max Memory Used: 20 MB

其中的 Memory Size 即是我們選用的套餐型別，Duration 即是執行的時間，Max Memory Used 是我們應用執行時佔用的記憶體。根據我們的 Max Memory Used 數值及應用的計算量，我們可以很輕鬆地計算出我們所需要的套餐。

因此，如果我們選用 1024M 的套餐，然後執行了 320 次，一共算是使用了 320G 的計算量。而其執行時間會被舍入到最近的 100ms，就算我們執行了 2.49ms，那麼也是按 100ms 算的。那麼假設，我們的 320 次計算都花了 1s，也就是 10*100ms，那麼我們要支付的費用是：10*320*0.000001667=0.0053344刀，即使轉成人民幣也就是不到 4 毛錢的 0.03627392。

如果我們先用的是 128M 的套餐，那麼執行了 2000 次，就是 200G 的計算量了。

如果我們先用的是 128M 的套餐，那麼執行了 8000 次，就是 1000G 的計算量了。

不過如上表所示，AWS 為 Lambda 提供了一個免費套餐（無期限地提供給新老使用者）包含每月 1M 免費請求以及每月 400 000 GB 秒的計算時間。這就意味著，在很長的時間裡，我們一分鐘都不用花。

Serverless 是什麼？

而從上節的內容中，我們可以知道這麼幾點：

• 在 Serverless 應用中，開發者只需要專注於業務，剩下的運維等工作都不需要操心
• Serverless 是真正的按需使用，請求到來時才開始執行
• Serverless 是按執行時間和記憶體來算錢的
• Serverless 應用嚴重依賴於特定的雲平臺、第三方服務

當然這些都是一些虛無縹緲地東西。

按 AWS 官方對於 Serverless 的介紹是這樣的：

伺服器架構是基於網際網路的系統，其中應用開發不使用常規的服務程式。相反，它們僅依賴於第三方服務（例如AWS Lambda服務），客戶端邏輯和服務託管遠端過程呼叫的組合。”^aws_serverless

在一個基於 AWS 的 Serverless 應用裡，應用的組成是：

• 閘道器 API Gateway 來接受和處理成千上萬個併發 API 呼叫，包括流量管理、授權和訪問控制、監控等
• 計算服務 Lambda 來進行程式碼相關的一切計算工作，諸如授權驗證、請求、輸出等等
• 基礎設施管理 CloudFormation 來建立和配置 AWS 基礎設施部署，諸如所使用的 S3 儲存桶的名稱等
• 靜態儲存 S3 作為前端程式碼和靜態資源存放的地方
• 資料庫 DynamoDB 來儲存應用的資料
• 等等

以部落格系統為例，當我們訪問一篇部落格的時候，只是一個 GET 請求，可以由 S3 為我們提供前端的靜態資源和響應的 HTML。

而當我們建立一個部落格的時候：

• 我們的請求先來到了 API Gateway，API Gateway 計費器 + 1
• 接著請求來到了 Lambda，進行資料處理，如生成 ID、建立時間等等，Lambda 計費器 + 1
• Lambda 在計算完後，將資料儲存到 DynamoDB 上，DynamoDB 計費器 + 1
• 最後，我們會生成靜態的部落格到 S3 上，而 S3 只在使用的時候按儲存收費。

在這個過程中，我們使用了一系列穩定存在的雲服務，並且只在使用時才計費。由於這些服務可以自然、方便地進行呼叫，我們實際上只需要關注在我們的 Lambda 函式上，以及如何使用這些服務完成整個開發流程。

因此，Serverless 並不意味著沒有伺服器，只是伺服器以特定功能的第三方服務的形式存在。

當然並不一定使用這些雲服務（如 AWS），才能稱為 Serverless。諸如我的同事在 《Serverless 實戰：打造個人閱讀追蹤系統》，採用的是：IFTTT + WebTask + GitHub Webhook 的技術棧。它只是意味著，你所有的應用中的一部分服務直接使用的是第三方服務。

在這種情況下，系統間的分層可能會變成一個又一個的服務。原本，在今天主流的微服務設計裡，每一個領域或者子域都是一個服務。而在 Serverless 應用中，這些領域及子域因為他們的功能，又可能會進一步切分成一個又一個 Serverless 函式。

只是這些服務、函式比以往的粒度更加細緻。

節選自《Serverless 架構應用開發指南》