聊聊與前端工程師天然互補的 Serverless

阿里云云原生發表於2022-12-14

頭圖.jpg
作者:靈輪_(阿里雲前端技術專家)_

作為前端工程師,我們的使命是為使用者提供良好的前端使用者體驗。隨著雲原生時代的到來,顯而易見的,我們能做的更多了。Serverless 產品的特點是免運維、按量付費和自適應彈性,所以我們可以利用雲上的各種 Serverless 能力,用相對更低的成本開發出更酷的產品,為我們的客戶創造更多價值。

如何構建雲原生現代化的 Web 應用?

讓我們先回顧一下,我們是如何把一個靜態網站釋出出去的。

在雲原生時代之前,我們想到的可能是需要先找一臺伺服器,安裝 Nginx,然後上傳靜態檔案,再經過一系列的配置,最終完成網站的釋出。完成這些以後,發現已經花掉了小半天的時間,實際上這些花在運維上面的時間其實並沒有為我們的客戶創造價值。但這其實還只是一個開始,隨著業務的發展,穩定性、彈性、安全和成本等問題,我們都要逐一解決,我們花在運維上的時間和精力會越來越多。否則,這個網站可能只是一個玩具。
但是隨著雲原生時代的到來,釋出靜態網站簡單了很多,我們可以透過雲產品,輕鬆地託管我們的網站。例如,可以將網站透過阿里雲物件儲存 OSS 提供的工具,將靜態資源上傳到 OSS,然後開啟一鍵託管。此外,為了讓客戶能夠更快地開啟頁面,還可以透過阿里雲 CDN,將 OSS 設定為 CDN 的源站,從而讓靜態資源離客戶更近,讓客戶的使用體驗更好。這兩款產品都是按量付費的免運維 Serverless 產品,它們大大地減少了我們各種繁雜的運維成本。我們可以把更多的時間花在研發和體驗上,為我們的客戶創造更多價值。

但是隨著業務的發展,我們的網站如果並不只是一個靜態網站了呢?

  • 對外服務的 API(需要對接快取,資料庫,訊息佇列,檔案儲存等)
  • 定時執行任務,甚至是執行海量任務
  • 傳送電子郵件/簡訊/即時訊息(釘釘,微信,飛書),撥打智慧語音電話
  • 對使用者上傳的圖片,音影片等進行處理(轉碼,縮圖,鑑黃,加水印,GPU 推理)
  • 服務端渲染 SSR 頁面
  • 大促,秒殺
  • 採集使用者在網站上的行為,分析如何提高使用者的轉化率

面對這些需求,難道我們又要去找伺服器?為了保證服務的穩定性,彈性,安全和成本,難道我們又要把大量的時間花在運維上?有沒有云產品可以像 OSS/CDN 解決靜態網站的運維問題一樣,解決我們的這些後端需求呢?

面對這些挑戰,阿里雲的 Serverless 產品函式計算 FC 是一個不錯的選擇。除了透過函式計算 FC 處理 API 請求和大規模任務之外,還可以在函式計算 FC 中訪問阿里雲的 RDS、SLS、Tablestore、NAS 等豐富的雲服務或者是其他第三方服務,從而滿足對儲存,計算,網路,安全,大資料,人工智慧等各種業務的需求。

各種 Serverless 雲產品就像是前端工程師的“武器庫”,我們可以使用這些雲產品來為我們的客戶提供高質量的服務。

image.png

函式計算 FC 的優勢和相關原理介紹

極致彈性,輕鬆應對流量洪峰

函式計算 FC 會根據請求量自動進行毫秒級彈性擴容,快速排程計算資源。從而使我們可以輕鬆應對海量 API 請求和大規模的併發任務。

在使用函式計算時,可以為函式配置一個“例項併發度”,這個併發度代表一個函式例項最多可以同時處理多少個請求。函式例項本質上是一個 Linux 安全容器,它是函式對外提供服務的最小單元。

例如,在“例項併發度”設定為 20 時,如果函式計算平臺同時收到了 100 個請求,則會拉起 5 個函式例項來處理這些請求。處理完這些請求後函式例項會被凍結,如果在接下來的 2~5 分鐘內(例項凍結以後就不再計費了)如果沒有新的請求,函式例項將被自動銷燬。在某些場景下,如果業務對延遲非常敏感,或者業務程式碼啟動很慢,可以透過配置彈性規則,設定最小函式例項數量,這樣函式計算 FC 會預先啟動好函式例項,從而保證使用者的使用體驗。也可以透過設定函式例項的最大數量,限制函式例項的最大數量,從而保護下游服務,並控制成本。

對比傳統伺服器模式下需要自己進行伺服器的擴容縮容的操作,函式計算 FC 這種自動彈性的方式不僅可以減少此類繁鎖的擴縮容運維操作,也可以避免傳統伺服器模式下由於擴容不及時導致的業務不可用,從而提高系統的穩定性。

降低成本,提高資源利用率

函式計算 FC 中可以自由配置 CPU,記憶體,GPU 等例項的規格。最小可以建立 0.05 核,128 MB 的函式,並提供了極小梯度的規格選擇,基本可以做到應用需要什麼規格就配置什麼規格。

函式計算 FC 的計費是毫秒級別的,比如我們的程式碼業務邏輯執行的時間為 5 毫秒,那麼我們只需為這 5 毫秒進行付費。並且在無流量時,函式計算 FC 會將函式例項縮容到 0。這對業務量還沒有起來的新業務,或者是一些呼叫本身就很少的中長尾業務非常友好,我們無需為它們付出固定的伺服器費用。

自由配置規格,毫秒級別計費,縮容到 0 等特點可以幫助我們大幅提升資源利用率,極大的降低成本。

免運維,更安全

在傳統的伺服器架構中,我們時刻需要關心執行應用的物理機的資源使用情況。在函式計算 FC 中,我們無需關心底層物理機的資源使用情況,函式計算 FC 平臺會自動排程並運維資源。但是如果是我們的業務程式碼消耗了過度的資源,例如發生OOM 等,函式例項會自動重啟,請求會失敗,這時我們需要根據監控指標和日誌找出程式碼中的問題,或者修改函式的規格,給函式例項更多的資源。

函式計算 FC 也提供了函式預設的 HTTP/HTTPS 域名,從而方便我們訪問函式。同時也支援繫結自己的域名到函式。所以相對於傳統的伺服器架構,在使用函式計算時,我們就免去了對應用伺服器和負載均衡伺服器的運維和購買成本。

從安全的角度出發,由於傳統伺服器需要一直執行著,在安全配置不合理時,或是沒有及時修復程式碼漏洞時,駭客可以透過掃描 IP 和埠,發現並攻入伺服器。函式計算FC因為不會一直起著例項,也不會直接將 IP 暴露在公網上,因此可以避免此類被掃描攻破的問題發生。

除此之外,作業系統的安全漏洞我們也無需關心,在出現安全漏洞時函式計算 FC 會第一時間完成修復。

在需要訪問其他服務時,函式計算 FC 也會根據配置,自動生成臨時金鑰,這個臨時金鑰的有效期是 36 小時,所以無需將重要的訪問金鑰寫在程式碼裡或配置檔案中,從而降低由於金鑰洩漏產生的風險。

隨著業務的不斷髮展,也可以額外購買阿里雲的 Web 應用防火牆 WAF 產品來保護函式安全。

零改造,研發效率高

函式計算支援建立 3 種型別的函式,“內建執行時”,“自定義執行時”和“容器映象”。並且提供了 API,SDK,控制檯和 Serverless Devs 工具,幫助我們完成應用的開發、構建、部署和觀測。

在使用“內建執行時”時,我們需要按照函式計算 FC 定義的介面規則編寫程式碼處理請求。例如,下面為一個 Node.js 的 API 示例,使用這幾行程式碼建立完函式之後,我們就可以立刻在我們的網站中使用這個 API 了。

image.png

使用“自定義執行時”時,我們無需改造程式碼就可以將 SpringBoot、Flask、Express、NextJS、NestJS、Gin 等 Web 框架開發的應用跑在函式計算上。只需在函式計算中配置應用監聽的“埠號”和“啟動命令”即可。它和使用傳統伺服器的部署方式非常類似。下圖中的程式碼,對熟悉 Express 框架的同學來說,應該是再熟悉不過了。

image.png

使用“容器映象”時,我們可以完全定製應用的執行環境,不用學習如何更新函式計算執行環境中的 Linux 版本,GCC 版本,安裝各種依賴,字型等問題。此外,因為容器映象的可移植性極好,我們不用擔心被雲廠商繫結,同一個容器可以執行在雲上或本地資料中心的伺服器上,或者是雲上或本地資料中心的 Kubernetes 叢集裡。甚至您可以同時將一個映象部署在伺服器、Kubernetes 叢集和函式計算裡,透過幾款不同的產品完成災備。

image.png

總結

透過函式計算 FC 等 Serverless 雲產品,我們無需管理伺服器等基礎設施,Serverless 雲產品會為我們準備好資源,以彈性、安全、可靠的方式執行我們的應用,儲存我們的資料,併為我們提供其他額外的附加價值。

Serverless 的免運維特性與前端工程師天然互補,前端工程師只需編寫業務程式碼,即可快速搭建雲原生的現代化的 Web 應用。讓前端工程師可以將更多的時間專注在為使用者創造價值上。

相關文章