如同 iPhone 當年颠覆了諾基亞，Serverless 的出現也帶來了一種全新的、颠覆式的雲開發架構模式。在 Serverless 出現前，開發者們根本無法想象幾分鐘就能快速部署一個 Web 應用上線。近日，亞馬遜雲科技 Tech Talk 特别邀請了資深無服務器技術專家孫華帶來分享《 如何高效、極簡構造無服務器 Web 應用》。孫華以 Amazon Lambda 的視角介紹了無服務器 Web 應用的構造方式，并講述了如何利用最新發布的 Lambda Function URLs 和 Lambda Adapter 進一步簡化無服務器 Web 應用的開發和調試并且實現 Web 應用在 Lambda，Fargate 和 EC2 等計算平台之間平滑遷移。

2012 年，Iron 公司首次提出 Serverless 的概念。2014 年亞馬遜雲科技發布 Amazon Lambda 第一次讓 Serverless 從概念走向落地，也标志着 Serverless 時代的開啟。孫華認為，Amazon Lambda 作為無服務器計算服務，主要有以下四個特點。

• 無需部署管理基礎設施：無服務器計算并不代表真的沒有服務器，而是不需要管理部署服務器。
• 自動擴展：不用考慮擴容、容量規劃的問題，底層的服務會自動實現按需擴容。
• 按需付費：按照時間和使用量收費，避免為閑置計算資源浪費。
• 高度可靠與安全：基于高可用架構開發，可用性高。

Amazon Lambda 的出現為應用開發和部署提供了極簡的模型。目前，Amazon Lambda 已有數十萬用戶，用戶的調用峰值通常超過每秒超過百萬級。

可口可樂公司就是 Amazon Lambda 的用戶之一。在疫情期間，可口可樂通過 Amazon Lambda 僅用一周時間就快速把 mobile pour 應用的原型上線，實現手機與飲料機毫秒級的通訊，從創意到交付的時間縮短了 50%。

Babble 是一家線上教育服務商。疫情期間，線上學習訪問量激增 2-3 倍。Babble 通過将服務遷移到 Amazon Lambda 服務器，P95 性能提高了 250ms (降低近 50%)，且通過提高利用率，成本降低了四分之一。

Serverless 架構常見的應用場景有數據處理、IT 運維自動化等，不少用戶還會将 Serverless 應用到前端的 Web 應用上，包括 Flask、Django、Express.js、Rails 等應用。Serverless 可以渲染相應的 Web 頁面到客戶端，同時也支持提供 json 的 Rest API，進行前後端的分離，靜态的 React、Angular、Vue 前端通過 HTTP 請求, 來調用後端的 API，獲取數據，從而展示給客戶。此外，手機後端應用也經常會使用 Serverless 開發小程序的後端。

無服務器 Web 應用有哪些特點呢？首先，最常見的 Web 應用開發方式，服務器裡面運行的是 Web 應用進程，此時，Web 應用會監聽到一個端口。并且，在 Amazon Lambda 裡面每個請求都是由一個單獨的計算實例來處理的，不管 CPU 還是内存，都專門為這一個請求服務。這種方式的優勢在于，可以将每個請求全部隔離開，不會出現某一個請求崩潰，影響其他用戶的并發需求。

其次，Web 應用在 Amazon Lambda 裡面運行，需要是無狀态的應用。因為 Amazon Lambda 請求會随機分發到多個計算實例上，每個計算實例在本地緩存數據，下一個請求進入，可能不會分配到同一個實例上。所以，如果需要共享狀态，可以存儲在 Redis 或者數據庫中。

第三，在 Amazon Lambda 的計算環境上，每次調用的請求處理完畢後，計算環境會被凍結到下一次請求來之前。在這段時間裡是沒有 CPU 資源的，後台任務不能運行，所以不能在 Amazon Lambda 裡面運行後台的進程。

最常見的基于前後端分離的 Web 應用架構，通常會把前端的 SPEA 應用放在 Amazon S3 上做 HTTP、Django 等，前端用 CDN 加速。用戶下載了前端後，前端會通過 API Gateway，來調用後端動态的數據。API Gateway 提供相應的 HTTP 的入口，觸發 Lambda 函數，從而運行 Web 應用。Web 應用可以訪問數據庫或者任何後端。

亞馬遜雲科技經常會收到客戶的反饋。客戶希望在 Amazon Lambda 上學習運行 Web 應用或者将單獨的應用運行在 Lambda Function 裡面。在 Lambda Function 裡面處理所有 URL 相應的業務邏輯，隻需要暴露一個 HTTP 入口就可以了，幾乎不需要任何額外的學習成本。上個月，亞馬遜雲科技推出了 Amazon Lambda 内置的 Function URLs 端口，在 Lambda 函數裡配置一個 Function URL，就可以提供 HTTPS Endpoint。目前該功能僅在 Amazon Global 提供，在中國區會于近期上線。Function URLs 指向 Amazon Lambda 的最新版本，或者是 Amazon Lambda 别名。Amazon Lambda 别名可以指向 1～2 個 Amazon Lambda 的版本，因此可以通過指向 alias 的方式進行灰度發布或者藍綠部署。

Lambda Function URLs 與 API Gateway 之間有什麼區别？

首先，Function URLs 是非常簡單地内置提供 HTTP 入口的方式。它是暴露在公網上的 HTTP 入口，其入口方式是 HTTPS 的，認證方式可以采用 IAM 的權限控制或者在公網上實現。Function URLs 不提供 Custom domain 支持，但是提供 CORS 支持，因此可以跨站請求，比如，浏覽器發來 Option，Function URLs 會主動根據配置，返回相應的結果，不會觸犯 Lambda 函數。但是，Function URLs 隻具備一些簡單的功能，對于一些高級的功能沒辦法實現，比如，使用 Usage Plans，基于 WAF 的集成和在内部提供 Private Enedpoint，目前 Function URLs 是無法實現的。因此，如果想使用 WAF、Usage Private、Private Enedpoint 等功能，請使用 API Gateway 的 Rest API。

其次，Lambda Function URLs 的超時時間是與函數的超時時間是一樣的，比如，函數最長要運行 15 分鐘，Lambda Function URLs 請求就可以運行 15 分鐘，而 Rest API 和 HTTP API 的超時時間僅為 29-30s。在 Payload Size 上，Function URLs 跟 Amazon Lambda 是一樣的，均為 6MB。

第三，采用 Lambda Function URLs 不需要支付額外的費用，但是采用 Rest API 與 HTTP API 都需要支付相應的費用。

很多用戶需要 Web 應用有相應的自定義域名訪問網站。這時，可以在前面通過 CDN 的方式，加上自定義域名，比如，在 CloudFront 上加上自己的域名，同時結合 Amazon WAF 進行相應集成應用的防護。因為 Function URLs 隻提供 HTTPS 的入口，在 CDN 回源的時候，是通過 HTTPS 回到源站的，不能把 Host Header 傳回源站，不能獲得用戶真正訪問的自定義域名。如果域名是固定的，可以在應用裡通過配置了解，但如果域名不是固定的，那麼就需要根據二級域名确定是哪個租戶在做相應的處理。這種情況下，就可以利用 CloudFront Function 的功能。CloudFront Function 可以在用戶請求端獲取域名，加到另外的 Header 裡面，再把 Header 傳回源站，在源站的應用裡面就可以通過這個 Header 獲得用戶訪問的真實的域名。

如果基于 Lambda Function URLs 部署單函數的的 Web 應用，前面通過 CloudFront 做動态請求的代理，靜态資源放在 Amazon S3，就會統一為如下架構，也就不需要 API Gateway 了。

Lambda Function URLs 為大家提供了一個非常簡單就可以獲得 HTTP 入口的方式，但是 Amazon Lambda 的開發方式是基于事件驅動的方法來進行開發的，會将事件源過來的事件轉換為 json 對象。對于熟悉 Web 應用開發的開發者，會有額外的學習成本，一般采用的做法是在應用裡面寫一個 Handler 函數，進行一層轉換，把 json 轉成 Web 應用需要的格式，但是這種方式可以進一步簡化。

亞馬遜雲科技推出的新工具 Lambda Adapter 作用就是幫助用戶完成轉化。采用 Lambda Adapter 無需修改代碼即可在 Amazon Lambda 上運行 Web 應用。Lambda Adapter 從 Amazon Lambda 獲得相應的 json 對象，把它轉換成 HTTP 請求，發送到 Web 應用上，Web 應用處理之後通過 HTTP Response 回到 Lambda Adapter，Lambda Adapter 會将它轉換成 Lambda 需要的 json Response 的格式。這樣不管用什麼語言，什麼樣的 Web 框架，開發 Web 應用或者 HTTP API，都可以通過這樣的方式，不需要修改代碼，也不需要添加任何的依賴，就可以在 Amazon Lambda 上運行，且不需要用特殊的工具，就可以用熟悉的方法在本地開發調試 API。

此外，Lambda Adapter 支持 API Gateway 的 Rest API、HTTP API，作為 HTTP 的事件源。不管是哪種格式，Lambda Adapter 都可以做相應的解析并轉換。同時因為 Lambda Function URLs 的事件格式和 API Gateway HTTP API V2 事件格式完全一緻，所以 Lambda Adapter 不用做任何的修改，就可以接入 Lambda Function URLs。用戶結合 Lambda Function URLs 和 Lambda Adapter 就可以把 Web 應用或者 HTTP API 運行在 Lambda 上面。同時，因為 Web 應用有可能返回圖片等 Binary 數據，因為 json 裡面是不能直接存 Binary 數據的，所以 Binary 數據要做 base64 encoding，Lambda Adapter 會檢測返回的數據是不是 Binary 數據，并且自動完成 base64 轉碼工作。

同時，Adapter 支持用容器鏡像的方式打包函數，也支持用 zip 的方式來打包函數。當用戶使用容器鏡像的方式打包函數，得到的容器鏡像既可以在 Amazon Lambda 上運行，也可以在容器環境裡面運行，甚至在本地的電腦上運行。所以 Web 應用可以非常方便地運行在不同的計算平台上，不需要做修改，就可以在不同的平台之間平滑地遷移。

通過 Lambda Function URLs 和 Lambda Adapter 可以很方便的通過熟悉的 API 的方式，構建了 Web 應用。但是如果用 Lambda Adapter，是否可以把現有的 Web 應用運行在 Amazon Lambda 上呢？

亞馬遜雲科技用 WooCommerce 進行了嘗試。WooCommerce 是一個電商的場景，為什麼要嘗試将 WooCommerce 運行在 Amazon Lambda 上呢？首先，在 Buildwith 網站上，訪問量最大的一百個網站中，WooCommerce 所占份額第一；其次，Wordpress 是基于 PHP 開發的，PHP 在 Web 應用網站建設上，大概有 70-80% 的網站是基于 PHP 開發的，使用量非常廣；第三，PHP 語言，每個請求進入，都需要重新進行初始化，同 Amazon Lambda 無狀态的計算環境非常契合。

亞馬遜雲科技團隊采用了如下無服務器 WooCommerce 架構，在 Amazon Lambda 上運行 WordPress。

該架構前面部分采用 Route53、CloudFront 做 CDN，用 Amazon Lambda 運行應用，前端用 Lambda Function URLs 代替 API Gateway 作為入口，并将靜态資源通過 Amazon S3 存儲。然後，在 Lambda 函數裡面通過 Docker 鏡像的方式，把 PHP Runtime、NGINX Server 和 PHP FPM 運行的進程管理服務加載進來，把 Wordpress 與 WooCommerce 代碼打包進去。後端用相應的數據庫，比如 Redis、最新的 V2 數據庫做數據的緩存，用 EFS 共享的系統來保存用戶上傳的文件。通過該架構，亞馬遜雲科技實現了在 Serverless 基礎上運行 WordPress。

在 Serverless 上運行網站實際性能如何呢？如果在 WordPress 的網站想要做到比較好的性能，可以把 WordPress 靜态化，變成靜态内容放在前端的 CDN 網站上。如果運行的是 WooCommerce 電商網站，用戶浏覽商品、将商品加入購物車、提交訂單、支付，是動态請求，需要回到後端的 PHP 應用上。對于靜态應用，性能方面可以做到 3 分鐘内從無請求到最高峰值，每分可處理 2 萬多筆訂單，持續 1 小時。成本方面，每處理一筆訂單需要調用 10 次 API，也就是處理 100 萬筆訂單需要調用 1000 萬次 Lambda 函數。據統計，1000 萬次 Lambda 函數調用的費用也僅為 300 美元。不僅如此，在測試過程中網站的 API 響應時間也非常平穩，P99 延遲僅為在 1-2s，P50 延遲隻有 500ms 左右。

分享的最後，孫華針對 Serverless 上運行網站實際性能進行了演示，并提供了 Serverless 相關的資料，感興趣的開發可掃描下方二維碼進行獲取。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!