騰訊雲Serverless2.0架構精解

 點擊觀看大咖分享

無服務器化後臺服務已成爲後臺服務轉型一個煊赫一時的方向，相對於傳統後臺架構有下降運維、資源成本等諸多優勢，雲函數就是目前應用較爲成熟的無服務器架構方案。那麼雲函數自身後臺架構是如何實現的呢？

騰訊雲雲函數（Serverless Cloud Function， SCF）是騰訊雲爲企業和廣大開發者們提供的無服務器執行環境，您無需購買和管理服務器，而只需使用平臺支持的語言編寫核心代碼並設置代碼運行的條件，代碼便可在騰訊雲基礎設施上彈性、安全地運行。

本次騰訊雲大學大咖分享《騰訊雲Serverless2.0架構精解》邀請了騰訊雲高級工程師龐博，以騰訊雲雲函數SCF爲例，講解雲函數架構的實現。

本課程目錄：

一、騰訊雲雲函數功能簡介

二、騰訊雲雲函數架構設計概覽

三、騰訊雲雲函數控制流架構原理詳解

四、騰訊雲雲函數數據流架構原理詳解

騰訊雲雲函數功能簡介

騰訊雲雲函數是騰訊雲提供給客戶的FAAS（Function As A Service）服務，所提供的是比微服務更加服務碎片化的軟件架構範式，可讓研發只須要關心業務代碼邏輯的編寫，再也不須要關注後臺的架構和運維，能夠將更多時間投入到業務上。

不只提供了代碼的編寫，還提供了函數代碼版本的管理能力。發佈後生成的版本是較爲穩定的版本，不可修改，能夠在安全的生產環境中使用

爲了客戶方便使用本身編寫的業務邏輯，提供了多種觸發方式：API網關、定時觸發器、COS、CMQ、CKafka、雲函數API。

騰訊雲雲函數架構設計概覽

如何實現一個雲函數服務。在前面的演示中，能夠看到主要操做有兩類：控制流和數據流。

控制流須要調度計算網絡存儲資源爲客戶提供服務，數據流是爲客戶的客戶提供觸發業務函數的途徑。

騰訊雲雲函數控制流架構原理詳解

以建立函數操做爲例，建立函數是提供給客戶的API接口，若是是同步的，後臺須要在同步的接口裏對代碼進行檢查並格式化，存儲在相應的位置，還需爲客戶準備相應的網絡資源和計算資源，啓動環境，準備接受相應的請求，最後還需在調用的總入口爲客戶增長數據通用，這樣的流程下來，客戶在調用的總入口需等待的時間較長，體驗差。所以騰訊雲雲函數控制流是進行異步化操做，當接受到請求時確認任務交付，返回成功，API將任務給到工做流模塊，工做流模塊會根據請求的數據組裝成一個消息，將消息異步投給須要作任務的子資源模塊，每一個子資源模塊在完成了本身的操做後會把任務執行是否成功的結果，以及相應的數據結果交給工做流模塊。工做流模塊根據回調的結果決定是否進行下一步操做，或是終止該流程。就這樣周而復始的工做，完成用戶提交的任務。另外，這裏多個業務模塊進行消息通信是基於mq消息，而且咱們每個子業務模塊的操做都是儘可能的原子化。

這樣的架構就帶來了不少的好處。

• 在事件驅動方面，模塊間的調用使用了消息隊列，實現了事件驅動的方式。例如鏈接維持等這種系統開銷就會降到比較低。對比一個同步的api，它裏面要作不少子業務模塊調度。同步的api，他在等子任務模塊執行完的時候，其自身也須要維護本身系統的開銷，包括內存、連接，而咱們消息事件驅動的方式就不是這樣。在工做流模塊處理完這個消息以後把消息投遞給下一模塊，就再也不維護相應的系統資源，因此就作到了一個系統資源的節省。
• 在可用性方面，多個模塊之間作到了完美的解耦，那麼單個模塊的故障就不會擴散。單個子模塊的操做盡可能的原子化、冪等化，方便咱們去追溯與回放。 在研發效率方面，模塊操做原子化，還有一些其餘的好處，例如後續開發新的業務能力，就再也不須要開發業務子模塊，只須要在工做流模塊去拼接以前原有的原子操做就能夠完成新的開發。
• 在用戶體驗方面，函數快速交付，服務穩定可靠。

騰訊雲雲函數數據流架構原理詳解

對於數據流最多的訴求就是觸發的調用鏈路延遲要儘可能的低。

那麼影響調用鏈路延遲有哪些因素呢

• 鏈路延遲。
• 冷啓動時間。
• 冷啓動率。

爲了下降掉延遲調用鏈路應該是越短越好，中間的操做越簡單越好。

但因爲騰訊雲後臺架構的複雜性和爲了保證客戶業務穩定和安全的可靠性，在該基礎上咱們的後臺調用鏈路仍是稍微有點長的。這樣才能保證客戶業務的安全和穩定，有不少必要的東西。api觸發的一個例子，它是最長的一條調用鏈路。首先請求進來以後，會到達雲api層而後請求作一個健全的操做。當健全操做經過以後，會將這一個請求分發給雲函數的後臺模塊。雲函數的後臺模塊會根據入參去檢驗該函數是否存在以及一些入參是否合法。在這以後，會再作一個技術服務，是爲用戶設置一個併發限制的能力。以後，會將這個請求分發給集羣的鏈路入口。集羣的鏈路入口選擇一個計算資源來執行這個實際的計算操做。整個鏈路調用就增長了不少的耗時，但用戶實際跑的業務函數可能耗時很是低。若是在鏈路上消耗了不少無謂的耗時。用戶體驗是十分很差的。

因此爲了解決這個問題，咱們在整個調用鏈路上，選擇性地增長了業務數據的cache以及連接的飽和能力。在不斷的優化後，咱們最後可以作到最長吊鏈路的延遲在12到20毫秒之間，基本能夠知足絕大部分的業務場景。另外，還有更多像例如api網關，這種鏈路較短的觸發延遲，其延遲是更低的。

如何解決冷啓動時間再調鏈路中的問題和影響。

首先咱們看一下冷啓動時間主要關心哪幾個核心的問題。

• 計算資源的準備。就是相似於虛擬機的建立、容器的建立。
• 下載代碼的時間。當有了一個計算資源後咱們仍是須要把代碼裝載進計算資源纔可以執行相應的業務邏輯。下載代碼的耗時，在較爲敏感的場景下也是不能夠接受的。
• 部署vpc網絡。主要是部署彈性網卡的耗時。

關於如何解決這幾個問題。冷啓動時間解決方案是輕量級虛擬機、代碼緩存、vpc網絡的代理。

一、輕量級虛擬機。

輕量級虛擬機實際上是咱們跑雲函數的一個計算資源。計算資源的選擇有不少種，好比咱們能夠選擇雲主機生產出來的虛擬機，還能夠選擇容器。可是在資源的選擇上，都有一個較大的缺點就是它們的生產時間較長，這就必然帶來一個冷啓動時間較長的問題，能夠高達數秒。在某些產品下，用戶是不能夠接受的。因而，咱們和雲主機團隊就一塊兒合做研發了輕量級虛擬化的這種計算資源。在這種計算資源的生產過程當中，只須要100毫秒或100毫秒之內，就能夠生產出來一個計算資源，這樣就極大下降了在計算資源生產上對冷啓動帶來的影響。

二、代碼下載時間的優化。

據統計，98%以上的用戶代碼都是小於100kb。在咱們的架構中，一個計算資源的節點是屬於同一個用戶的，該節點上能夠跑用戶的多個函數。基於這種場景，咱們設計了將用戶全部較小的100kb函數，全都緩存來這個單個計算節點上，這樣絕大部分的擴容請求不會觸發一個代碼的下載邏輯，有效下降了代碼下載的延遲。

另外，對於後臺架構的部署，是以單個地域爲單位的，地域的概念就好比說像廣州，北京和上海，單個地域下面有多個可用區就好比說廣州一廣州二廣州三。實際單個的計算節點的運行還須要在一個肯定的物理位置， 對於新建立的容器，它是沒有代碼緩存的。這種狀況下，就須要遠端下載用戶的代碼。可是，單個地域下咱們中心的代碼存儲又只有一份。這就可能致使跨可用區域的下載延遲較高，因此咱們在單個可用區下爲該可用區單獨設計了一份函數的緩存，進一步下降了跨可用區的延遲。由以前的一到兩毫秒優化到了一毫秒以內。

三、vpc網絡資源建立的問題。

時間的消耗主要是在用戶使用本身的vpc網絡來跑他本身的函數這個場景。在較早的時候，咱們調研了業界,基本也都是使用了該方式，就是將用戶vpc下的彈性網卡插在每個跑函數的節點上，這種架構的就有一個缺點就是每當有一個用戶計算資源節點擴容的時候，都會觸發一個彈性網卡的插拔操做。這個操做是十分耗時的，能夠耗時超過十秒以上，這個影響對冷啓動的時間是很是大的，用戶基本是不可接受的。

針對這個問題，咱們設計了一套新的方案，在跑雲函數的網站下，爲用戶建立一個網絡流量轉發的代理。而後用戶全部跑函數的資源節點的網絡流量都要經過這個代理的轉發，咱們只須要將這個代理節點插上用戶vpc資源的彈性網卡，就能夠有效節省在後續擴容計算節點中產生的插拔彈性網卡的時間，並且代理的建立能夠爲用戶預建立，用戶基本再也感覺不到建立vpc資源給用戶帶來的冷啓動時間。

綜合續解決了上面三個問題，咱們用戶的冷啓動時間已經優化了幾百毫秒左右。

雖然咱們前面說用戶冷啓動的時間在幾百毫秒，可是在某些延遲敏感的業務下，可能幾百毫秒仍是須要進一步優化的。咱們就此設計了一個自動擴縮模塊，它會爲用戶的每個函數去作一個過去調用趨勢的一個分析，作一個實時計算，來預測將來一段時間內，用戶可能調用資源使用的走勢，經過這種預測咱們就會爲用戶提早擴容好計算的資源，來防止一個冷啓動的發生。在這種狀況下，據統計，冷啓動率能夠控制在千分之一左右。

那麼今天的講解就到這裏，騰訊雲函數的架構優化和演技仍是在不斷的進行當中的，也歡迎你們和咱們進行更多的交流和探討。

---

問卷

爲了給廣大開發者提供最實用、最熱門前沿、最乾貨的視頻教程，請讓咱們聽到你的須要，感謝您的時間！點擊填寫 _問卷_

騰訊雲大學是騰訊雲旗下面向雲生態用戶的一站式學習成長平臺。騰訊雲大學大咖分享每週邀請內部技術大咖，爲你提供免費、專業、行業最新技術動態分享。