目錄
Serverless 是一項新技術，可能有朋友不是很熟悉。所以我們先介紹下 Serverless 的概念和發展歷史，接着介紹騰訊雲 Serverless 從 1.0 到 2.0 的技術演進，以及我們如何支持 Serverless 這種技術的，也就是技術生態。最後再介紹下 Serverless 的應用場景和具體的應用案例。
Serverless：雲計算新趨勢
這是 Serverless 目前的發展情況。
最近幾年，微服務和 k8s 很火。上圖可以看到 Serverless 跟他們的熱度對比，其中藍色曲線是 Serverless 的熱度曲線圖。從 2016 年開始，Serverless 的熱度是要大於微服務和 k8s 的。
Serverless 最初在 2010 年被提出，2014 年 AWS 推出了 lambda 服務，把 Serverless 產品化，並收到了很好的效果，微軟、Google 和 IBM 看到後，也分別在 2016 年推出了自己的 Serverless 產品：Azure function、GCP 和 OpenWisk。阿里雲和騰訊雲也分別在 2017 年推出了自己的 Serverless 產品，騰訊雲要早阿里雲一天推出。
在 2018 年，我們聯合微信，推出了基於 Serverless 的產品小程序雲開發，用來協助用戶快速的開發小程序。在 2019 年，我們推出了 Serverless 2.0 產品，後面會介紹 Serverless 2.0 和 Serverless1.0 在技術形態及計算資源上的區別。
什麼是 Serverless
Serverless 直譯過來就是無服務器，無服務器並不代表 Serverless 真的不需要服務器，只不過服務器的管理以及資源分配部分對用戶不可見，由平臺開發商維護，用戶只需要關注業務邏輯的開發即可。Serverless 不是具體的一個編程框架、類庫或者工具，它是一種軟件系統架構思想和方法。它的核心思想是用戶無須關注支撐應用服務運行的底層資源，比如：CPU、內存和數據庫等，只需要關注自己的業務開發即可。
那麼 Serverless 爲什麼這麼火？
從雲計算的發展階段說起，一開始是 On-Premise 層，接着是 IaaS 層，之後再到 PaaS 層。最後是 FaaS 層，Serverless 就是在這一層。
在軟件研發領域，繞不開的 2 個環節是軟件的部署和運維。如果我們要上線一個業務，在 On-Premise 階段，需要購買物理服務器，可能還需要自建機房、安裝製冷設備、招聘運維人員，然後再在上面搭建一系列的基礎設施，比如：虛擬化、操作系統、容器、Runtime，Runtime 可以理解爲像 Python、golang、Node.js 這類軟件。接下來我們要去安裝軟件類的開發框架。最後，我們纔會去編寫我們真正需要的業務函數。
到了 IaaS 層這一階段，雲廠商維護了硬件和虛擬化這 2 個基礎設施，到了 PaaS 層雲廠商又維護了 OS、容器和 Runtime，然後到了 FaaS 這個階段，用戶只需要關注 Function，也就是只需要關注自己的業務邏輯。可以看到隨着階段的演進用戶需要關注的點越來越少，越來越聚焦於自己的業務邏輯。所以在 On-Premise 階段我們開發一個業務可能需要 8 個人，在 FaaS 階段，我們只需要 2 個業務，節省的人力可以投入到業務研發這塊兒，提高產品的迭代速度，進而提高產品競爭力。
過去十多年，雲計算其實是一個「去基礎架構」的過程。這個過程可以讓用戶聚焦於自己真正需要的業務開發上，而不是底層的計算資源上。Serverless 符合雲計算髮展的方向，是雲的終極形態，這種特有的模式使 Serverless 存在潛在的巨大價值。
Serverless 2.0 組件架構
這張圖描述了 Serverless 的組件架構。最底層是基礎設施層，底層計算資源我們用到了 docker 和輕量化虛擬機技術，其中 docker 是 Serverless 1.0 的計算資源展現形態，輕量化虛擬機是 Serverless 2.0 的計算資源展現形式，相比於 docker，輕量化虛擬機性能得到了非常顯著的提升，可以在幾毫秒就可以啓動一個業務進程。在最底層我們也做了雙活，並且對底層資源做了嚴格的安全保護。
再上一層就是資源管理層，比如說我們有集羣監控，監控我們的集羣監控狀況，如果有集羣不可用，會立馬安排運維人員去排障。當然了，我們底層是有雙活的，當一個集羣出故障的時候，我們可以把流量切換到另一個集羣，用戶是無感知的，也不會影響用戶的請求。這一層我們有專門的自動擴縮容算法，來應對用戶的請求變化。
再往上，我們有認證和授權系統，通過認證和授權來保證函數的安全。最上面就是接入層，接入層主要用來觸發 Function 的調度和分配。接着往上是架構層，主要用來做一些流程上的調度。最上面這 2 層是用戶需要關心的，用戶主需要關注自己的業務代碼，以及跟數據庫，存儲等的調用，還有自己使用的一些框架，其它底層的設施用戶完全不用關心，全是由雲廠商來提供專業的保障和維護。
我們還提供了很多外圍的工具系統，來支持用戶的研發、部署和排障。比如：DevOps 支持，日誌、監控、告警支持。後面會有介紹。
Serverless 2.0 技術形態
如圖，左邊是 Serverless 1.0 的技術形態，右邊這部分是 Serverless 2.0 的技術形態。1.0 的時候，只有 event function，event function 是基於事件驅動型的，大概意思就是外界觸發一個事件給 Serverless 平臺，Serverless 平臺收到觸發事件後會調用函數並傳入觸發事件數據和參數信息，函數內部做業務邏輯處理之後返回給調用方。event function 可以對接多種雲上的產品，比如：api 網關、ckafka、cmq、cos 等。
event function 是一種開發模式，要求業務將業務邏輯拆分成 function 這種粒度，這種方式國外接受程度比較高，但是國內很多用戶都還停留在 HTTP 這個階段，爲了能夠方便現有的業務遷移到 Serverless 平臺，適配現有業務的調用方式以及擴展 serverless的使用場景，我們又開發了 2 個新的技術形態，http function 和 http service。
http function 這種形態可以理解爲通過 HTTP 請求來觸發函數的運行，通過 HTTP Request 傳遞參數，通過 HTTP Response 來返回參數。同時在創建 HTTP Function 的時候會自動生成外網域名，供用戶直接調用。
event function 和 HTTP Function 都是只有在請求的時候纔會調用，函數完成之後便不再運行，也就是不再佔用資源，換句話說不用再爲這些資源付費，後面會有一頁 PPT 介紹，serverless 是如何節省資源，以及跟 CVM 比 Serverless 這個技術的價格優勢在哪裏。
接着介紹一下 HTTP Service，Service 這種形態可以理解爲我們通常意義上的 HTTP 服務，簡單理解就是把 HTTP 服務的運行環境從物理機或者虛擬機或者容器換成 Serverless 計算資源。這種形態服務進程常駐，不限制運行時間，因爲服務進程常駐，所以它一直在監聽請求，所以請求延時更低。因爲 service 這種形態，跟我們現在的服務運行方式是一致的，所以業務可以無縫遷移到 Serverless 平臺上，不需要做過多的改造。同時在用戶創建 service 之後平臺會自動創建一個外網域名供調用。
3 種形態各有使用場景。比如：event function 適合基於事件觸發型的請求，比如：cos, ckafka, cmq， api 網關，也適合用完即走的請求。http function 適合期望函數以 http 請求的方式調用的場景，http service 適合期望服務以 HTTP 服務持久監聽請求的場景。
到 2.0 的時候我們跟友商已經形成了一個差異，像 AWS 和阿里的 FaaS 還停留在這個階段，這邊業界有個比較好的產品叫 Google Cloud Run。所以我們跟其他友商的優勢是他們是割裂開的 2 款產品，我們把他放到同一個入口了，更方便用戶去使用。
Serverless 2.0 運行過程
這兩種技術形態，又是如何支持用戶請求的呢？
如果一個用戶想用雲函數，首先要在本地做開業務開發，目前用的比較多的是 VS Code IDE，當研發把代碼和依賴編碼完成後通過我們提供的 VS Code 插件可以很方便的把代碼部署到我們的平臺上，或者通過我們提供的 SCF 命令行工具，也可以很方便的把代碼部署到雲端，也可以通過我們的控制檯進行代碼提交。這是我們的雲函數平臺，分爲 function 和 service 2 種形態。因爲他是一個完整的業務邏輯，勢必會用到像數據庫，對象存儲這些服務，雲函數已經把相關產品的 sdk 內置到我們的 runtime 中了，用戶在使用這些後端服務時，直接 import sdk，然後掉 SDK 相關接口即可，用起來會更方便一些。後端的這些服務在 Serverless 中統一稱爲 BaaS (Backend as a Service)。也就是把像數據庫，對象存儲等能力統一通過 API 的形式供用戶使用，至於這些組件的高可用，擴縮容也不需要用戶去關心，用戶只需要去使用即可。
用戶把業務邏輯部署完成之後，可以通過終端去發起請求，比如瀏覽器、安卓或者 IOS，Serverless 提供不同的觸發方式，比如 HTTP，也就是通過 HTTP 請求來直接觸發。通過 COS 觸發，舉個簡單的例子，用戶把一張圖片上傳到 COS 平臺，COS 平臺收到用戶上傳圖片的時間後，會去請求配置的雲函數，並且傳入事件的數據，和用戶自定義的數據，業務在雲函數中通過解析這些數據和參數完成業務邏輯。
當請求來的時候，我們平臺會根據請求量的大小，去自動或縮容。像 Function 這種，我們會瞬時拉取足夠的函數實例來滿足所有的請求，我們有一個調度層，會根據請求量的大小來判斷需要起多少個 function 實例，同時我們也有一套算法，根據用戶每天的請求情況，提前創建好一些資源，當用戶請求過來時，直接將請求切換到已經創建好的資源上，減少請求延時。像 Service 這種，我們也會根據請求流量動態的做水平擴容，業務無須感知。
Serverless 2.0 技術生態
Serverless 更多的是解決計算資源的按需分配，無須運維，但如果想真正在 Serverless 平臺上跑業務，還需要其它系統的支持，來滿足業務對開發、運維和排障的需求。我們從開發者工具，DevOps、監控運維 3 個方面，來介紹下我們是如何支持函數的研發、運維和排障的。
開發者工具
首先來介紹下開發工具，爲了支持開發者能夠方便高效的開發和部署雲函數，我們開發了一系列的工具，比如：我們提供 VS Code 插件，通過 VS Code 插件，開發者可以很方便的通過 IDE 直接部署、更新和調試雲函數。我們也提供了 Web IDE 來方便用戶直接在網頁開發代碼。此外我們還提供 CLI 工具，通過 CLI 用戶可以在終端很方便的通過命令調用完成諸如配置、部署、調試、調用等功能。最後我們還提供 API 接口來滿足用戶對自動化和定製化的需求。最後我們還提供 SDK 供用戶更方便的調用雲函數的接口。所以可以看到要將 serverless 產品化，還需要做很多其它工作來支撐 Serverless 這個技術，尤其是工具這塊兒。
DevOps 支持
除了開發者工具，我們也提供完善的 DevOps 支持，從最佳實戰，到工作流，到工具鏈，以及產品打通，我們都提供了很多方案和支持。
比如工作流這裏，我們支持編碼、構建、打包、部署、測試和發佈等一系列流程。在工具這裏，我們提供了：CLI、應用模型等。產品這裏，我們打通了很多產品供用戶很方便的跟這些產品進行交互，利用這些產品提供的能力，比如：Git 倉庫，API 網關，Serverless DB 等。這個是 DevOps 支持。
日誌
日誌這裏我們支持 2 種日誌查詢方式，方便用戶查看日誌。在 scf 控制檯上，能夠查看函數調用成功與否，各階段的調用時間，以及用戶打印在日誌或者標準輸出的日誌，支持用戶按 RequestId 去搜索日誌。另外我們還支持用戶將日誌輸出到騰訊雲日誌服務系統，將日誌持久化存儲，在日誌服務系統中，用戶可以根據正則表達式來搜索日誌，也可以自定義檢索規則，方便下次檢索。
監控
我們提供 3 個維度的監控。提供本月調用次數、本月資源量、本月出流量的監控。提供按地域劃分的調用次數、運行時間、錯誤次數、併發個數、受限次數監控，這些監控指標都是用戶很關心的指標。另外我們也提供函數級別的監控：：調用次數、資源超過限制次數、函數執行超時時間、內存超過限制次數等監控指標。所有這些監控指標都可以在騰訊雲監控系統上配置告警。
性能監控
我們還提供一些更高階的監控，現在在啓動開發，大概在 8 月底或者 9 月初的時候會發布。我們會提供函數與函數之間的調用鏈追蹤，展示每個調用節點函數的執行情況、函數執行的性能分析，以及支持對失敗函數進行流量重放。所謂的流量重放，就是說，我們會把調用失敗的函數放在 DLQ 隊列中，用戶可以很方便的從 DLQ 隊列中重試該失敗的函數，方便用戶 Debug。
計費模型
之前有提到過，我們會有一頁 PPT 來專門分析下 Serverless 下的計費模式和優勢。Serverless 平臺下的計費按如下 3 個維度進行計費：
- 資源使用費用：（資源使用量 - 免費資源額度） X 資源使用單價
- 調用次數：（函數調用量 - 免費調用額度） X 調用次數單價
- 外網流量費用：外網出流量 X 流量單價
但是這種比較難理解，所以我們一般會跟 CVM 進行對比：如果用戶部署業務，需要購買 CVM，可能需要 10 臺 CVM，那對計算資源的投入就是這條黃線，相當於計算資源一直在使用這些計算資源。對於雲函數來講，當沒有請求的時候是不佔用計算資源的，不會產生任何費用，只有請求的時候才佔用計算資源，白天會有個波峯，晚上會有個波谷，大部分業務都是這種模式，可以看到這些陰影面積就是雲函數的實際使用資源，我們只會對這些陰影面積進行收費。
這個是跟 CVM 的計費對比，當資源使用率小 60% 的時候 serverless 下的費用比 CVM 小很多，一般業務很難達到資源使用率 60%，能達到 30% 就已經很不錯了。
Serverless Event Function 應用場景
這裏介紹一下應用場景，先介紹下 event function 的應用場景，通過這張圖，我們可以看到，雲函數可以作爲瀏覽器、APP 和小程序的後端服務。通過我們提供的不同觸發器可以支持不同的場景，比如通過 API 網關觸發器，可以匹配 websockt 的應用場景，通過 cos/cmq/ckafka 觸發器可以支持像：消息處理、流失計算，事件通知這類的應用場景。
Serverless HTTP Service 應用場景：BFF
剛纔那個是比較簡單的一個 Demo，這個就是一個比較複雜的場景。假設我有一個 APP 應用跨多端的，比如 Android，iOS，Web。如果想寫後臺的話，我可能要寫多個接口，去適配不同的終端。這樣如果後端有變更，需要去更改 3 個終端的 API 接口，與此同時，當我們需要對一個字符串進行處理，如限定 140 個字符的時候，我們需要在每一個客戶端（Android，iOS，Web）分別實現一遍，這樣的代價顯然相當大。。現在有一個比較流行的解決方案就是在前後端加一個 BFF 層（Backend For Frontend）將前後端解耦，這裏是 BFF 層可以承載的能力比如：身份校驗，日誌記錄，數據組合等。BFF 一般由前端工程師去編寫，適配不同的後端當後端有變更的時候，只需要改 BFF 層就可以，不用去更改客戶端。BFF 層可以部署成 HTTP Service，也就是可以直接利用我們提供的 HTTP Service 技術形態來部署。通過 BFF，可以讓前端工程師變成全棧工程師，開發不用去關注底層的資源。
Serverless 助力微信小程序雲開發
這個是小程序雲開發了，是騰訊雲和微信合作的一個標杆場景。左邊是傳統模式，首先是小程序前端，後面對應一個後端，這個後端可能是一個 API 服務器，後端又對接了很多其它子系統比如：數據庫、存儲、負載均衡、網絡、容災等。需要考慮很多因素，但是用雲開發，就可以簡化成右邊這種架構，前端頁面，然後到微信後臺，微信後臺會走專線的形式，將用戶的請求轉到 Tencent Cloud Base 組件，簡稱 TCB，TCB 後邊掛接了數據庫、存儲、網絡、容災等系統，後端這些都不需要工程師去考慮，全都有 TCB 進行對接。TCB 相對純雲函數來講它屏蔽了更多的東西比如：雲函數、存儲和數據庫，做小程序開發會更簡單。
接下來我們看下 serverless 的具體落地情況。
Serverless 助力騰訊六大業務線
這裏先介紹下騰訊雲 serverless 產品在內部的使用情況。目前在騰訊內部已經有大量業務在用，比如微信小程序雲開發底層用的是 serverless 做計算資源，企業微信的機器人。QQ 小程序相冊，騰訊新聞底層也用到了 serverless 等。
客戶案例 - 騰訊地圖：100 億條消息/天
這個是騰訊地圖的客戶案例，走的是 event function 這種方式。場景是這樣的：用戶在訪問騰訊地圖時會產生一些數據庫，騰訊地圖會將這些數據進行整理並保存到 Hbase 和 ES 上，然後再配上一個 UI 用來查詢數據。當用戶產生一條數據時，會將這條數據放在 kafka 隊列中，kafka 觸發後端的雲函數，雲函數做數據處理之後又將數據放入 kafka 隊列中，由另外一個進程從 kafka 隊列中取走處理後的數據，放入 ES 和 Hbase 中。
客戶案例 - 企業輔導背單詞
企業輔導背單詞沒有用雲開發那一套去做這個小程序，是因爲他有多端，有 QQ 小程序，有微信小程序。這個是企業背單詞的邏輯架構，這邊是小程序的功能側，這邊是管理後臺，它所有跟後臺的交互都是用 API 網關去跟後端的 Function 交互，然後後端的 Function 去跟後端的 BaaS 交互。這個是背單詞的的技術架構，小程序端會實現聽、讀、學習等邏輯，小程序端調用後端的 Function 會去完成鑑權、語音合成、學習記錄存儲等工作。像語音合成是直接調用 Baa S層的 AI 接口，學習存儲是直接調用 BaaS 層的數據庫接口把單詞等信息存入數據庫的。
客戶案例 - 騰訊相冊小程序
這個是小程序的案例，去年發佈小程序雲開發的時候，這個是我們第一家用戶，也是調用量最大的，這個小程序是把騰訊相冊和 QQ 空間做了打通，在微信端用相冊小程序，就可以把原來放在空間的相冊、圖片下載出來，也可以在手機端去做一些圖片的上傳和分享等，相冊小程序用戶量是比較大的，目前的註冊用戶是 1 個億，月活 1200 萬，如果用傳統的形式去實現，他要搭業務集羣，域名備案，負載均衡，監控，包括日誌，會話管理還有數據庫，它全部都要自己搞一套，比較複雜。當時他們選雲開發時因爲他們人力不夠，包括測試、研發人力都不夠，就幾個前端工程師。用雲開發之後，架構就比較簡單了，微信端開發完之後，然後到業務集羣，業務集羣就相當於後端的雲函數，去寫業務邏輯，最後到數據庫，對象存儲。
這個小程序最初是一個前端工程師花了 2 周時間寫了一個 Beta 版本，基本上就把相冊的上傳下載分享等邏輯全部寫好。
Serverless 帶來的用戶價值
業務遷移到 serverless 平臺可以帶來如下價值：
- 用戶不需要去購買和維護計算資源，並且不需要關注高可用、負載均衡等問題，用戶只需要去編寫數據處理的業務代碼即可
- 我們天然的支持了基於ckafka的觸發器，用戶不需要再去實現這一套邏輯，節省了很多工作量
- 資源按需分配，只有用戶瀏覽地圖的時候纔會觸發底層資源的分配
- 藉助於雲的能力，我們提供了非常大的資源池，用戶不需要去擔心後臺計算資源的問題
作者介紹：
孔令飛，騰訊雲 Serverless 產品架構師。
本文轉載自公衆號ServerlessCloudNative（ID：ServerlessGo）。
原文鏈接：