Categories
程式開發

深入淺出Serverless:優勢、意義與應用 | GMTC


深入淺出Serverless:優勢、意義與應用 | GMTC 1

Serverless 是炙手可熱的技術,被認為是雲計算發展的未來方向。尤其是在前端研發領域,使用 Node 開發雲函數,可以讓前端工程師更加專注於業務邏輯,實現全棧工程師的角色轉變。 Serverless 的優勢技術 Leader 和架構師在進行技術選型時會關注很多指標, Serverless 貢獻最大的就是 研發交付速度(Time to Market)成本(Cost)

研發交付速度方面,衡量的指標是 Time to Market,是從需求產出到上線所用的總時長,Serverless 在這方面的優勢在技術和團隊協作兩個視角上均有體現。

一是技術視角。有一種觀點稱 Serverless 是一種很簡單的技術,我對這種觀點並不完全同意。 Serverless 架構讓用戶和底層架構的關係發生了變化,之前開發者需要關注核心業務邏輯、運維和底層架構的治理,在 Serverless 架構中底層的部分由 Serverless 架構提供方來解決。從整個應用系統的角度來看,系統架構的難度和復雜度並沒有實質簡化。

深入淺出Serverless:優勢、意義與應用 | GMTC 2

Serverless 底層複雜架構(用戶完全不用關注的部分)

這裡我們不展開講 Serverless 架構的底層實現細節。只需要了解一點:Serverless 底層架構做的事情越多,業務層面需要關注的架構和運維工作就越少,因為做的工作少了,所以交付的時間就更快了。

深入淺出Serverless:優勢、意義與應用 | GMTC 3

Serverless 架構下開發者需要關注的兩塊內容

二是團隊協作視角。在 Serverless 的模式下,全棧開發的工作模式會執行得更加順暢。我們知道,前後端分離確實是一種很好的架構模式:細化了分工,降低了耦合,提升了復用。但隨之而來的問題,是團隊間的溝通成本、KPI 目標的差異所帶來的各種催排期、接口確認以及聯調測試。不少技術團隊用全棧開發的模式來解決這些問題, Serverless 下不需要在架構和技術棧花費過多精力,Runtime 和語言也沒有強制依賴,而是完全面向業務,每個前端工程師都可以是全棧的。

另一個優勢就是 Serverless 會大大降低成本,體現在計算資源和人力兩個層面。

在計算資源的成本方面,主要體現在彈性擴縮容量,按需付費。在傳統的計算資源預算時,往往為了能抗住峰值流量,系統容量都有 Buffer,說白了就是日常的浪費。

深入淺出Serverless:優勢、意義與應用 | GMTC 4

在 Serverless 模式下,當業務代碼上線後,一分錢都不需要支付。只有當真實請求和流量過來了,平台才會根據請求量,瞬時拉起對應數量的函數實例,去接收請求和執行業務代碼,此時才需要為真正的代碼執行所消耗的資源付費。No Pay for Idle ,從會計學的角度,Serverless 讓計算資源從固定成本變成了可變成本。這種付費模式對於那種流量波動很大的業務優勢明顯。

深入淺出Serverless:優勢、意義與應用 | GMTC 5

還要說明的是人力成本。很多技術 Leader 總抱怨人手不夠,也許真實情況並非如此,只是沒有足夠比例的人投入到業務功能的開發和迭代上,而是去做了架構、底層等必要的支撐性工作。我承認這些工作確實非常有挑戰、非常必要,也非常重要。在 Serverless 模式下,由於不再需要關注底層架構,所以縮小這部分的工作量和人力佔比,就有了更多的工程師可以放在核心業務上,多做迭代,從而加速產品功能的研發。這不是更高的 ROI 嗎?

Serverless 的適用場景Serverless 適用於事件觸發的場景。當某個事件發生時,拉起並調用 Serverless 雲函數,比如文件上傳、消息隊列中的消息事件、定時器事件,也可以是 IoT 設備的某個事件。還可以用於一些文件處理,比如圖像處理、音視頻處理和日誌分析等場景。

當然,這些事件也包括 HTTP 請求事件,這是 Serverless 的一個很大的適用場景—— HTTP Service,主要實現基於 HTTP 應用的後端服務,比如 REST API、BFF 和 SSR 服務,以及業務邏輯的實現。

我主要關注 Serverless 在 HTTP 場景下的應用。這也是和前端工程師結合最緊密的部分。小到為小遊戲、運營活動提供後端的支持,大到整個 App 或站點的 REST API、BFF,或是 H5 頁面的 SSR,都是 Serverless 適用的場景。

Serverless 對前端開發者的意義Serverless 的諸多優勢業內有很多討論,也有不少文章談及。我想聚焦到前端開發者身上來說一說,Serverless 能夠幫助前端工程師實現真全棧的夢想。可能有人會質疑,為什麼你又提出一個真全棧,和之前的全棧有什麼區別嗎?

深入淺出Serverless:優勢、意義與應用 | GMTC 6

業內對於全棧的定義:前端 + 後端 + 數據庫

我先明確一下真全棧的定義:如何判斷一個工程師是真全棧工程師?當公司有了一堆產品功能需求,招了一個程序員張全佔,如果他能從 0 到 1 把需求做成產品,那才叫真全棧。如果張全佔完成了前端功能開發、後端開發以及數據庫開發,實現了所有的需求功能,並且部署到對應的服務上,就完事了,那麼問題也就來了:服務掛了誰來重啟?環境穩定性誰來做?日誌把磁盤寫滿了誰來清理?定時任務怎麼搞?產品突然火爆了,流量一夜間突然擴大了十幾倍的時候(產品經理狂喜中),誰負責擴容?這些問題雖然不是核心業務需求,卻是每一個線上產品都必須考慮的東西,否則只能稱為功能集合,不能稱之為產品。

深入淺出Serverless:優勢、意義與應用 | GMTC 7

從需求到產品,從 0 到 1 的技術全棧

Serverless 架構的出現,將剛才說到的一些非核心業務邏輯,以及運維相關的事情給“屏蔽”了。前端工程師張全佔只需關注前台功能、後台功能和數據這些核心的業務邏輯,就可以獨立做出產品。例如目前的微信小程序云開發就是 Serverless 式的,開發者完全不用關注底層架構。

Serverless 對前端工程師群體來說是一個機會。讓一個前端工程師能夠得到獨立負責某些產品研發的機會,完成某些產品從需求到上線的從 0 到 1 的機會,一個回歸到互聯網研發工程師角色的機會。我希望所有的前端工程師都有機會成為 Serverless 工程師,有機會獨立負責研發整個產品。

採用 Serverless 的準備總體上來說,採用 Serverless 不需要工程師大量的學習和準備過程。

Serverless 本身就是在現有的架構中做減法,減去那些服務器的管理和配置工作。當然在具體落地的時候,還是有一些準備工作要做:

首先是明確目標,開發者在了解 Serverless 之後,應該去思考對於自身業務和開發架構,採用 Serverless 是為了解決什麼問題?想取得哪方面的提升?沒有一種技術是為了用而用,都是針對具體場景解決具體問題。這是第一個需要搞明白的。

明確了目標之後,接著是 Serverless 模式下架構的一些設計工作。與傳統的開發模式一樣,系統設計的工作量是根據業務的複雜程度決定的。對於復雜業務邏輯來說,在開發之前需要明確有多少個雲函數,每個雲函數的輸入輸出定義、採用哪些 BaaS 後端服務,都需要提前設計規劃好。

特別要說明的是,這些設計和非 Serverless 並沒有什麼本質上的不同,Serverless 雲函數也不是神秘莫測的。簡單理解,它所提供的就是一個語言的 Runtime。在非 Serverless 架構下如何執行的代碼,Serverless 架構下還是那樣執行。如果業務是基於 Express 或者 koa 這類應用框架,那麼 Serverless 雲函數下,還是直接使用這些框架即可。

深入淺出Serverless:優勢、意義與應用 | GMTC 8

騰訊雲函數已支持一鍵部署 Express.js 應用

最後是一些實施上的準備,以騰訊雲函數為例,只要是寫過代碼的,花小半天時間閱讀一些基礎文檔、教程,或者是跟著Demo 走一遍,就可以立刻開始寫代碼,幾乎沒有什麼門檻和不同。要敲黑板強調的是,別忘記了工程化和 CI/CD 方面的考慮,尤其是和現有研發流程的結合。這塊有一些小小的工作量,畢竟是開發模式的升級,但基於雲函數提供的 CLI 和 SDK 都很容易實現。

Serverless 和雲函數的關係Serverless 架構由兩部分構成,分別是 FaaS(Functions as a Service)和 BasS(Backend as a Sevice)。其中 FaaS 就是指雲函數,它是一種新的算力組織和提供方式,它讓用戶不再需要關心服務器的管理和配置,只用專注於核心業務邏輯業務代碼的編寫。 BaaS 指的是一些服務化的後端功能,包括數據庫/ 對象存儲、賬戶權鑑、消息隊列、社交媒體整合和AI 能力等,這些服務和接口在FaaS 層使用相應的SDK 或API 來連接和調用。

深入淺出Serverless:優勢、意義與應用 | GMTC 9

FaaS+BaaS 的組合,構成了 Serverless 無服務器架構,免除了所有運維性操作,讓企業和開發者可以更加專注於核心業務的開發,實現快速上線和迭代,把握業務發展的節奏。

由此可見,雲函數是 Severless 架構中的算力部分,是實現 Severless 架構的基礎計算資源。在 Severless 架構下的業務系統中,因業務功能、需求場景不同,所需的 BaaS 後端服務也可能各不相同,但業務邏輯都需要通過雲函數來實現。

具體案例剛才也提到 Serverless 本身有很多很多的應用場景,這個問題在不同的 Serverless 的場景下,答案也是不同的。

如果業務需求是基於類似於 Express、koa 的應用框架來實現的,那麼在設計上,基本沒有任何區別。 Serverless 雲函數可以很好地支持這些應用框架,只是部署方式不同而已。

如果需求場景不需要任何應用框架,直接使用原生代碼,在 Serverless 架構下進行設計時,需要以函數為粒度來考慮,將函數作為業務中的最小功能單元。

還有一個場景使用 Serverless 和不使用就有很大的不同——企業上雲。

現在很多企業應用都做應用上雲,上云其實是一件非常有技術門檻的事情。可能需要上雲的代碼只有幾百行,但傳統上雲絕不是上傳部署幾百行代碼那麼簡單(估計很多工程師看到 Kubernetes 那幾本厚書的時候就已經快瘋了)。這個過程需要專業的、有經驗的工程師,花費大量的工作,才能把業務系統遷移到雲上。

深入淺出Serverless:優勢、意義與應用 | GMTC 10

傳統的應用上雲:大量的技術門檻和環境配置

Serverless 下的體驗就非常不同,因為無服務器架構,所以不需要關注虛機或者容器配置和治理工作,基本上只用上傳代碼就完成了上雲。

Serverless 的未來演化從以往的歷史來看,技術的演化還是存在一些一般規律的。

首先我預測 Serverless 生態一定會趨於繁榮。一個技術很有優勢,相關的社區貢獻,以及周邊的支持就越強大,用的人就越多;用的人越多,這個技術就越火,類似於經濟學裡的有效市場理論。最近 Serverless 的發展很快,可能大家看到這篇內容的時候,我們的 Serverless DB 產品已經發布了,就是開發者連數據庫的存在都不需要關注了。 Serverless 的使用者會越來越多,同時生態裡的貢獻者也會更多,整個生態也會更加繁榮。

第二個方向是 Serverless 的標準化。當生態繁榮之後,對於標準化的需求就變得非常強烈了。國內外各家云都有了自己的 Serverless 解決方案,對開發者隱藏了底層基礎設置。但是各家的接口、實現還是不一樣。試想一下,開發者在國內云上用 Serverless 實現的代碼,在做國際化的時候,要遷移到另一個雲廠商,卻發現完全無法平滑遷移是什麼感受?公司內兩個技術團隊如何在 Serverless 的架構下復用功能和代碼?如何能夠用統一的標准或者框架來構建應用? Serverless 開發需要一些標準,或是某一種框架來適配各個雲廠商之間的不同實現和接口,很可能是 Serverless 接下來的發展方向。

作者介紹 王俊傑,騰訊 Serverless 技術專家。負責騰訊雲函數與大前端研發結合方案設計,負責 SCF 雲函數編排、Serverless 日誌、監控、排障等相關 Topic。同時擔任騰訊雲 Serverless 技術佈道師,推動 Serverless 技術在行業大前端研發架構中的落地和實踐。曾擔任百度搜索 Web 前端技術經理,負責百度搜索產品前端研發技術管理工作。

活動推薦 想進一步了解 Serverless?想知道如何將 Serverless 融入到現有開發模式和工具中?想通過案例理解如何將 Serverless 和當前的業務結合落地?

在GMTC 深圳2019 ,我們不僅有Serverless 專場帶你了解阿里、騰訊兩大巨頭的的工程實踐之路,更有阿里巴巴經濟體前端Serverless 研發升級項目負責人風馳,從大局上帶你了解阿里在Serverless 上的佈局和架構。你要是覺得意猶未盡,別慌,我們在會後還設置了 Serverless 深度技術培訓,讓你離熟練掌握更進一步。目前大會開幕倒計時最後一周! !各位感興趣的小伙伴歡迎聯繫票務小姐姐:13269078023(同微信)。

深入淺出Serverless:優勢、意義與應用 | GMTC 11