Serverless架構詳解：開發者如何專一於業務代碼自己？

本文來自騰訊雲技術沙龍，本次沙龍主題爲Serverless架構開發與SCF部署實踐

演講嘉賓：黃文俊，曾負責企業級存儲、企業級容器平臺等產品的架構與開發，目前主要負責SCF騰訊無服務器雲函數產品相關。對容器平臺、微服務架構、無服務器架構以及DevOps等多種熱門技術領域均有涉獵。

你們好，自我介紹一下，目前我是騰訊雲無服務器雲函數產品負責人。我作了不少年後端開發。今天是從一個程序員角度講解一下咱們怎麼樣用Serverless架構。

我將本次講解分爲幾塊：第一，Serverless架構介紹；第二，對雲函數產品介紹；第三，Serverless使用場景。

講Serverless架構以前咱們能夠來看一下整個雲的發展過程，在沒有云以前你們可能都是用的物理服務器，早期時候你們都用的物理機託管方式，採購一些服務器在機房裏託管，這個時候你們前期要選擇物理機型號，要作好IDC網絡；若是出了問題還要請IDC人員幫你操做。這些設備的投入和運維成本仍是很高的。

雲時代到來以後，因爲虛擬化技術的運用，咱們用上了雲主機。雲主機是你們直接在雲上作虛擬機購買，開通就可使用。這時候咱們稱之爲IaaS(基礎設施即服務)，這種狀況下就無需物理機運營，直接放到雲平臺來作。而以後隨着容器技術的發展，咱們有了容器平臺，或者叫PaaS（平臺即服務）。在容器平臺到來以後實際上還存在一部分基礎設施運維問題，可是這時候基礎設施逐漸下沉到運維人員進行操做；而從應用開發者角度來看，他們已經不用再去關心虛擬機，或者操做系統。在這種狀況下，應用開發人員更多的去關注應用所須要的計算資源或者存儲資源的使用。繼續向前發展，咱們到了FaaS（函數即服務）。這時候運維人員不須要關注底層的運維，而是按需運行的能力。業務開發人員可以進一步作與業務相關的事情。

接下來咱們來看一下Serverless架構是什麼。Serverless從物理機或虛擬機的使用上進行了分離，更關注上層業務的運行狀況。Serverless架構包含兩塊：函數即服務和後端即服務。函數即服務提供的是計算能力。原有的計算能力，不管是容器也好，虛擬機也好都承載在必定的操做系統之上，函數即服務把計算能力進行了進一步抽象，咱們在後文再繼續進行展開。另外，Serverless還有後端即服務，好比對象存儲，數據庫應用，緩存服務，咱們也能夠稱之爲Serverless，由於這些服務也可以在雲上提供開通即服務，開通即便用的能力。在使用這些產品時一樣不須要關注它的服務器是什麼樣的，它的服務器部署在哪裏，而是服務開通就可使用了，後面的運維工做都交給了雲，因此不用感知它的最底層服務器，所以咱們也能夠把它稱之爲Serverless。這種服務就稱之爲Serverless後端即服務。這兩個合起來能夠稱爲Serverless架構。

函數即服務的工做原理是什麼樣的？在Serverless上是怎樣提供計算能力的？你們原來使用容器或者虛擬機的時候均可以知道，咱們把代碼上傳到容器或者上傳到虛擬機，而後啓動一個進程，代碼就能夠運行，它就能夠接受外部的請求，作一些實時的響應。Serverless和原有的容器或虛擬機不一樣，實現的是計算託管服務，Serverless用戶首先要作的，是把咱們稱爲雲函數的代碼，提交到平臺上進行代碼託管；而後要作的是配置觸發器。爲何須要配置觸發器？由於雲函數的運行方式是觸發式運行，有觸發的時候，代碼纔會真正運行起來。因此配置觸發器意味着咱們給它設置了一個觸發源，也就是定義了在什麼事件下代碼才真正運行起來。用戶代碼託管到平臺以後，事件沒有到來以前，它僅僅是代碼文件和配置存儲，代碼並無運行。什麼狀況下運行？是當事件觸發真正到來的時候，雲函數纔會真正啓動一個實例，這個實例就意味着一個計算單元。計算單元被拉起後，這個事件就被傳到這個計算單元中進行計算處理。若是這個觸發源的事件不少，併發很高的狀況下，平臺會根據事件的堆積狀況，或者事件到達的速度，自動把同一份代碼和配置拉起多個實例進行併發處理。所以能夠看到Serverless的運行是按需運行，意味着只有在事件到來的狀況下，代碼纔會被拉起，纔會運行起來。

自動併發，是指雲函數平臺會根據事件堆積狀況自動的進行併發，自動拉起多個實例進行處理。而原有的容器或者虛擬機若是要進行併發的話仍是要有必定的手工參與，好比啓動更多的容器，或者加入更多的虛擬機來承載高併發的請求。而函數即服務是徹底自動的運行。

按需運行帶來的另一個特色，是代碼在運行起來以後上纔會佔用計算資源。函數即服務的費用也是根據按需運行來的，也就是函數運行的時候才進行計費；而沒有使用的狀況下不會計費。實際上大多數互聯網業務只有白天的時候，甚至六點以後你們下班以後業務纔會迎來高峯，而到凌晨以後實際上沒有多少請求的，所以函數即服務可以很好的知足波峯波谷來削峯填谷的能力。

從上面的原理能夠看出函數即服務的一些特色，好比說代碼託管，雲函數平臺所提供的直接就是運行環境，也就是支持各類開發語言的環境；對於開發者或者函數服務使用者來講，並無感知到它下面的服務器在哪裏，而是由函數平臺完成了函數運行的調度。所以實際來說不須要運維，包括操做系統優化，服務器維護等等這些都是由平臺進行承載。

而秒級部署意味着函數在真正的被請求的時候才運行。而這個請求才運行表明着當請求到達平臺的時候函數纔會被實時拉起並運行。運行完成後若是沒有後續請求，實例也會退還。

因爲函數運行是事件觸發的，而事件其實包含不少種類，有各類觸發器均可以對接雲函數。有越多的觸發器對接，雲函數所能提供的場景也就越多。

對於開發者來講，使用雲函數的狀況下，他真正關注的是應該業務，是使用代碼去聚焦他的業務邏輯，例如是拿到這個事件後該進行什麼樣的邏輯操做，進行什麼樣的業務存儲，而不須要去關注怎麼使用業務代碼實現高併發，怎麼樣實現高請求的承載能力。所以這裏看到函數即服務可以爲應用開發者帶來一些便利，而自動併發自己也是函數即服務所具備的特色。

而對於騰訊雲無服務器雲函數，在最開始開發產品的時候，咱們目標也是同樣，就是把計算進行託管。在計算託管的狀況下，咱們使用計算就像咱們使用騰訊雲對象存儲同樣，在使用的時候不用關心最底層的運維，不用關心虛擬機或者物理機是否安全。和對象存儲進行對比也能看到，咱們計算也是按照實際使用狀況進行計費。固然如今雲函數還處於免費期，你們能夠隨時使用。

從使用方法來講，雲函數自己，或者說函數即服務這種產品自己的使用方法都是很簡單的。咱們在開發的時候更多的關注於核心代碼的編寫。核心代碼的意思實際上就是真正的業務邏輯。並且業務邏輯裏不須要考慮高併發，由於由剛纔給出來的函數即服務這種計算特色來看的話，在高併發請求的時候是經過多個實例處理進行，所以業務代碼在編寫的時候，就關注單個事件的處理就行。所以，第一步的核心的就是編寫核心業務代碼，就是用代碼要實現什麼樣的業務。後續就是配置觸發方式。配置觸發方式就是把函數代碼和觸發源對接起來。和雲平臺上其餘的產品進行對接，須要什麼樣的事件，處理什麼樣的事件，進行什麼樣的邏輯處理，作好這樣的觸發源對接後，函數就可以在事件產生的狀況下運行。

所以，從整個使用方法來看的話，你們真正要作的是兩步：第一，編寫代碼，第二，配置好觸發。而對於底層的基礎設施，環境配置這塊都不須要你們操心的。

目前，騰訊雲函數從運行環境來講目前已經支持了Python、Nodejs、PHP、Golang、Java等語言的開發運行環境。

接下來是觸發器，由於觸發器越多，雲函數所能去使用的場景其實也越多，咱們已經實現的觸發器有定時觸發器；騰訊雲對象存儲服務，包括文件的上傳、刪除等時間；CMQ 消息隊列服務；API 網關服務，這個是經過serverless 架構實現 API 服務的一款重要觸發器；另外，還有ckafka，這個是騰訊雲提供的kafka能力。目前kafka算是一個開源產品，咱們騰訊雲把它包裝後放到雲上來，也是兼容標準的kafka協議。所以在不少狀況下直接遷移到騰訊雲不須要任何修改。由於kafka自己做爲消息傳遞的載體，跟騰訊原有的消息隊列相似，由消息來執行雲函數。

下面介紹一下在什麼場景下Serverless能夠落地？第一，在Serverless場景中最經常使用到的就是API服務。你們知道實現一個API服務，不管是把API給到瀏覽器應用，仍是給到手機APP使用，仍是給到小程序應用，給到它們的時候是以API實現的。要實現這個要有WEB服務器接收鏈接，對接後端的業務代碼，若是你要再進行文件存儲，後端的結構化存儲，或者有一些緩存須要讀寫，你的應用服務器後面可能還要對接相應的文件存儲，結構化數據庫，後續若是想使用緩存，再對接到相應的服務器或相應產品。若是把現有的API服務向Serverless架構演進，那麼它將怎麼樣呈現呢？

在不改變 API 的狀況下，它的前端瀏覽器應用、APP、小程序，均可以無縫對接上來。而使用API網關來承接 API 請求，當這個請求來到API網關，由它轉發給雲函數，觸發雲函數執行。雲函數執行時運行業務邏輯。實際上雲函數運行時要求無狀態，所以這樣的狀態存儲也須要用到後面的一些存儲，不管作緩存也好仍是數據庫也好都要用上。所以，雲上提供的產品同樣能夠進行對接。像文件存儲的話能夠用對象存儲來進行。數據庫的話同樣的有相應的數據庫產品，結構化仍是非結構化數據庫都有相應的產品可使用。一樣的，緩存也有相應的產品作對接。雲函數經過代碼編寫，直接進行數據庫的讀寫，或者緩存的讀寫都是能夠的。

從整個服務架構來看的話，咱們使用最前面的API網關，提供是API能力，甚至進一步可以直提供有SDK服務，更加的方便開發。SDK提供了各類開發語言來直接進行API調用。雲函數在中間起到的是業務邏輯處理的做用，而狀態數據或者其餘業務數據的存儲是依賴於後面的文件存儲或者數據庫進行的。API服務也是Serverless最經常使用的一種落地形式。

這裏介紹的場景，都是咱們客戶在實際使用的場景。在 serverless落地場景中，對對象文件的處理也很常見。對象文件處理指的是對對象文件進行操做後的回調處理。回調一般是在對象文件建立或刪除操做後產生的事件。雲函數能夠在獲取到這個事件後進行後續的處理。這裏常見的處理邏輯是下面幾種，好比說圖片處理，針對圖片去生成各類尺寸的縮略圖或者進行裁剪，而後再次存儲到對象存儲數據中，以後能夠根據不一樣客戶端的請求展現不一樣大小的圖片到前端。

文件批量打包，用戶須要進行文件篩選和打包的時候能夠經過使用雲函數來處理。在上傳文件後，若是須要選擇哪些文件來打包，把文件生成壓縮包以供下載，這均可以由事件處理來進行。

日誌歸檔分析，以及業務系統回調，也是雲函數所承載的業務邏輯。好比說日誌歸檔分析這種用法，用戶會把天天的前端應用服務器的日誌上傳到對象存儲中歸檔，歸檔後會觸發雲函數執行，雲函數會拉下這些日誌文件進行實時分析，它會抽取這些日誌中的錯誤數，或者是其餘業務相關或者用戶關注的內容，而後再把它抽取到的信息或者統計到的信息寫回數據庫，供用戶後續進行排查、使用。用戶自身API調用也是，例如用戶生成的一些視頻文件上傳到對象存儲，會觸發雲函數，將上傳文件的信息通知到用戶的轉碼系統，經過視頻轉碼轉成不一樣分辨率而後再進行存儲。固然轉碼是用戶自身實現的業務系統，這塊經過回調通知，通知它自身的業務系統。這些就是雲函數在Serverless架構和對象存儲連用的落地場景。

再就是CKafka消息處理。CKafka目前比較多的應用場景是作日誌存儲和日誌蒐集，例若有多臺應用服務器在不斷產生日誌的狀況下，能夠把日誌寫到CKafka，而後CKafka再進行歸檔和後續分析。而 CKafka和雲函數對接是由CKafka收到的信息來進行觸發的。日誌蒐集後，要歸檔的日誌，通常存儲到對象存儲當中。這種狀況CKafka消息，會被推送給雲函數，雲函數再再把這些消息寫到對象存儲中去。有些用戶不是寫對象存儲，而是寫數據庫，以數據庫形式歸檔，其實也是同樣的。有的使用場景，須要進行消息分析，會實時拿到消息後馬上分析裏面的關鍵字，若是捕捉到了關鍵字，會馬上把這些消息推送到ckafka 的另外一個topic 中，去及時的發出告警給到業務和運維人員。這也是 serverless 的一種用法，就是對消息的分析和轉發。

消息隊列和CKafka相似，可是消息隊列通常不是進行日誌的蒐集，而是進行業務解耦。消息隊列 CMQ 是騰訊雲提供的一個高可靠金融級消息隊列，一般進行一些業務級消息轉發和處理。使用這個產品，實際上作的是業務解耦。雲函數在這裏承載着消息的邏輯處理過程，它可以在接收到消息後對消息馬上進行業務處理。這個業務處理就是實際的業務邏輯，好比我要根據裏面某個消息進行判斷，判斷它是否合適，要不要進行後續的轉發，或者轉發到另外的業務系統中去？這就是業務之間執行的邏輯。

同時，咱們也可使用雲函數，再次進行消息的分派，作狀態轉移。這個狀態轉移和後面消息轉發都是同樣的，它會識別消息裏的內容，根據消息裏的內容進行轉發。這種狀況下相似於咱們使用雲函數進行邏輯處理，把它轉移到合適的消息隊列，而後再進行處理。這也是咱們所見過直接用雲函數進行消息派發的使用方式。

最後一種形式如今也很多，就是利用定時器觸發。本來你們更可能是在運維場景下使用定時任務，在原有使用 crontab 腳本的狀況下，你們一般還要關心腳本運行是否成功，這臺虛擬機是否還在工做。雲函數拋棄了你們使用傳統的虛擬機或者物理機來去寫crontab腳本還要確保可靠性的問題。而在實際使用定時器觸發的場景下，這裏也有幾種用法：一種是業務撥測。這個是週期性的去撥測業務是否還在工做，若是出現異常的狀況下可以及時的發出告警，發出郵件或者短信告訴到運維或開發人員。

另外一個是定時備份，這個是在所須要的週期內，好比天天，或者每兩天對數據庫進行備份，針對數據庫須要作數據導出，導出後再將導出內容以文件的形式存儲到合適的地方，例如對象存儲中，作好定時備份。

還有一個是定時數據計算。由於有些計算是根據一段時間內的統計以後，進行計算並展現。在實際場景中，咱們騰訊雲內部有業務就是在進行定時數據計算，每兩小時作一次統計，而後再把統計數據寫到數據庫作後續業務的展現以及業務分析。

總結：Serverless架構自己給用戶帶來什麼？它實際上就是容許咱們更關注業務代碼，所以能夠更快速的構建業務而後上線。如今互聯網開發速度愈來愈快，所以你們指望的是進一步加快開發和業務真正上線的速度，提升迭代的能力。所以，使用Serverless的話能夠更快速讓業務上線，讓咱們更快實現咱們的想法。而按需使用是咱們這個業務在上線以後，在真正產生請求後，業務纔會被調動觸發，纔會有計算。而若是你的業務產生了爆發式增加，其實也不須要擔憂平臺承載能力或者業務擴展是否跟得上，由於平臺提供自動擴展能力，下降了你們對運維的訴求，你們不用關心很底層的東西，而運維人員也能夠更偏重流程化和業務相關的運維。這就是Serverless架構給你們帶來的一些好處。而做爲Serverless裏的核心，函數即服務這種產品，是Serverless中所呈現出來的計算型的組件，你們也能夠看到它和觸發源和後端的各類產品或服務有緊密關聯，它能夠更多的被看作是雲時代的腳本，相似於黏合劑，把前面的觸發源和後端的各類存儲，數據，服務進行了黏合，真正實現架構落地，纔是真正實現業務邏輯落地的能力。

Q&A

Q：雲函數有無限擴展能力，可是整個系統也有多是有限制的，好比它的背後的數據庫和存儲，我能不能設這樣的一個擴展上限？

A：這能夠設置上限的。目前能夠經過提交工單的方式來設置指望的合適上限。擴展能夠在後臺設置一個合適值，併發實例擴展到這個就不會再擴展了，避免大量實例鏈接形成後端的數據庫或存儲超過鏈接數限制。

Q：實現 API 服務有哪些開發方式？

A：雲函數實現 API 服務的開發方式有好幾種，一個是所有在一個函數裏完成，路徑和方法解析都在函數裏進行。這也是偏傳統的開發方式。另一種是進行拆解，每一個函數處理一個 API 路徑和方法的請求，這種是微服務的開發方式。

而函數和函數之間調用也是能夠實現。一種是直接使用雲API，一種是使用 API網關包裝後的 API。雲函數被觸發調用的話，除了介紹的不少觸發器，在不使用這些觸發器的狀況下，經過代碼或者腳本也能夠經過騰訊雲的雲API調用。

Q：在事件觸發的時候，就是CMQ事件觸發的時候，是否能夠保證函數被執行呢？由於不像API網關，調用一下函數能夠啓動，前端能夠感知到。可是CMQ，就是扔到消息隊列可否保證這個函數被執行呢？

A：由於不像API網關是同步調用。同步調用就是這個調用在運行過程當中若是出了問題，不管是平臺，好比說資源不足，併發不夠，或者好比使用的超時了，這個時候能夠馬上感知到。 而像CMQ或者CKafka都是異步的，這樣意味着調用後你感知不到，這個消息何時執行，執行結果都無法感知。這種解決方法有兩種：一種是函數運行後的結果輸出，把消息處理後的輸出結果再放到另外一個消息隊列中去，讓你外部的業務系統可以感知到。固然這種對外通知也是異步通知。同步通知是另一種，就是函數裏能夠對自身業務進行回調API，能夠經過代碼知道如今的數據處理是什麼樣的結果，處理完後能夠馬上回調到API讓業務系統接收處處理結果。

Q：像COS觸發，拿視頻轉碼來講，這個有可能在300秒內處理不完。如今函數設置時間只能最高300秒，這個有什麼解決方案嗎？

A：爲何各家的雲平臺，都把這個時間大體定在這個範圍內，就是不但願在雲函數中進行過重的計算。視頻轉碼就屬於過重的計算，而云函數提供的包括CPU能力，內存大小都有限，實際上都不太適合在雲函數內進行轉碼。實際上能夠用一些視頻服務來實現轉碼，使用雲函數來作這二者之間的橋樑，例如對象存儲的事件觸發後，雲函數拿到這個事件經過調用視頻轉碼服務來轉碼，而不是在雲函數轉碼。目前騰訊雲有這個服務，你能夠試試看。

獲取更多詳細資料，請戳如下連接：

Serverless 架構.pdf

問答
serverless：如何刪除一個函數？
相關閱讀
讓業務感知不到服務器的存在——基於彈性計算的無服務器化實踐
使用 SCF 無服務器雲函數定時備份數據庫 
雲學院 · 課程推薦 | 騰訊專項技術測試組長，結合8年經驗爲你細說冷熱分離法則

此文已由做者受權騰訊雲+社區發佈，原文請點擊

搜索關注公衆號「雲加社區」，第一時間獲取技術乾貨，關注後回覆1024 送你一份技術課程大禮包！

海量技術實踐經驗，盡在雲加社區！