本文整理自 ServerlessDay · China 大會 - 《Serverless 應用實踐及典型案例解析》的分享，講師為騰訊雲 Serverless 高級架構師盧萌凱、獵豹移動前端總監董文梟、江娛互動技術經理董文強、新東方高級工程師李墾。
本文主要分為四部分：
- Serverless 的優勢和價值
- 基於 Serverless 構建 REST API
- Serverless 和服務端渲染的結合
- Serverless 構建音視頻轉碼方案
Serverless 的優勢和價值
為什么我們投入這么大時間和精力來做 Serverless 呢？因為我們堅信雲計算的未來趨勢之一就是 Serverless。因為 Serverless 讓雲服務的應用變得更加簡單、高效。比如用雲主機部署應用的時候，不僅要搭建和維護環境，同時也要評估業務的資源用量，尤其是對於運營類的活動，如果一旦評估的不准確，要么會造成資源的巨大浪費，要么服務可能會被打爆，甚至停服下線。
而 Serverles 能夠做到按需使用，讓業務完美的彈性伸縮，對於運維同學來講，簡直不能更爽。而且和預付費的實例不同，Serverless 是 pay as you go的模式，只有當業務運行時才會占用資源，只有源被占用了才會計費，簡單來講，就是，我實際用多少就付多少錢。這種計費模式對於存在明顯波峰波谷的服務，優勢相當明顯。
另外，雲計算的發展，一定是讓用戶更加專注於業務。而對於運維來講，那些繁瑣的且對業務發展沒有核心價值的資源維護工作，就可以 offload 給雲廠商，這樣就能更加專注業務層面的運維。這就是 Serverless 所帶來的價值，他不僅把用戶對雲的使用成本降到了最低，也最大程度上的加速了應用的上線過程。
我們也可以回顧下雲計算出現及發展的這些年里，和自建 IDC 相比，用戶就是越來越聚焦業務，資源的使用效率也越來越高，而 Serverless 在當下把這些優勢做到了極致。
我們再來簡單看下雲函數是怎么構成 Serverless 架構，以及Serverless應用具體是怎么運行的。
開發者在實際使用時，可以借助 WEB IDE 或者本地 IDE 完成代碼開發，然后通過在線或者插件、工具的方式把代碼以及所用到的相關依賴，一起打包部署到雲函數平台，在代碼里，我們可以像傳統開發方式一樣去調用后端的 BaaS，比如訪問數據庫、對象存儲、消息隊列、第三方服務接口等。計算邏輯和后端服務共同構成了所謂的 Serverless 應用架構。
而終端用戶根據平台提供的請求方式，去觸發部署在雲函數平台上的業務代碼，比如發送 http 請求等，平台會根據用戶的請求量去拉起相應的計算資源去運行用戶代碼。平台會保障資源的可用性和彈性伸縮，因此用戶只用關注和聚焦業務及其運行情況。
基於 Serverless 構建 REST API
接下來進入今天的正題，首先我們來看下 REST API 這個場景。這里會用到 Serverless Framework 來輔助開發和部署。借助 Serverless Framework 的 SCF 組件，我們可以把本地開發好的 REST API 應用快速部署到雲上，我們只需要提前寫好相應的 yaml。Serverless Framwork 會基於 yaml 里的配置信息，快速創建雲函數、API 網關等雲資源。
接下來分享江娛互動 Serverless API實踐。將從下面三個方面分享
- 為什么要遷移到雲函數
- 遷移后的價值
- 使用雲函數后的一些心得
大概將近一年前，江娛互動策划設計了一個功能，某個服務端的行為會觸發系統通知發送到聊天頻道上。理論上這個設計也沒問題，但是沒有考慮規模，我也不知道上了這么一個功能。上線之后，聊天系統突然來了20倍的請求量沖擊，請求開始大量排隊。玩家發的一句話需要一分鍾后才會送達。
因此緊急加服務器分流，扛過了這一波活動。事后復盤如何避免這種突發請求量高峰，硬堆服務器數量肯定不行，方向當時是考慮這么幾個：彈性伸縮、容器化、雲函數。
最終選擇雲函數是因為它天然適合無狀態 Http 服務的場景。
- 首先從部署便捷性上講，只需要關注到代碼層面就好了，容器、鏡像、服務器的概念完全不用理會。
- 其次就是用多少花多少錢。后半夜沒啥請求量的時候，就沒有成本。
- 最后就是再多的請求量，只要資源上限允許，都可以承載得住，當然，僅限於雲函數這一層。因此決定先試試雲函數。
團隊大概花了不到一個月時間，理清楚雲函數的基本用法並把玩家拉取歷史消息的接口遷移了過去，非常順利，用起來也沒有什么問題，於是決定整體遷移。
這是一套非常棒的成本和性能兼顧的方案。自從遷移之后，聊天服務的API部分，穩定性非常好，隨着游戲用戶越來越多，也無需考慮承載量的問題，而總體成本始終能維持在比較低的水平。偶爾遇到極端的請求量高峰時，也都能正常撐過去，不會引起雪崩的局面。
另外雲函數和其他系統的結合利用，也比較方便，比如消息隊列和日志系統。還有定時觸發器，直接取代了以往找台服務器用 crontab 運行一些定時任務的方法。而我們也在把一些其他的外圍系統用雲函數的方式來做，盡量減少游戲服務端的復雜度。
從程序員的角度看。使用雲函數可以讓開發者更加專注於代碼本身的優化，可以去重新思考需求的本質，重新整理自己的思路。比如循環里要做什么，查詢數據庫時是不是要優化一下SQL，大型的數據明確不用時，是不是先手動把內存釋放掉等等。這對於開發者技術水平的提升，是有很大的好處的。而且帶來的正反饋，就是成本上明顯的減少。
Serverless 和服務端渲染的結合
接下來再來看下 SSR 場景。最早的時候前端應用其實就是 SSR，由服務器端生成 Html 頁面送到瀏覽器端，后來為了提升工程化效率，在前端引入了組件和 MVVM 的開發模式，然后就有了 CSR，典型的如單頁應用，通過在瀏覽器端加載 JS 和 CSS 來完成渲染。但是我們也發現單頁應用對 SEO 不夠友好，另外，單頁應用的首屏加載時間也會比較久，尤其是網絡越差的情況就越明顯。
所以一些公司為了優化用戶體驗，或者優化 SEO，就又開始轉向 SSR。但是對於前端同學來說，需要跑后端，我就得運維一個 node 服務器集群，這個是很頭疼的一件事，還需要了解很多后端的知識，如負載均衡和高並發等。借助 Serverless 可以完美解放前端同學的負擔。
獵豹移動前端團隊在 2016 年的時候開始使用 React，2017 年就開始研究並嘗試 React Server Render，同期 Facebook 的網站已經采用 Isomorphic 技術實現，性能非常好。為了滿足公司業務需求和技術傳承，團隊自研了獵豹的前端技術框架 Koot.js，目前已成為獵豹前端的主要技術方案。
Koot.js 是基於 React、Koa、Webpack 來架構的，其中用 Koa 搭建的 Node 作為開發服務和部署時候的 SSR 服務，頁面渲染主要是用 React+Redux 完成的一套代碼在瀏覽器環境和 Node 環境通用，利用 Webpack 可編程性動態生成配置並執行，打包出多場景（開發、測試和線上環境等）多端代碼（前端、服務端）部署。
具體落地的時候，獵豹移動團隊將自研的 Koot.js 使用 Serverless Framework 進行了封裝，做了一個 Serverless 組件，這樣在其他業務場景需要用的時候就可以直接復用，可以節省不少成本，避免了重復造輪子，降低了出錯的概率。
SSR 項目落地的時候通常不是很順暢，項目部署的時候需要具備服務器技術能力才能和運維順暢溝通，所以項目落地不僅要前端同學掌握后端開發能力還要對運維技術、並發等問題多方面考慮，這對前端技術同學的技術全面行有較高要求。
在這種情況下，去年我們開始接觸 Serverless 技術，Serverless 技術可以降低前端對服務端和運維的技術能力但要求，更適合大部分要做 SSR 的前端團隊。團隊調研了幾大雲廠商 Serverless 服務，綜合比較后，選擇了騰訊雲作為實現 SSR 的 Serverless 服務支持。
騰訊雲 Serverless 提供了比較全面的組件支持，與 Serverless Framework 基本是無縫結合，周邊社區和生態支持也比較到位，使用過程會少踩一些坑。在選定了平台之后就比較順暢了，因為 Serverless Framework 提供了很多標准化的接口，在封裝 Koot.js Serveless 組件的過程中也比較省心。
Serverless 構建音視頻轉碼方案
最后是音視頻轉碼場景，雲函數和對象存儲 COS 的結合，可以很方便的把上傳到 COS 的音視頻，進行自動化的轉碼處理。雲函數里可以基於 ffmpeg 實現自定義的轉碼邏輯，並且對於轉碼后回傳 COS 的文件，還可以自動觸發 CDN 預熱。
憑借雲函數(SCF)的強大聯動能力，將視頻上傳、視頻處理、圖片處理、存儲場景有機地整合為一體。用戶可以自定義轉碼函數，幫助客戶快速搭建定制化任務處理能力，彌補當前單獨雲服務的功能盲點。可以把 ffmpeg 業務方便地從物理機、雲主機或容器中移植到雲函數。雲函數提供豐富的計量方式，幫助用戶獲得顯著的成本優勢。
在每年暑期的時候，都會有大量的學生在新東方的平台學習。以前我們都是在自建的機房里基於服務器和 NFS 來實現音視頻課程的存儲和轉碼邏輯。但是由於暑期流量比較大，IDC 里的服務器不一定能滿足計算需求，同時自建服務的硬件采購周期較長，這里期望尋找一種彈性的方法，既能夠支持快速業務部署，又能高效的完成轉碼功能。
經過對比和選型，最終選定騰訊雲的雲函數。在雲上采用雲函數+ COS 的方式，可以支持彈性伸縮，即使把本地流量全部切到雲上，也能有全部承載。那么新的業務流程，就會加入任務調度模塊，當業務流量過來的時候，可以自動或者手動把流量分別導入自研服務和雲上服務，並在流程里加入了很多高可用的技術，比如通過任務 TraceID 進行全鏈路追蹤、雲端計算失敗本地重新計算一次等。新的方案里，雲端服務開發起來很簡單，且不需要投入太多的運維精力，費用相對也很低，用多少付多少。
Serverless 是雲計算的必然趨勢，也是雲原生的應用場景之一，期待大家能夠有更多的嘗試和分享。
One More Thing
3 秒你能做什么？喝一口水，看一封郵件，還是 —— 部署一個完整的 Serverless 應用？
復制鏈接至 PC 瀏覽器訪問：https://serverless.cloud.tencent.com/deploy/express
3 秒極速部署，立即體驗史上最快的 Serverless HTTP 實戰開發！
傳送門：
- GitHub: github.com/serverless
- 官網：serverless.com
歡迎訪問：Serverless 中文網，您可以在 最佳實踐 里體驗更多關於 Serverless 應用的開發！