當 Amazon Lambda 遇上 Apache APISIX 可以擦出什么火花？

本文通過介紹了 Serverless 的相關內容，引出了一個好的網關在 Serverless 架構下的重要性。而 APISIX 就是這樣的一個網關。

作者程小蘭，API7.ai 技術工程師

什么是 Serverless

Serverless 的基礎概念是將運行服務所需的基礎設施交由云服務提供商管理，以及一些自部署的 Serverless 平臺，從而讓使用 Serverless 的工程師可以專注于面向客戶業務應用層的開發，而不需要在基礎設施的構建、管理、擴容等任務上投入過多精力。

目前，很多云服務提供商也在推出 Serverless 相關的產品。比如 Amazon Serverless 的核心是名為 AWS Lambda 的計算服務。

如下圖所示，和傳統的開發、編譯、部署運行方式不同，使用 Amazon Serverless 計算服務 Lambda，僅需要上傳源文件，選擇執行環境并執行，便能得到運行結果。在該過程中，服務器部署、runtime 安裝、編譯等，都由 Amazon Serverless 計算平臺管理執行。

對工程師來說，只需要維護源代碼和 Amazon Serverless 執行環境的相關配置即可。與此相關的技術還有 BaaS（Backend as a Service，后端即服務），是指我們無需編寫或者管理所有服務端組件，把應用中的各個部分完全外包出去，而 Serverless 則是一種新的運行代碼的托管環境。

為什么需要 Serverless

對于開發人員而言，Serverless 可以對程序執行細節進行抽象，讓業務開發工程師專注于代碼本身。從上圖的對比也可以看出，基于 Serverless 的開發，對于開發人員來說更友好。

從成本角度來看，使用 Serverless 只需按照使用量付費；從服務性能角度來看， Serverless 可以自動響應任何規模的代碼執行請求，可以通過調整函數內存大小優化代碼執行時間和響應時間。

使用 Serverless 時為什么需要一個網關？

雖然 Serverless 對于開發人員提供了非常大的優勢，但 Serverless 服務的使用也存在一些問題。

比如將函數 URL 硬編碼到應用程序中；其次應用程序邏輯的授權和身份驗證問題也比較繁瑣；再者，更新云服務提供商的過程也是一個比較艱巨的工程。

而網關可以天然地解決上述問題，通過二者配合的方式，Serverless 可以更好地解決上述問題。如下圖所示，描述的是如何使用 Amazon Serverless 的相關服務迅速組裝一個簡單的 Web Service，網關將在授權等問題中發揮重要作用。

這里以 Apache APISIX 為例，它為流行的云服務提供商（AWS、Azure）提供 Serverless 框架支持；可以定義一個路由去啟用 Serverless 插件，而不是將函數 URL 硬編碼到應用程序中；同時，為開發人員提供了熱更新函數 URI 的靈活性，更新不同的 FaaS 云服務提供商也沒有什么額外的麻煩；此外，這種方法也減輕了應用程序邏輯的授權和身份驗證問題。

Apache APISIX 與 Serverless

Apache APISIX 是 Apache 軟件基金會下的云原生 API 網關，它兼具動態、實時、高性能等特點，提供了負載均衡、動態上游、灰度發布（金絲雀發布）、服務熔斷、身份認證、可觀測性等豐富的流量管理功能。

我們可以使用 Apache APISIX 來處理傳統的南北向流量，也可以處理服務間的東西向流量。同時，它也支持作為 K8s Ingress Controller 來使用。APISIX 通過插件來擴充生態，目前也內置了各類插件，覆蓋了 API 網關的各種領域，如認證鑒權、安全、可觀測性、流量管理、多協議接入等，當然，也包含很多 Serverless 相關插件。

AWS Lambda 插件

aws-lambda 插件用于將 AWS Lambda 作為動態上游集成至 APISIX，從而實現將訪問指定 URI 的請求代理到 AWS 云。用戶使用該插件終止對已配置 URI 的請求，并代表客戶端向 AWS Lambda Gateway URI 發起一個新的請求。

這個新請求中攜帶了之前配置的授權詳細信息，包括請求頭、請求體和參數（以上參數都是從原始請求中傳遞的），之后 aws-lambda 插件會將帶有響應頭、狀態碼和響應體的響應信息返回給使用 APISIX 發起請求的客戶端。該插件支持通過 AWS API key 和 AWS IAM secrets 進行授權。 插件細節可參考官方文檔或者博客。

Serverless 相關插件匯總

除了 Amazon Lambda，Apache APISIX 目前還支持與 Azure Function、Lua 函數和 Apache OpenWhisk 等 Serverless 相關生態的集成，從而提供了相應的 Serverless 插件，具體如下表所示。

插件名稱	描述
serverless	用戶可以通過 Serverless 插件上傳自定義的 Lua 腳本，并根據配置中的 phase 來指定代碼運行階段。例如在 access 階段對請求進行訪問控制，在 header filter，body filter 階段，對響應頭或響應體進行修改，或者在 log 階段打印個性化日志等。另外，由于 Serverless 插件是熱加載的，因此我們不需要重新啟動 Apache APISIX 便可立即生效。
Azure Function	用于將 Azure Serverless Function 作為動態上游集成至 APISIX，從而實現將訪問指定 URI 的請求代理到 Microsoft Azure 云服務。啟用 azure-functions 插件后，該插件會終止對已配置 URI 的請求，并代表客戶端向 Azure Functions 發起一個新的請求。該新請求中攜帶了之前配置的授權詳細信息，包括請求頭、請求體和參數（以上參數都是從原始請求中傳遞的）。之后便會通過 azure-functions 插件，將帶有響應頭、狀態碼和響應體的信息返回給使用 APISIX 發起請求的客戶端。
OpenWhisk	用于將開源的分布式無服務器平臺 Apache OpenWhisk 作為動態上游集成至 APISIX。啟用 openwhisk 插件后，該插件會終止對已配置 URI 的請求，并代表客戶端向 OpenWhisk 的 API Host 端點發起一個新的請求，然后 openwhisk 插件會將響應信息返回至客戶端。
OpenFunction	用于將開源的分布式無服務器平臺 CNCF OpenFunction 作為動態上游集成至 APISIX。啟用 openfunction 插件后，該插件會終止對已配置 URI 的請求，并代表客戶端向 OpenFunction 的 function 發起一個新的請求，然后 openfunction 插件會將響應信息返回至客戶端。

總結

近年來，隨著微服務架構的出現，很多企業都開始將業務架構遷移到云端，不少云服務提供商也在推出 Serverless 相關的產品，基于 Serverless 的開發已經成為一種十分便利的開發模式。

本文通過介紹了 Serverless 的相關內容，引出了一個好的網關在 Serverless 架構下的重要性。而 APISIX 就是這樣的一個網關，當然本文并未在具體使用細節上進行更豐富的描述，僅僅簡單介紹了 APISIX 中的 Serverless 類型的插件 。如果你對這類插件的使用感興趣，也歡迎在社區中進行更豐富的實踐與討論。