過去幾年間，Serverless 發展迅猛，與其相伴的還有從小程式、移動端等到前後端一體化的演進與實踐，也正因如此，從雲端計算到前端，眾多開發者都極為關注。本文介紹了騰訊雲CloudBase 的 Serverless 實踐，相信會對關注 Serverless 以及研發模式的開發者有所裨益。
Serverless到底是什麼？
在國內，Serverless 通常被稱呼為「無服務計算」。但 Serverless 不是一種具體的框架、程式碼庫或者工具集，而是一個為了減輕開發者的服務運營/運維成本而提出來的一套理論思想。
為了簡化開發者們的理解成本，業界對 Serverless 有一種結合雲端計算行業的定義方式：
Serverless = FaaS + BaaS
FaaS：Function as a Service，函式即服務。
對於 FaaS，業界已經有比較多的成熟廠商提供了線上產品，例如：
- AWS Lambda，起步最早的 FaaS 雲產品，和 AWS 的雲產品有很好的互動，開發者使用較多。
- Azure Functions，來自微軟的公有云函式計算產品，晚於 AWS lambda 釋出。
- Google Cloud Functions，來自 Google 的公有云計算產品，和 Google 的 Firebase 有較深的互動。
- 騰訊雲 Serverless Cloud Fucntion，來自騰訊雲的公有云計算產品，和騰訊雲的雲開發有較深的結合落地。
BaaS: Backend as a Service， 後端即服務。
對於 BaaS，覆蓋的範圍會更廣闊一些，需要去解決 Serverless 落地過程中除去計算而外的所有後端場景，例如資料庫服務，訊息佇列和儲存服務等。開發者在使用 BaaS 服務的時候，不再需要去感知後端的服務運維，提出服務需求，享受服務即可。例如在資料庫服務部分，通常又被細稱為 DBaaS（Database as a Service）。傳統場景下，開發者的運維團隊要關心資料庫運維的細節問題，而基於 DBaaS，開發者只需要關注業務邏輯即可。
雲開發是什麼？
雲開發（Tencent CloudBase，TCB）是騰訊雲提供的雲原生一體化開發環境和工具平臺，為開發者提供高可用、自動彈性擴縮的後端雲服務，包含計算、儲存、託管等serverless化能力，可用於雲端一體化開發多種端應用（小程式，公眾號，Web 應用，Flutter 客戶端等），幫助開發者統一構建和管理後端服務和雲資源，避免了應用開發過程中繁瑣的伺服器搭建及運維，開發者可以專注於業務邏輯的實現，開發門檻更低，效率更高。技術文件：https://cloudbase.net
技術交流加Q群：601134960
最新資訊關注微信公眾號【騰訊云云開發】
騰訊云云開發在Serverless方面取得了什麼樣的成果？
為了讓應用開發者更高效地落地創意，作為國內落地實踐 Serverless 較早的團隊，騰訊云云開發結合 Serverless 理念打造了一套服務開發者的多端一站式應用開發平臺 CloudBase，並取得了包括多端支援、大幅節約資源成本、免運維等成果驗證。
目前，騰訊云云開發服務了 50 萬的開發者，涉及的領域包含小程式、Web 應用和終端應用。開發者們可以基於雲開發 CloudBase 平臺快速構建自己的業務邏輯，釋放創意。
CloudBase在Serverless落地實踐中逐漸發現FaaS的短板
基於雲開發 CloudBase 的能力，開發者只需要關注自己的核心業務邏輯，後臺服務的可用性、可靠性、故障處理恢復等其它分散式難題全部交給雲開發來應對。
以下是雲開發 CloudBase 的一個產品矩陣圖：
雲函式是雲開發CloudBase基礎服務中的一項，也是Serverless理念中FaaS的落地。然而隨著雲開發 CloudBase 不斷服務各式各樣的開發者的過程中，雲函式也暴露出一些在解決使用者業務場景乏力的短板出來。主要包含以下幾個方面：
01改造成本
在雲函式的模式下，開發者需要進行一系列的雲函式適配性改造才可以將已有業務搬遷到雲開發上來。特別是，開發者部分業務還需要基於後臺常駐模式才可以有效執行，而云函式的事件觸發、用完即回收的特點卻無法支援開發者的這一重要訴求。
02語言生態限制
雲函式對於不同的語言需要針對性的提供不同的 Runtime，例如 Node.js 場景，隨著版本的不斷更新迭代，需要平臺不停去適配新的 Runtime 版本。另外，不同的開發語言往往還有很多的配套框架。例如 Node.js 生態的 Koa 和 Express 等等，這些框架往往依賴於系統平臺的一些機制，而云函式本身需要額外的成本去適配這些框架，對框架的適配度也將大大影響相關語言開發者的使用意願。
03效能
雲函式的按需使用，在請求真正觸發時才產生計算成本的特性大大降低了開發者的運維成本，但也同時帶來了啟動時的時延問題，也就是「冷啟動」問題。
為了解決這個冷啟動問題，雲函式可以採用首次啟動後延遲銷燬、資源預留等方法來優化，但是對於一些對效能要求較高的業務，雲函式始終無法提供逼近傳統計算模型的服務，也影響了開發者使用雲函式的意願。
為了補齊雲函式的短板，Serverless雲應用被提出。
Serverless雲應用背後的技術理念
那除了 FaaS，Serverless 的計算載體還有其他的選項麼？
答案是肯定的，2019 年 4 月谷歌科技大會，Google Cloud 宣佈將專注電信、零售、金融等垂直領域，與成熟的大型企業合作。針對此類使用者在使用 Serverless 產品時的語言生態支援有限、改造成本過大、效能等問題推出基於 Knative 的 Serverless 容器產品 CloudRun。
這裡是 Google Cloud Run 的一個產品時間軸：
那 CloudRun 背後的 Knative 理念又是怎樣的呢？
Knative 是由 Google 提出，嘗試去解決 Kubernetes 入門門檻略高的問題，這個理念已得到業界的一致認可。Knative 將重點放在三個關鍵元件上：build（構建）你的應用程式，為其提供流量 serving（服務），以及確保應用程式能夠輕鬆地生產和消費 event（事件），以下是一個直觀的表述 Knative 和 Kubernetes 之間關係的架構圖：
Serverless雲應用如何落地Knative理念？
雲開發 CloudBase 的 Serverless 雲應用是基於 Knative 來構建整個體系的，圍繞 Knative 進行了相關理念的實際落地。下面我們會從 CloudBase Serving、CloudBase Build、CloudBase 雲應用生態三個方面進行具體的闡述。
CloudBase Serving
- URL 到容器
在使用者使用 CloudBase Serverless 雲應用新建服務的時候，會產生一個與之對應的 URL，通過這個 URL，使用者即可訪問到對應的服務。那麼這個 URL 是如何通過版本進行流量管理，對映到對應的容器的呢？如下圖：
其中建立的 CloudBase 服務下允許存在多個版本（Revision）。使用者可以針對每個版本進行流量設定，Router 會根據流量佔比來進行請求路由，從而實現服務維度的定製化灰度策略。
- 擴縮至 0
在 Serverless 場景下，我們還允許使用者設定最小副本數為 0，對於一些需要常駐的服務，開發者設定最小副本數不為 0 即可，這樣可以有效應對冷啟動。
可以看到，每個 Revision 對應了 Deployment 管理的一組 Pod。
Pod 會自動上報 metrics 資料到 Autoscaler，Autoscaler 會根據請求量和資源使用情況修改 Deployment 的副本數量，從而實現自動擴縮容。Serverless 容器一個重要的特點是它會 scale to 0，也就是當應用沒有流量訪問時，它會自動銷燬所有的 Pod。
Activator 是為了處理 0→1 而出現的。當某個 revision 後面的 Pod 縮容到 0 時，Route 的流量會指向 Activator，Activator 接收到請求之後會自動拉起 Pod，然後把流量轉發過去。
CloudBase Build
CloudBase 提供三種能力來進行雲應用的交付，使用者可以通過映象、原始碼+Dockerfile、原始碼這三種方式中任一的一種進行 Serverless 雲應用部署。
下面闡述下三種方式的落地實踐：
方案選型：考慮到目前 Knative Build 仍然處於快速演進變化中（從 Knative Build → tekton pipeline），CloudBase Build 這塊暫時是複用騰訊雲現有的 build pipeline 能力進行構建交付。
- 映象方式
使用者可用已有的映象或者在本地生成的映象，通過 docker push 原生命令，將映象推送到騰訊雲個人私有映象倉庫中，即可進行 CloudBase 雲應用的部署執行了。
- 原始碼+Dockerfile
使用者可以通過原始碼+Dockerfile 的方式進行雲應用部署執行。原始碼+Dockerfile 的方式支援原生程式碼上傳，以及雲端程式碼（GitHub/GitLab/Coding 等）授權拉取部署執行。在該模式下，開發者不再需要關心映象是如何構建的，CloudBase BuildServer 會在雲端進行映象的構建。
- 原始碼
Dockerfile 還是需要一定的入門門檻，我們一直在思考有沒有辦法進一步降低使用者的使用門檻，推出了基於原始碼的方式。使用者只需要在 CloudBase Framework 下進行原始碼編寫，通過 CloudBase CLI 命令列工具就可以進行雲端構建+部署。
CloudBase 雲應用生態
為了更加方便 CloudBase 雲應用的開發者，CloudBase 雲應用還將相容 CloudBase 的生態（比如 CloudBase Server SDK，CloudBase 雲呼叫，CloudBase 雲支付等）。
當雲應用和 CloudBase 現有生態進行了結合，使用者就可以複用現有 CloudBase 生態的能力了。
舉一個例子：比如使用者的一個網站，可以將靜態資源放到靜態託管中，實現加速。將動態資源放到雲應用中，實現流量驅動。並且程式碼無需實現跨域訪問設定。雲應用可和雲函式以統一的域名對外提供訪問。
這只是生態結合的一種場景，基於雲函式可以在微信生態使用的能力（雲呼叫、雲支付），在雲應用中都可以正常的使用，這裡就不一一介紹了，期待大家的探索。
結語
雲開發 CloudBase 的 Serverless 雲應用是雲開發團隊在落地 Serverless 雲端一體化實踐過程中推出的新一代計算託管平臺。基於該平臺能力，開發者既可以享受 Serverless 帶來的免運維，專注業務快速落地創意的優勢；也沒有云函式模式下面臨相關（改造，冷啟動，Runtime 有限）限制，雲應用將是 Serverless 計算場景的一個有效補充。
當然在雲應用模式下，開發者需要理解更多的一些計算服務概念（映象，框架，Dockerfile），會比雲函式的使用上更重一些，雲函式在快速落地原型驗證，上線輕量能力上有更多的應用場景。
在傳統定義 Serverless 概念中，「Serverless=FaaS+BaaS」，這是一種前後串聯的組合關係，彼此之間的互動是單向的，FaaS 的行為單向傳遞到 BaaS。
將 Serverless 雲應用（Serverless 容器）補充到 Serverless 計算場景之後，CaaS（Container as a Service）的理念也將慢慢走近開發者，服務開發者。
因為加入 CaaS 概念的 Serverless 生態等式將會變更為：「Serverless = FaaS+CaaS+BaaS」，但是這裡僅僅是在原概念上多了一個加數麼？考慮到計算能力之間的相互傳遞，Serverless 的作用關係將會發生本質的形態變化，如下圖所示：
CaaS 會重新定義 Serverless 的語義（Serverless = FaaS+CaaS+BaaS）麼，給 Serverless 生態帶來多大的組合變化？
讓我們拭目以待。
雲開發（Tencent CloudBase，TCB）是騰訊雲提供的雲原生一體化開發環境和工具平臺，為開發者提供高可用、自動彈性擴縮的後端雲服務，包含計算、儲存、託管等serverless化能力，可用於雲端一體化開發多種端應用（小程式，公眾號，Web 應用，Flutter 客戶端等），幫助開發者統一構建和管理後端服務和雲資源，避免了應用開發過程中繁瑣的伺服器搭建及運維，開發者可以專注於業務邏輯的實現，開發門檻更低，效率更高。