作者:靈輪_（阿里云前端技術專家）_
作為前端工程師，我們的使命是為用戶提供良好的前端用戶體驗，隨著云原生時代的到來，顯而易見的，我們能做的更多了，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 云產品就像是前端工程師的“武器庫”，我們可以使用這些云產品來為我們的客戶提供高質量的服務，
函式計算 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 了，
使用“自定義運行時”時，我們無需改造代碼就可以將 SpringBoot、Flask、Express、NextJS、NestJS、Gin 等 Web 框架開發的應用跑在函式計算上，只需在函式計算中配置應用監聽的“埠號”和“啟動命令”即可，它和使用傳統服務器的部署方式非常類似，下圖中的代碼，對熟悉 Express 框架的同學來說，應該是再熟悉不過了，
使用“容器鏡像”時，我們可以完全定制應用的執行環境，不用學習如何更新函式計算運行環境中的 Linux 版本，GCC 版本，安裝各種依賴，字體等問題，此外，因為容器鏡像的可移植性極好，我們不用擔心被云廠商系結，同一個容器可以運行在云上或本地資料中心的服務器上，或者是云上或本地資料中心的 Kubernetes 集群里，甚至您可以同時將一個鏡像部署在服務器、Kubernetes 集群和函式計算里，通過幾款不同的產品完成災備，
總結
通過函式計算 FC 等 Serverless 云產品，我們無需管理服務器等基礎設施，Serverless 云產品會為我們準備好資源，以彈性、安全、可靠的方式運行我們的應用，存盤我們的資料，并為我們提供其他額外的附加價值，
Serverless 的免運維特性與前端工程師天然互補，前端工程師只需撰寫業務代碼，即可快速搭建云原生的現代化的 Web 應用，讓前端工程師可以將更多的時間專注在為用戶創造價值上，
更多內容關注 Serverless 微信公眾號（ID：serverlessdevs），匯集 Serverless 技術最全內容，定期舉辦 Serverless 活動、直播，用戶最佳實踐，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/539527.html
標籤：其他
上一篇：約瑟夫環問題