您好,登錄后才能下訂單哦!
怎么搭建彈性可擴展的WebAPI,很多新手對此不是很清楚,為了幫助大家解決這個難題,下面小編將為大家詳細講解,有這方面需求的人可以來學習下,希望你能有所收獲。
常見的 WebAPI 架構如上圖所示,主要包括客戶端(瀏覽器)、服務器、數據庫,WebAPI 由服務器提供,同時服務器要完成負載均衡、登錄鑒權的相關操作。
當客戶端流量快速增大時,服務器端只能通過水平擴展加機器的方式來增加提高服務能力。
這種常規模式主要有兩點局限性:
技術同學除了開發業務代碼,有大量的服務器運維成本,來保證服務的穩定性、可用性,技術同學要花費很多時間進行運維工作,占用開發時間,降低項目研發效率。
流量突然增加時,需要水平擴展加機器,彈性的響應能力差,擴容速度往往要數十分鐘,無法實現秒級極速擴容,導致一段時間內的服務能力不足。同時當流量變少時,難以做到及時縮容,造成機器的成本浪費。
基于函數計算的 WebAPI 架構如上圖所示,與常規的 WebAPI 架構相比,客戶端和數據庫未發生變化,但服務器變化巨大,主要體現在:
之前需要開發團隊維護的路由模塊以及鑒權模塊都將接入服務商提供的 API 網關系統以及鑒權系統,開發團隊無須再維護這兩部分的業務代碼,只需要持續維護相關規則即可。
在這個結構下,業務代碼也被拆分成了函數粒度,不同函數表示不同的功能。
我們已經看不到服務器的存在,是因為 Serverless 的目的是讓使用者只關注自己的業務邏輯即可,所以一部分安全問題、資源調度問題(例如用戶量暴增、如何實現自動擴容等)全都交給云廠商負責。
相對于傳統項目而言,傳統項目無論是否有用戶訪問,服務都在運行中,都是有成本支出,而 Serverless 而言,只有在用去發起請求時,函數才會被激活并執行,且會按量收費,可以實現在有流量的時候才有支持,沒有流量的時候就沒有支出,相對來說,成本會進一步降低。
可以通過兩種方式來創建應用,如果是已有的 Web 項目,可以選擇上圖中的第一種方式:“常見 Web 應用”;對于新項目則推薦使用第二種方式:“基于模板創建應用”。我們這里使用模板方式,選擇基于 Python 的 Web 應用。
模板可以當做應用腳手架,選擇適合的模板,可以自動完成相關依賴資源的創建,如角色、OSS、域名網關等,降低開發成本。
在應用下,創建函數,我們是開發 WebAPI,所以選擇“HTTP”函數,這種函數會將指定的 http 請求作為觸發器,來調度對應函數的執行。
函數新建好之后,是個返回 helloWorld 的 demo,我們在此基礎上來開發我們的業務邏輯。
首先介紹下上圖代碼中的 handler 函數,這個函數是入口函數,http 觸發器接收到調用后會通過這個入口來啟動整個函數。函數有兩個入參,environ 和 start_response:
environ
environ 中主要包含兩部分內容:http 請求的入參和函數執行上下文 fcContext,函數上下文參數中包含一些函數運行時的信息(例如 request id 、 臨時 AK ),您在代碼中可以使用這些信息。信息類型是 FCContext。
start_response
該參數主要用于生成 http 請求的 response。
在新建函數時會自動創建一個 http 觸發器,這個觸發器的路徑是“aliyun.com”的一個測試路徑,只能用于測試,真實的應用需要通過自定義域名將真實域名與函數綁定,這樣訪問指定域名時,對應函數就會被觸發執行。
在每個函數編輯頁面,日志和監控服務,函數的每次執行都會生成唯一的 requestId,日志中通過 requestId 進行查詢,看到本次函數執行的所有日志。
看完上述內容是否對您有幫助呢?如果還想對相關知識有進一步的了解或閱讀更多相關文章,請關注億速云行業資訊頻道,感謝您對億速云的支持。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。