當 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 型別的外掛 。如果你對這類外掛的使用感興趣，也歡迎在社群中進行更豐富的實踐與討論。