教你 4 步搭建彈性可擴充套件的 WebAPI

作者 | 蕭起 阿里云云原生團隊

**導讀：**本節課程主要分為三個部分，基本概念中介紹基於函式計算的 WebAPI 與普通的 WebAPI 的區別及優勢；開發流程中介紹如何在函式計算的控制檯進行 WebAPI 的開發；操作演示中會例項演示函式計算 WebAPI 的開發過程。

基本概念

常見的 WebAPI 架構如上圖所示，主要包括客戶端（瀏覽器）、伺服器、資料庫，WebAPI 由伺服器提供，同時伺服器要完成負載均衡、登入鑑權的相關操作。

當客戶端流量快速增大時，伺服器端只能透過水平擴充套件加機器的方式來增加提高服務能力。

這種常規模式主要有兩點侷限性：

• 技術同學除了開發業務程式碼，有大量的伺服器運維成本，來保證服務的穩定性、可用性，技術同學要花費很多時間進行運維工作，佔用開發時間，降低專案研發效率。

• 流量突然增加時，需要水平擴充套件加機器，彈性的響應能力差，擴容速度往往要數十分鐘，無法實現秒級極速擴容，導致一段時間內的服務能力不足。同時當流量變少時，難以做到及時縮容，造成機器的成本浪費。

基於函式計算的 WebAPI 架構如上圖所示，與常規的 WebAPI 架構相比，客戶端和資料庫未發生變化，但伺服器變化巨大，主要體現在：

• 之前需要開發團隊維護的路由模組以及鑑權模組都將接入服務商提供的 API 閘道器係統以及鑑權系統，開發團隊無須再維護這兩部分的業務程式碼，只需要持續維護相關規則即可。

• 在這個結構下，業務程式碼也被拆分成了函式粒度，不同函式表示不同的功能。

• 我們已經看不到伺服器的存在，是因為 Serverless 的目的是讓使用者只關注自己的業務邏輯即可，所以一部分安全問題、資源排程問題（例如使用者量暴增、如何實現自動擴容等）全都交給雲廠商負責。

• 相對於傳統專案而言，傳統專案無論是否有使用者訪問，服務都在執行中，都是有成本支出，而 Serverless 而言，只有在用去發起請求時，函式才會被啟用並執行，且會按量收費，可以實現在有流量的時候才有支援，沒有流量的時候就沒有支出，相對來說，成本會進一步降低。

開發流程

1. 登入函式計算控制檯，建立應用

可以透過兩種方式來建立應用，如果是已有的 Web 專案，可以選擇上圖中的第一種方式：“常見 Web 應用”；對於新專案則推薦使用第二種方式：“基於模板建立應用”。我們這裡使用模板方式，選擇基於 Python 的 Web 應用。

模板可以當做應用腳手架，選擇適合的模板，可以自動完成相關依賴資源的建立，如角色、OSS、域名閘道器等，降低開發成本。

2. 新建函式

在應用下，建立函式，我們是開發 WebAPI，所以選擇“HTTP”函式，這種函式會將指定的 http 請求作為觸發器，來排程對應函式的執行。

函式新建好之後，是個返回 helloWorld 的 demo，我們在此基礎上來開發我們的業務邏輯。

首先介紹下上圖程式碼中的 handler 函式，這個函式是入口函式，http 觸發器接收到呼叫後會透過這個入口來啟動整個函式。函式有兩個入參，environ 和 start_response：

• environ

environ 中主要包含兩部分內容：http 請求的入參和函式執行上下文 fcContext，函式上下文引數中包含一些函式執行時的資訊（例如 request id 、 臨時 AK ），您在程式碼中可以使用這些資訊。資訊型別是 FCContext。

• start_response

該引數主要用於生成 http 請求的 response。

3. 配置觸發器，繫結域名

在新建函式時會自動建立一個 http 觸發器，這個觸發器的路徑是“aliyun.com”的一個測試路徑，只能用於測試，真實的應用需要透過自定義域名將真實域名與函式繫結，這樣訪問指定域名時，對應函式就會被觸發執行。

4. 日誌與監控

在每個函式編輯頁面，日誌和監控服務，函式的每次執行都會生成唯一的 requestId，日誌中透過 requestId 進行查詢，看到本次函式執行的所有日誌。