共計 4032 個字符，預計需要花費 11 分鐘才能閱讀完成。

這期內(nèi)容當中丸趣 TV 小編將會給大家?guī)碛嘘P(guān)如何進行 Serverless 應(yīng)用實踐及典型案例解析，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

Serverless 的優(yōu)勢和價值

為什么我們投入這么大時間和精力來做 Serverless 呢？因為我們堅信云計算的未來趨勢之一就是 Serverless。因為 Serverless 讓云服務(wù)的應(yīng)用變得更加簡單、高效。比如用云主機部署應(yīng)用的時候，不僅要搭建和維護環(huán)境，同時也要評估業(yè)務(wù)的資源用量，尤其是對于運營類的活動，如果一旦評估的不準確，要么會造成資源的巨大浪費，要么服務(wù)可能會被打爆，甚至停服下線。

而 Serverles 能夠做到按需使用，讓業(yè)務(wù)完美的彈性伸縮，對于運維同學來講，簡直不能更爽。而且和預付費的實例不同，Serverless 是 pay as you go 的模式，只有當業(yè)務(wù)運行時才會占用資源，只有源被占用了才會計費，簡單來講，就是，我實際用多少就付多少錢。這種計費模式對于存在明顯波峰波谷的服務(wù)，優(yōu)勢相當明顯。

另外，云計算的發(fā)展，一定是讓用戶更加專注于業(yè)務(wù)。而對于運維來講，那些繁瑣的且對業(yè)務(wù)發(fā)展沒有核心價值的資源維護工作，就可以 offload 給云廠商，這樣就能更加專注業(yè)務(wù)層面的運維。這就是 Serverless 所帶來的價值，他不僅把用戶對云的使用成本降到了最低，也最大程度上的加速了應(yīng)用的上線過程。

我們也可以回顧下云計算出現(xiàn)及發(fā)展的這些年里，和自建 IDC 相比，用戶就是越來越聚焦業(yè)務(wù)，資源的使用效率也越來越高，而 Serverless 在當下把這些優(yōu)勢做到了極致。

我們再來簡單看下云函數(shù)是怎么構(gòu)成 Serverless 架構(gòu)，以及 Serverless 應(yīng)用具體是怎么運行的。

開發(fā)者在實際使用時，可以借助 WEB IDE 或者本地 IDE 完成代碼開發(fā)，然后通過在線或者插件、工具的方式把代碼以及所用到的相關(guān)依賴，一起打包部署到云函數(shù)平臺，在代碼里，我們可以像傳統(tǒng)開發(fā)方式一樣去調(diào)用后端的 BaaS，比如訪問數(shù)據(jù)庫、對象存儲、消息隊列、第三方服務(wù)接口等。計算邏輯和后端服務(wù)共同構(gòu)成了所謂的 Serverless 應(yīng)用架構(gòu)。

而終端用戶根據(jù)平臺提供的請求方式，去觸發(fā)部署在云函數(shù)平臺上的業(yè)務(wù)代碼，比如發(fā)送 http 請求等，平臺會根據(jù)用戶的請求量去拉起相應(yīng)的計算資源去運行用戶代碼。平臺會保障資源的可用性和彈性伸縮，因此用戶只用關(guān)注和聚焦業(yè)務(wù)及其運行情況。

基于 Serverless 構(gòu)建 REST API

接下來進入今天的正題，首先我們來看下 REST API 這個場景。這里會用到 Serverless Framework 來輔助開發(fā)和部署。借助 Serverless Framework 的 SCF 組件，我們可以把本地開發(fā)好的 REST API 應(yīng)用快速部署到云上，我們只需要提前寫好相應(yīng)的 yaml。Serverless Framwork 會基于 yaml 里的配置信息，快速創(chuàng)建云函數(shù)、API 網(wǎng)關(guān)等云資源。

接下來分享江娛互動 Serverless API 實踐。將從下面三個方面分享

為什么要遷移到云函數(shù)

遷移后的價值

使用云函數(shù)后的一些心得

大概將近一年前，江娛互動策劃設(shè)計了一個功能，某個服務(wù)端的行為會觸發(fā)系統(tǒng)通知發(fā)送到聊天頻道上。理論上這個設(shè)計也沒問題，但是沒有考慮規(guī)模，我也不知道上了這么一個功能。上線之后，聊天系統(tǒng)突然來了 20 倍的請求量沖擊，請求開始大量排隊。玩家發(fā)的一句話需要一分鐘后才會送達。

因此緊急加服務(wù)器分流，扛過了這一波活動。事后復盤如何避免這種突發(fā)請求量高峰，硬堆服務(wù)器數(shù)量肯定不行，方向當時是考慮這么幾個：彈性伸縮、容器化、云函數(shù)。

最終選擇云函數(shù)是因為它天然適合無狀態(tài) Http 服務(wù)的場景。

首先從部署便捷性上講，只需要關(guān)注到代碼層面就好了，容器、鏡像、服務(wù)器的概念完全不用理會。

其次就是用多少花多少錢。后半夜沒啥請求量的時候，就沒有成本。

最后就是再多的請求量，只要資源上限允許，都可以承載得住，當然，僅限于云函數(shù)這一層。因此決定先試試云函數(shù)。

團隊大概花了不到一個月時間，理清楚云函數(shù)的基本用法并把玩家拉取歷史消息的接口遷移了過去，非常順利，用起來也沒有什么問題，于是決定整體遷移。

這是一套非常棒的成本和性能兼顧的方案。自從遷移之后，聊天服務(wù)的 API 部分，穩(wěn)定性非常好，隨著游戲用戶越來越多，也無需考慮承載量的問題，而總體成本始終能維持在比較低的水平。偶爾遇到極端的請求量高峰時，也都能正常撐過去，不會引起雪崩的局面。

另外云函數(shù)和其他系統(tǒng)的結(jié)合利用，也比較方便，比如消息隊列和日志系統(tǒng)。還有定時觸發(fā)器，直接取代了以往找臺服務(wù)器用 crontab 運行一些定時任務(wù)的方法。而我們也在把一些其他的外圍系統(tǒng)用云函數(shù)的方式來做，盡量減少游戲服務(wù)端的復雜度。

從程序員的角度看。使用云函數(shù)可以讓開發(fā)者更加專注于代碼本身的優(yōu)化，可以去重新思考需求的本質(zhì)，重新整理自己的思路。比如循環(huán)里要做什么，查詢數(shù)據(jù)庫時是不是要優(yōu)化一下 SQL，大型的數(shù)據(jù)明確不用時，是不是先手動把內(nèi)存釋放掉等等。這對于開發(fā)者技術(shù)水平的提升，是有很大的好處的。而且?guī)淼恼答仯褪浅杀旧厦黠@的減少。

Serverless 和服務(wù)端渲染的結(jié)合

接下來再來看下 SSR 場景。最早的時候前端應(yīng)用其實就是 SSR，由服務(wù)器端生成 Html 頁面送到瀏覽器端，后來為了提升工程化效率，在前端引入了組件和 MVVM 的開發(fā)模式，然后就有了 CSR，典型的如單頁應(yīng)用，通過在瀏覽器端加載 JS 和 CSS 來完成渲染。但是我們也發(fā)現(xiàn)單頁應(yīng)用對 SEO 不夠友好，另外，單頁應(yīng)用的首屏加載時間也會比較久，尤其是網(wǎng)絡(luò)越差的情況就越明顯。

所以一些公司為了優(yōu)化用戶體驗，或者優(yōu)化 SEO，就又開始轉(zhuǎn)向 SSR。但是對于前端同學來說，需要跑后端，我就得運維一個 node 服務(wù)器集群，這個是很頭疼的一件事，還需要了解很多后端的知識，如負載均衡和高并發(fā)等。借助 Serverless 可以完美解放前端同學的負擔。

獵豹移動前端團隊在 2016 年的時候開始使用 React，2017 年就開始研究并嘗試 React Server Render，同期 Facebook 的網(wǎng)站已經(jīng)采用 Isomorphic 技術(shù)實現(xiàn)，性能非常好。為了滿足公司業(yè)務(wù)需求和技術(shù)傳承，團隊自研了獵豹的前端技術(shù)框架 Koot.js，目前已成為獵豹前端的主要技術(shù)方案。

Koot.js 是基于 React、Koa、Webpack 來架構(gòu)的，其中用 Koa 搭建的 Node 作為開發(fā)服務(wù)和部署時候的 SSR 服務(wù)，頁面渲染主要是用 React+Redux 完成的一套代碼在瀏覽器環(huán)境和 Node 環(huán)境通用，利用 Webpack 可編程性動態(tài)生成配置并執(zhí)行，打包出多場景（開發(fā)、測試和線上環(huán)境等）多端代碼（前端、服務(wù)端）部署。

具體落地的時候，獵豹移動團隊將自研的 Koot.js 使用 Serverless Framework 進行了封裝，做了一個 Serverless 組件，這樣在其他業(yè)務(wù)場景需要用的時候就可以直接復用，可以節(jié)省不少成本，避免了重復造輪子，降低了出錯的概率。

SSR 項目落地的時候通常不是很順暢，項目部署的時候需要具備服務(wù)器技術(shù)能力才能和運維順暢溝通，所以項目落地不僅要前端同學掌握后端開發(fā)能力還要對運維技術(shù)、并發(fā)等問題多方面考慮，這對前端技術(shù)同學的技術(shù)全面行有較高要求。

在這種情況下，去年我們開始接觸 Serverless 技術(shù)，Serverless 技術(shù)可以降低前端對服務(wù)端和運維的技術(shù)能力但要求，更適合大部分要做 SSR 的前端團隊。團隊調(diào)研了幾大云廠商 Serverless 服務(wù)，綜合比較后，選擇了騰訊云作為實現(xiàn) SSR 的 Serverless 服務(wù)支持。

騰訊云 Serverless 提供了比較全面的組件支持，與 Serverless Framework 基本是無縫結(jié)合，周邊社區(qū)和生態(tài)支持也比較到位，使用過程會少踩一些坑。在選定了平臺之后就比較順暢了，因為 Serverless Framework 提供了很多標準化的接口，在封裝 Koot.js Serveless 組件的過程中也比較省心。

Serverless 構(gòu)建音視頻轉(zhuǎn)碼方案

最后是音視頻轉(zhuǎn)碼場景，云函數(shù)和對象存儲 COS 的結(jié)合，可以很方便的把上傳到 COS 的音視頻，進行自動化的轉(zhuǎn)碼處理。云函數(shù)里可以基于 ffmpeg 實現(xiàn)自定義的轉(zhuǎn)碼邏輯，并且對于轉(zhuǎn)碼后回傳 COS 的文件，還可以自動觸發(fā) CDN 預熱。

憑借云函數(shù) (SCF) 的強大聯(lián)動能力，將視頻上傳、視頻處理、圖片處理、存儲場景有機地整合為一體。用戶可以自定義轉(zhuǎn)碼函數(shù)，幫助客戶快速搭建定制化任務(wù)處理能力，彌補當前單獨云服務(wù)的功能盲點。可以把 ffmpeg 業(yè)務(wù)方便地從物理機、云主機或容器中移植到云函數(shù)。云函數(shù)提供豐富的計量方式，幫助用戶獲得顯著的成本優(yōu)勢。

在每年暑期的時候，都會有大量的學生在新東方的平臺學習。以前我們都是在自建的機房里基于服務(wù)器和 NFS 來實現(xiàn)音視頻課程的存儲和轉(zhuǎn)碼邏輯。但是由于暑期流量比較大，IDC 里的服務(wù)器不一定能滿足計算需求，同時自建服務(wù)的硬件采購周期較長，這里期望尋找一種彈性的方法，既能夠支持快速業(yè)務(wù)部署，又能高效的完成轉(zhuǎn)碼功能。

經(jīng)過對比和選型，最終選定騰訊云的云函數(shù)。在云上采用云函數(shù) + COS 的方式，可以支持彈性伸縮，即使把本地流量全部切到云上，也能有全部承載。那么新的業(yè)務(wù)流程，就會加入任務(wù)調(diào)度模塊，當業(yè)務(wù)流量過來的時候，可以自動或者手動把流量分別導入自研服務(wù)和云上服務(wù)，并在流程里加入了很多高可用的技術(shù)，比如通過任務(wù) TraceID 進行全鏈路追蹤、云端計算失敗本地重新計算一次等。新的方案里，云端服務(wù)開發(fā)起來很簡單，且不需要投入太多的運維精力，費用相對也很低，用多少付多少。Serverless 是云計算的必然趨勢，也是云原生的應(yīng)用場景之一，期待大家能夠有更多的嘗試和分享。

上述就是丸趣 TV 小編為大家分享的如何進行 Serverless 應(yīng)用實踐及典型案例解析了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關(guān)知識，歡迎關(guān)注丸趣 TV 行業(yè)資訊頻道。