使用無服務架構，億級請求的API服務如何將成本降低兩個數量級
Serverless 是當今軟件架構領域最熱的話題，本文作者使用 Serverless 架構重構了 Readability Parser API，使得 API 成本大幅度下降，儘管其架構是基於 AWS，但對於我們通用的架構仍然具有參考價值。
當我去年加入 Postlight 時，第一個任務是重寫轉碼服務（Readability Parser API）。轉碼服務為稍後閱讀應用程序以及其他服務提供 API 支持，它接受互聯網上任何文章的鏈接，然後返回了該文章的結構化內容展示（它可以從網絡上混亂的內容中提取結構化內容）[1]。
重寫的原因有三個：
API 多年來變得老舊而脆弱，解析結果都存儲在數據庫中，這意味著整個數據庫非常龐大。執行稍微複雜的查詢都有問題，這意味著我們對 API 內部發生了什麼一無所知。同時也存在原始文章如果更改，API 響應將不會包含更新的結果。
最初作者已經不在公司了，新工程師缺乏必要的領域知識。
最重要的是這個服務每月要花費公司大約 10,000 美元。
重寫的幾個目標：
生成功能相同的庫，返回與原始代碼相同的結果。
工程師可以輕鬆貢獻代碼。
減少每月產生的費用。
對於語言，我們選擇了JavaScript。選擇 JavaScript 意味著代碼理論上可以在服務器或瀏覽器中運行。 公司的每個工程師都有 Web 編程經驗，所以選擇 JavaScript 也意味著幾乎每人都可以給新項目提交代碼。 舊的代碼是用 Python 編寫的，但是 Python 缺乏瀏覽器運行的優勢。
為了大幅度降低成本，我們選擇了運行在 AWS Lambda[2] 和 API Gateway[3] 上的無服務器架構，它使用 Serverless 框架[4]來構建和部署。
去年十月，我們發佈了 Mercury Web Parser[5]，結果令人震驚。我們的成本大幅度下降，Mercury Web Parser 每月的成本約為 400 美元，比老的服務的成本要低兩個數量級。 （當然也是因為需求或架構略有不同，以前的費用也包括數據庫費用，而現在的無服務器架構使用緩存，因此存在數據庫開銷。）
以下是我們如何實現的一些細節。
1、使用無服務器架構
假設您以在無服務器環境中滿足需求，採用無服務器架構將大大降低成本。簡單地轉到無服務器環境對降低託管成本有很大幫助。在我們完成改變之後，運行成本降低兩個數量級。即使在切換到無服務器架構之後，仍然有降低成本的餘地。
如果您對 Lambda 沒有任何經驗，則其定價將如下所示：
Lambda 免費套餐包含每月 1M 免費請求以及每月 400,000 GB 秒的計算時間。您為 Lambda 函數選擇的內存大小決定著它們能以免費套餐運行多久。Lambda 免費套餐在 AWS 免費套餐 12 個月的期限到期後不會自動過期，而是無期限地提供給現有的和新的 AWS 客戶。
當您希望在 Lambda上優化成本時，最重要的是該函數分配的內存大小決定運行成本。該成本與執行函數所需的時間成比例增加或減少。
（注意：GB-seconds 是分配給函數的內存及執行時間的計量單位，例如，如果你調用一次 3 秒鐘的函數，並且你已經為該函數分配了 1GB 內存， 就是執行了 3GB-seconds 的計算時間，如果將該分配減少到 512MB，執行時間保持 3 秒，則將計算時間縮短到 1.5GB-seconds。）
這意味著您可以通過加快執行函數所需的時間，降低內存分配或兩者都用來降低 Lambda 成本。由於我們程序的執行速度已經很不錯了，所以降低內存是顯而易見的選擇。
2、降低內存分配
Lambda 的內存分配範圍從 128MB 到 1536MB。降低 Lambda 成本的過程很簡單。持續降低您的 Serverless 配置中的 memorySize 分配，部署，然後關注您的函數的執行延遲。如果我們的函數的延遲在幾個小時後沒有顯示出顯著的變化，那麼我們會保留變化並降低成本。
請記住，每次將函數的內存分配減半時，您的 Lambda 成本大致減半。例如，根據官方的 Lambda 定價計算器，100 萬次調用（不包括免費級別），平均運行 2 秒（不快，不是特別慢），分配 1GB 內存，將花費 33.54 美元。如果使用 512MB，將花費 $16.87。 256MB 花費 $8.54。
對於轉碼服務，我們目前運行的函數使用 256MB 配置。
3、API Gateway Responses 緩存
API Gateway 中的緩存響應可以顯著減少 Lambda 調用。 例如，用戶通常會為相同的文章發起請求。 我們每個月只需要為 API Gateway（使用 0.5GB 內存，1 小時TTL）支付約 14 美元。 在上個月，API 請求中有 52％（2 千萬）由緩存命中返回，這意味著只有不到一半（1870 萬請求）需要調用我們的 Lambda 函數，這可以為我們節省 240 美元。
關於可伸縮性的注意事項
除了節省成本之外，無服務器架構也可能會大大降低維護/配置成本以及複雜性。 我們的 API 可以使用相同的配置，緩存和部署方法來為 1,000 個請求到 100,000,000 個請求提供服務。
此外，隨著服務的擴展，成本並不一定會增加。 畢竟超過一半的 API 請求可以由我們的緩存提供服務。
最終成本
在上述所有優化之後，我們目前運行 Mercury Web Parser API 的成本如下所示：
API 網關
服務費用為137美元
緩存：$ 14
數據傳輸：$ 42（這是以0.09美元/ GB計算）
LAMBDA
請求費用：3美元
計算成本：$ 174（平均2.37s /調用，內存分配256MB）
總成本：$ 370
看好無服務器架構的未來
我們已經使用 Lambda 做了很多事情，從解析網頁到編寫 Slack 機器人; 從批量轉換數十萬張照片到轉碼數十萬部影片。
我們越多使用它，就越認為無服務器架構解決了很多問題。到目前為止，Mercury Web Parser 及其所使用的工具一直是我們決定使用無服務器架構的最佳驗證。
關於我們的轉碼服務
在 Postlight，我們使用了 Mercury Web Parser 來支持：
Mercury AMP 轉換器[6]，任何使用 Google AMP 的網站，只需要加入一行代碼。
Mercury Reader[7] 是超過 100 萬用戶使用的 Chrome 擴展程序，通過點擊按鈕可以消除文章中的廣告和干擾，只留下任何網站上的文字和圖像。
Bloomberg Lens[8]，Chrome 擴展程序和 iOS 共享表應用程序，其中提供有關網絡上任何文章的相關新聞，公司數據和個人信息。
我們還支持數千名每天使用 Mercury 的開發人員從網絡上的任何文章中提取結構化內容。 每月完成 3900 萬個請求，只需 370 美元。
對於每一百萬的請求，花費還不到 10 美元，並且可以輕鬆地擴容。
相關推薦
