Serverless 應用實踐及典型案例解析

時間 2020-07-26

標籤 serverless 應用實踐典型案例解析简体版

原文原文鏈接

本文整理自 ServerlessDay · China 大會 - 《Serverless 應用實踐及典型案例解析》的分享，講師爲騰訊雲 Serverless 高級架構師盧萌凱、獵豹移動前端總監董文梟、江娛互動技術經理董文強、新東方高級工程師李墾。前端

本文主要分爲四部分：node

Serverless 的優點和價值
基於 Serverless 構建 REST API
Serverless 和服務端渲染的結合
Serverless 構建音視頻轉碼方案

Serverless 的優點和價值

爲何咱們投入這麼大時間和精力來作 Serverless 呢？由於咱們堅信雲計算的將來趨勢之一就是 Serverless。由於 Serverless 讓雲服務的應用變得更加簡單、高效。好比用雲主機部署應用的時候，不只要搭建和維護環境，同時也要評估業務的資源用量，尤爲是對於運營類的活動，若是一旦評估的不許確，要麼會形成資源的巨大浪費，要麼服務可能會被打爆，甚至停服下線。git

而 Serverles 可以作到按需使用，讓業務完美的彈性伸縮，對於運維同窗來說，簡直不能更爽。並且和預付費的實例不一樣，Serverless 是 pay as you go的模式，只有當業務運行時纔會佔用資源，只有源被佔用了纔會計費，簡單來說，就是，我實際用多少就付多少錢。這種計費模式對於存在明顯波峯波谷的服務，優點至關明顯。程序員

另外，雲計算的發展，必定是讓用戶更加專一於業務。而對於運維來說，那些繁瑣的且對業務發展沒有核心價值的資源維護工做，就能夠 offload 給雲廠商，這樣就能更加專一業務層面的運維。這就是 Serverless 所帶來的價值，他不只把用戶對雲的使用成本降到了最低，也最大程度上的加速了應用的上線過程。github

咱們也能夠回顧下雲計算出現及發展的這些年裏，和自建 IDC 相比，用戶就是愈來愈聚焦業務，資源的使用效率也愈來愈高，而 Serverless 在當下把這些優點作到了極致。數據庫

咱們再來簡單看下雲函數是怎麼構成 Serverless 架構，以及Serverless應用具體是怎麼運行的。express

開發者在實際使用時，能夠藉助 WEB IDE 或者本地 IDE 完成代碼開發，而後經過在線或者插件、工具的方式把代碼以及所用到的相關依賴，一塊兒打包部署到雲函數平臺，在代碼裏，咱們能夠像傳統開發方式同樣去調用後端的 BaaS，好比訪問數據庫、對象存儲、消息隊列、第三方服務接口等。計算邏輯和後端服務共同構成了所謂的 Serverless 應用架構。編程

而終端用戶根據平臺提供的請求方式，去觸發部署在雲函數平臺上的業務代碼，好比發送 http 請求等，平臺會根據用戶的請求量去拉起相應的計算資源去運行用戶代碼。平臺會保障資源的可用性和彈性伸縮，所以用戶只用關注和聚焦業務及其運行狀況。後端

基於 Serverless 構建 REST API

接下來進入今天的正題，首先咱們來看下 REST API 這個場景。這裏會用到 Serverless Framework 來輔助開發和部署。藉助 Serverless Framework 的 SCF 組件，咱們能夠把本地開發好的 REST API 應用快速部署到雲上，咱們只須要提早寫好相應的 yaml。Serverless Framwork 會基於 yaml 裏的配置信息，快速建立雲函數、API 網關等雲資源。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 是雲計算的必然趨勢，也是雲原生的應用場景之一，期待你們可以有更多的嘗試和分享。