當 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 型別的外掛 。如果你對這類外掛的使用感興趣,也歡迎在社群中進行更豐富的實踐與討論。
- RESTful API 為何成為頂流 API 架構風格?
- APISIX Ingress 如何使用 Cert Manager 管理證書
- API 閘道器策略的二三事
- 服務網格領域的百花齊放,是否存在一個更優解?
- 馬蜂窩如何利用 APISIX 閘道器實現微服務架構升級
- 為什麼 APISIX Ingress 是比 Ingress NGINX 更好的選擇?
- 基於 APISIX 的服務網格方案 Amesh 積極開發中!
- 盤點微服務架構下的諸多身份驗證方式
- 2022 Apache APISIX 年度記憶
- APISIX Ingress 對 Gateway API 的支援和應用
- 為什麼 APISIX Ingress 是比 Traefik 更好的選擇?
- 當 Amazon Lambda 遇上 Apache APISIX 可以擦出什麼火花?
- 認證鑑權對於 API 閘道器的重要性
- 馬斯克都不懂的 GraphQL,API 閘道器又能對其如何理解?
- APISIX Ingress 如何支援自定義外掛
- Apache APISIX 玩轉 Tongsuo 國密外掛
- 如何基於 APISIX 迭代數字智聯平臺
- 譯文 | A poor man's API
- APISIX 在君潤人力雲原生平臺的架構實踐