一講了解Serverless，以騰訊地圖、微信小程序爲例

Serverless從去年開始尤爲是最近特別火，由於確實可以解決咱們的一些業務問題。我會藉助騰訊雲Serverless產品，來介紹下騰訊雲是如何落地Serverless技術，以及Serverless技術所適用的場景，最後會介紹一些客戶案例。

Serverless 簡介

在左邊這張圖上，藍色的是Serverless，在2016年它的熱度已經超過微服務和Kubernetes。右邊展現的是Serverless產品化的狀況。好比，2014年的時候，AWS首先推出了Lambda，2016年微軟、Google、IBM都分別出了本身的產品。國內來講，17年國內廠商騰訊雲推出了Tencent Cloud SCF，阿里雲也推出了本身的Serverless產品。18年騰訊雲聯合微信，推出了微信小程序雲開發的產品TCB，19年，騰訊雲推出了Serverless 2.0產品TSF Serverless，支持新的應用場景。

什麼是 Serverless？

Serverless無服務器，不表明真的不須要服務器，只不過服務器由雲廠商維護。它是一種軟件系統架構思想和方法，不是軟件框架、類庫或者工具。它的核心思想是，無須關注底層資源，好比：CPU、內存和數據庫等，只需關注業務開發。

咱們從另外一個角度來看下 serverless 技術爲何這麼火。

這張圖的前三列你們應該能夠看到這 3 列表明瞭雲計算的發展階段，從剛開始的 On-Premise 到 IaaS 層，再到 PaaS 層。第四列 FaaS 層，serverless就在這一層。

在軟件研發領域，咱們繞不開的兩個環節是軟件的部署和運維。若是咱們要上線一個業務，在 On-Premise 階段，咱們要去購買物理服務器，而後還可能須要去建本身的機房，安裝製冷設備，招聘運維人員，而後再上面搭建一系列的基礎設施，好比：虛擬化，操做系統，容器，Runtime，Runtime 能夠理解爲像 python, golang, nodejs 這類軟件。接下來咱們要去安裝軟件類的開發框架，到最後，咱們纔會去編寫咱們真正須要的業務函數。到了 IaaS 層這一階段，雲廠商維護了硬件和虛擬化這兩個基礎設施。

到了 PaaS 層雲廠商又維護了 OS、容器和 Runtime，而後到了 FaaS 階段，用戶只須要關注 Function，也就是隻須要關注本身的業務邏輯。能夠看到隨着階段的演進，用戶須要關注的點愈來愈少，愈來愈聚焦於本身的業務邏輯。因此在 On-Premise 階段，咱們開發一個業務可能須要 8 我的，在 FaaS 階段，咱們只須要 2 個業務，節省了不少人力，能夠把節省的人力投入到業務研發這塊，提升產品的迭代速度，進而提升產品的競爭力。

由這張圖咱們也能夠看到，過去十多年雲計算實際上是一個「去基礎架構」的過程。這個過程可讓用戶聚焦於本身真正須要的業務開發上，而不是底層的計算資源上。serverless 符合雲計算髮展的方向，是雲的終極形態，這種特有的模式使serverless 存在潛在的巨大價值。

Serverless技術形態

這裏介紹下Serverless的技術形態。目前騰訊雲Serverless一共有3種技術形態。

一種是Cloud Function，Serverless Cloud Function 是基於事件驅動型的，大概意思就是外界觸發一個事件給 Serverless 平臺，Serverless 平臺收到觸發事件後，會調用函數並傳入觸發事件數據和參數信息，函數內部作業務邏輯處理以後返回給調用方。Serverless Cloud Function 能夠對接多種雲上的產品，好比：api網關、ckafka、cmq、COS對象存儲等。

event function 是一種開發模式，要求業務將業務邏輯拆分紅function 這種粒度，這種方式國外接受程度比較高，可是國內不少用戶都還停留在 HTTP 這個階段，爲了可以方便現有的業務遷移到 serverless 平臺，適配現有業務的調用方式以及擴展 serverless的使用場景，咱們又提供了TSF Serverless這種方式。

TSF Serverless，Service 這種形態能夠理解爲咱們一般意義上的 HTTP 服務，簡單理解就是把 HTTP 服務的運行環境從物理機或者虛擬機或者容器換成 serverless 計算資源。這種形態服務進程常駐，不限制運行時間，由於服務進程常駐，因此它一直在監聽請求，因此請求延時更低，同時也支持長鏈接和必定的內場共享能力。由於 service 這種形態，跟咱們如今的服務運行方式是一致的，因此業務能夠無縫遷移到serverless 平臺上，不須要作過多的改造。同時TSF Serverless支持Spring Cloud這種微服務框架，也支持Service Mesh這種服務形態。

還有一種就是Tencent Cloud Base這種形態，這種形態是咱們聯合微信團隊推出，簡化小程序開發流程，裏面封裝了不少功能，好比：雲函數，對象存儲，數據庫，方便用戶開發小程序。這也是雲函數的一個典型應用場景，經過封裝雲函數，提供一些PaaS能力。

Serverless Cloud Function 組件架構

Cloud Function 組件架構

這裏介紹一下Cloud Function的組件架構，讓你們瞭解下，咱們底層都作了哪些工做，來實現serverless這門技術。這張圖描述了 serverless 的組件架構。最底層是基礎設施層，底層計算資源咱們用到了 docker 和輕量化虛擬機技術，其中 docker 是 serverless1.0 的計算資源展示形態，輕量化虛擬機是serverless2.0 的計算資源展示形式，相比於 docker，輕量化虛擬機性能獲得了很是顯著的提高，能夠在幾毫秒就能夠啓動一個業務進程。在最底層咱們也作了雙活，而且對底層資源作了嚴格的安全保護。

再上一層就是資源管理層，好比說咱們有集羣監控，監控咱們的集羣監控情況，若是有集羣不可用，會立馬安排運維人員去排障，固然了，咱們剛說過咱們底層是有雙活的，當一個集羣出故障的時候，咱們能夠把流量切換到另外一個集羣，用戶是無感知的，也不會影響用戶的請求。這一層咱們有專門的自動擴縮容算法，來應對用戶的請求變化。再往上，咱們有認證和受權系統，經過認證和受權來保證函數的安全。再上面就是接入層，接入層主要用來觸發 Function 的調度和執行。在往上就是架構層，主要用來作一些流程上的調度。最上面這2 層是用戶須要關心的，用戶主須要關注本身的業務代碼，以及跟數據庫，存儲等的調用，還有本身使用的一些框架，其它底層的設施用戶徹底不用關心，全是由雲廠商來提供專業的保障和維護。

咱們還提供了不少外圍的工具系統，來支持用戶的研發、部署和排障。好比：DevOps 支持，日誌、監控、告警支持。後面會有介紹。

運維工具建設

剛纔講了Serverless是如何支持函數的運行，其實就是講了計算資源。可是要真正使用Serverless這個技術，光有計算資源還不行，還要有其它工具來支持Serverlss的開發和運維。接下來我從開發者工具，CI/CD，日誌，監控告警來介紹下騰訊雲是如何支持serverless的。

首先來介紹下開發工具，爲了支持開發者可以方便高效的開發和部署雲函數，咱們開發了一系列的工具，好比：咱們提供 VS Code 插件，經過 VS Code 插件，開發者能夠很方便的經過 IDE 直接部署、更新和調試雲函數。咱們也提供了 Web IDE 來方便用戶直接在網頁開發代碼。此外咱們還提供 CLI 工具，經過 CLI 用戶能夠在終端很、方便的經過命令調用完成諸如配置、部署、調試、調用等功能。最後咱們還提供 API 接口來知足用戶對自動化和定製化的需求。最後咱們還提供 SDK 供用戶更方便的調用雲函數的接口。因此能夠看到要將 serverless 產品化，還須要作不少其它工做來支撐 serverless 這個技術，尤爲是工具這塊兒。

除了開發者工具，咱們也提供完善的 DevOps 支持，從最佳實戰，到工做流，到工具鏈，以及產品打通，咱們都提供了不少方案和支持。

好比工做流這裏，咱們支持編碼、構建、打包、部署、測試和發佈等一系列流程。在工具這裏，咱們提供了：CLI、應用模型等。產品這裏，咱們打通了不少產品供用戶很方便的跟這些產品進行交互，利用這些產品提供的能力，好比：Git 倉庫，API 網關，ServerlessDB等。這個是 DevOps 支持。

日誌這裏咱們支持 2 種日誌查詢方式，方便用戶查看日誌。在 scf 控制檯上，可以查看函數調用成功與否，各階段的調用時間，以及用戶打印在日誌或者標準輸出的日誌，支持用戶按 RequestId 去搜索日誌。另外咱們還支持用戶將日誌輸出到騰訊雲日誌服務系統，將日誌持久化存儲，在日誌服務系統中，用戶能夠根據正則表達式來搜索日誌，也能夠自定義檢索規則，方便下次檢索。

Serverless Cloud Function 應用場景

這裏介紹一下應用場景，先介紹下 Cloud function 的應用場景，經過這張圖，咱們能夠看到，雲函數能夠做爲瀏覽器、APP 和小程序的後端服務。經過咱們提供的不一樣觸發器能夠支持不一樣的場景，好比經過 API網關觸發器，能夠匹配 websockt 的應用場景，經過cos/cmq/ckafka 觸發器能夠支持像：消息處理、流失計算，事件通知這類的應用場景。

Serverless Cloud Function 客戶案例

這個是騰訊地圖的客戶案例，走的是 event function 這種方式。場景是這樣的：用戶在訪問騰訊地圖是會產生一些數據庫，騰訊地圖會將這些數據進行整理並保存到 Hbase 和 ES 上，而後再配上一個 UI 用來查詢數據。當用戶產生一條數據時，會將這條數據放在 kafka 隊列中，kafka 觸發後端的雲函數，雲函數作數據處理以後又將數據放入 kafka 隊列中，由另一個進程從 kafka 隊列中取走處理後的數據，放入 ES 和 Hbase 中。

Tencent Cloud Base

下面介紹一下TCB。作小程序開發時，要有一個小程序前端，也須要有後端，寫後端時，須要處理不少後端須要的組件或者功能，好比數據庫、存儲或者CDN等等，都須要研發工程師本身去給產品寫接口、作調用，工做量很是大，這時候能夠經過TCB來解決，TCB就會變成右邊這樣。前端仍然有一個小程序的前端，中間We-Chat Backed主要用來作受權，當受權經過後，會把請求轉發到TCB組件，這個組件會提供不少SDK，提供的SDK裏面封裝了不少功能，好比數據庫、對象存儲以及雲函數，直接經過TCB的SDK調用，這樣就不須要處理後端那麼多組件，讓用戶很是方便的去開發一個小程序。

TSF Serverless

這裏介紹一下TSF Serverless，TSF是騰訊雲的微服務產品，這個產品底層以前是支持基於虛擬機和基於容器部署應用，咱們又增長了基於Serverless第三種部署方式。基於Serverless的話，用戶不須要去關注底層資源，只須要去部署容器就能夠了。

這個是它的組件架構，最底層是Serverless計算託管的一些功能，好比集羣管理容器，這是Serverless底層的一些計算的展示形式。再上一層微服務部署框架，這個部署能夠原生支持一些微服務功能，好比服務註冊、服務發現以及服務限流、服務熔斷、動態配置、服務監控、負載均衡、服務容錯、服務審計等等。

TSF Serverless 應用場景

這裏介紹下TSF Serverless其中的一個典型場景。假設我有一個 APP 應用跨多端的，好比 Android，iOS，Web。若是想寫後臺的話，我可能要寫多個接口，去適配不一樣的終端。這樣若是後端有變動，須要去更改 3 個終端的 API 接口，與此同時，當咱們須要對一個字符串進行處理，如限定 140 個字符的時候，咱們須要在每個客戶端（Android，iOS，Web）分別實現一遍，這樣的代價顯然至關大。

如今有一個比較流行的解決方案就是在先後端加一個 BFF 層（Backend For Frontend）將先後端解耦，這裏是 BFF 層能夠承載的能力好比：身份校驗，日誌記錄，數據組合等。BFF 通常由前端工程師去編寫，適配不一樣的後端當後端有變動的時候，只須要改 BFF 層就能夠，不用去更改客戶端。BFF 層能夠部署成 HTTP Service，也就是能夠直接利用咱們提供的 HTTP Service 技術形態來部署。經過 BFF，可讓前端工程師變成全棧工程師，開發不用去關注底層的資源。由於BFF通常是HTTP服務，因此TSF Serverless就很適合這個場景。