本文整理自 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 應用的開發！
推薦閱讀：《Serverless 架構：從原理、設計到專案實戰》
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/75848.html
標籤：其他