Serverless的架構(gòu)及使用場景是什么

Serverless的架構(gòu)及使用場景是什么，相信很多沒有經(jīng)驗的人對此束手無策，為此本文總結(jié)了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個問題。

Serverless 正在改變未來軟件開發(fā)的模式和流程，對于大多數(shù)應(yīng)用而言，借助 Serverless 服務(wù)，開發(fā)者可以將絕大多數(shù)精力投入在業(yè)務(wù)邏輯的開發(fā)整合上，大大縮短開發(fā)周期，降低運維成本。本文將探討 Serverless 生態(tài)中缺少的工具以及潛在的創(chuàng)業(yè)機會。

我們目前創(chuàng)業(yè)做的事情跟 Serverless 也是非常強相關(guān)的，目前聚焦研發(fā)一款 IDaaS 身份即服務(wù)產(chǎn)品 Authing。我之前在字節(jié)跳動負(fù)責(zé)一款日活過億的 Serverless 產(chǎn)品 LarkCloud。我個人對 Serverless 保持著長期的關(guān)注，對 Serverless 行業(yè)的發(fā)展也有很多想法，今天也跟大家分享一下。

1）云計算的發(fā)展

關(guān)于Serverless 架構(gòu)，在看這個架構(gòu)之前，我們先來回顧一下云計算的發(fā)展。圖中藍(lán)色這部分是由用戶來進(jìn)行管理的這一部分，黃色這一部分是由云服務(wù)商來進(jìn)行管理的。從早期的 On-Premises 到 FaaS ，這是云計算的發(fā)展歷程。

On-Premises 的時候，機房所有的硬件、操作系統(tǒng)、容器、運行時環(huán)境、應(yīng)用、函數(shù)等都需要自己管理；發(fā)展到 IaaS 之后，那么開發(fā)商他們不需要維護(hù)自己的硬件了，但是還是需要維護(hù)很多東西。

后來 CaaS 服務(wù)出現(xiàn)，容器即服務(wù)，我們自己不需要再維護(hù)操作系統(tǒng)層面的東西，只需要維護(hù)容器，K8s 這么短時間火起來，這也是一個很重要的原因。

那么再往下就是像阿里云、AWS 這種云計算 PaaS 平臺出來，做了很多周邊的一些工具，比如說各種各樣的監(jiān)控、報警，還有整個的服務(wù)器管理的控制臺，然后有了這種服務(wù)之后，讓客戶連這些服務(wù)也不用自己來管理了，只需要管理自己的應(yīng)用就好了，這就是 PaaS 服務(wù)。

再到現(xiàn)在，出現(xiàn) FaaS 的產(chǎn)品形態(tài)，最右邊的 FaaS 是藍(lán)色的，下層所有模塊都是黃色的，由云服務(wù)商提供，中間還有一個灰色模塊 Application ，需要云服務(wù)商和用戶一起進(jìn)行管理。

那么這是 FaaS 的一個演進(jìn)歷史，總的來說 FaaS、PaaS、CaaS 等服務(wù)發(fā)展出來的緣由：就是讓更多的客戶能夠?qū)Ｐ淖约旱臉I(yè)務(wù)，而不需要去維護(hù)底層這么多跟業(yè)務(wù)無關(guān)的基礎(chǔ)設(shè)施。

2）Serverless 架構(gòu)

接下來看一下 Serverless 架構(gòu)，這里我們以 AWS 的一些服務(wù)為例，最左邊的一個User Agent（用戶），從瀏覽器去訪問一個系統(tǒng)，首先會經(jīng)過一個API Gateway，API Gateway會出發(fā)一個函數(shù) Cloud Function，在AWS中叫 Lambda，然后 Lambda 會去執(zhí)行一些獲取資源、業(yè)務(wù)操作，這些資源都是受限的，它可能是亞馬遜的 DynamoDB、也可能是 AWS S3 存儲、也可能是亞馬遜的 EC2，也可能是你自己的一個社交數(shù)據(jù)以及通訊錄好友等。

這些資源默認(rèn)是受限的，受限的時候就需要去訪問一個無服務(wù)器的身份認(rèn)證系統(tǒng)，即圖中的 Authing ，用戶通過 Authing 進(jìn)行登錄，認(rèn)證完成之后會獲取一個 Token，然后用戶帶 Token 去請求資源，這個時候這個后端必須驗證 Token 是合法的，才能夠獲取用戶有權(quán)限訪問的資源。這是 Serverless 整體的訪問的一個流程。

現(xiàn)在很多人把 Serverless 分為兩塊，一塊叫做 FaaS（函數(shù)即服務(wù)）Functions as a Service的縮寫，只需要執(zhí)行一個函數(shù)，上傳一個函數(shù)，然后這些函數(shù)來執(zhí)行一些操作，比如說讀取你的通訊、你的地址，或讀取其他的業(yè)務(wù)信息。

另外一塊叫做 BaaS（后端即服務(wù)），全稱是 Backend as a Service，就是把整個 BaaS 代碼上傳到服務(wù)器，然后它會自動給你做一些彈性伸縮。

其實函數(shù)的粒度更細(xì)一些，然后我們今天主要探討的還是FaaS，BaaS 現(xiàn)在發(fā)展的不是特別好，我個人也不是很看好 BaaS 這塊的市場。

3）FaaS 函數(shù)的生命周期

接下來我們了解一下 FaaS 的生命周期，F(xiàn)aaS 的全稱是 Functions as a Service，開發(fā)者只需要開發(fā)一個函數(shù)，然后這個函數(shù)會根據(jù)函數(shù)的訪問量來自動的做一些收縮。FaaS 有觸發(fā)器，就是從哪一方進(jìn)行調(diào)用，比如：你在瀏覽器上請求一個 FaaS ，那么就是收到一個 HTTP 請求。又如說某個圖片被上傳到了騰訊云的 OSS 里面（OSS 是騰訊的存儲服務(wù)），那么上傳成功之后有一個回調(diào)消息，這個消息會去觸發(fā) FaaS 函數(shù)，這個就叫做 Webhook。還有一類物聯(lián)網(wǎng)場景，比如溫度采集器，測量到溫度之后，會有一種 Pub/Sub 這種消息模型，這種消息模型是異步的，也是會執(zhí)行這樣一個 FaaS 觸發(fā)器。

那么一旦是觸發(fā)了 FaaS 的執(zhí)行，就會啟動一個VM （虛擬機），那么這個 VM （虛擬機）目前主要分為兩類：一類是直接 Fork 進(jìn)程，然后在進(jìn)程里執(zhí)行這段代碼，另一類就是去啟動一個容器，然后在容器里面執(zhí)行。在 Process 進(jìn)程里執(zhí)行代碼的方式是不太安全的，所以現(xiàn)在很多人都轉(zhuǎn)向了容器。當(dāng)然容器的問題在于冷啟動時間會非常長，也就是說假如這個函數(shù)本身執(zhí)行時間只有 200 毫秒，如果加上容器的啟動時間可能也是 200 毫秒，總共的時間可能變成了 400 毫秒，那么就會造成一些網(wǎng)絡(luò)延遲，最后對用戶體驗產(chǎn)生影響。

啟動了這樣一個 VM 之后，就會去運行這個函數(shù)，運行結(jié)束之后就會把這個實例給銷毀掉，同時云服務(wù)商會根據(jù)你的運行時間來計算、所耗費的資源如：CPU、內(nèi)存、包括帶寬等等，然后計算這次運行花多少錢，來進(jìn)行一次扣費。

這就是 FaaS 函數(shù)的生命周期，接下來給大家剖析一下：為什么我們要用 FaaS ？

4）IaaS 模型

首先，我們先來看 IaaS 模型。分別從四個視角來看一下 IaaS 的整體架構(gòu)：

• 第一是從 Service Models 視角，即服務(wù)模式，分為 IaaS、PaaS、SaaS。

• 第二是從 Cloud Stack 視角，闡釋來云計算是由最底層基礎(chǔ)設(shè)施層、應(yīng)用程序棧、應(yīng)用程序、用戶層 來構(gòu)成。

• 第三是從 Stack Components 視角，來看一下詳細(xì)的構(gòu)成組件：

• 
  

• 基礎(chǔ)設(shè)施層：就是各種各樣的硬件資源，如CPU、網(wǎng)絡(luò)、帶寬、硬盤等等，由基礎(chǔ)設(shè)施廠商來提供服務(wù)，并保障最基礎(chǔ)的系統(tǒng)安全。

• Application Stack：就是需要構(gòu)建應(yīng)用所需要的基礎(chǔ)軟件技術(shù)棧，包括了操作系統(tǒng)、編程語言、應(yīng)用服務(wù)器、中間件、數(shù)據(jù)庫（關(guān)系數(shù)據(jù)庫、圖數(shù)據(jù)庫、亦或是非關(guān)系數(shù)據(jù)庫等）、還有報警監(jiān)控服務(wù)、DevOps、CI/CD、API Gateway 等。

• Application 層：開發(fā)者去建立自己的業(yè)務(wù)模型、業(yè)務(wù)應(yīng)用的時候所需要的開發(fā)組件，「認(rèn)證、授權(quán)」是其中最基礎(chǔ)的組件，然后是 UI（即用戶界面）、一些事務(wù)，比如你的支付、或直播的事務(wù)等。另外是一些報告，涉及與業(yè)務(wù)相關(guān)的用戶的增長數(shù)據(jù)的報告、管理業(yè)務(wù)的使用情況，Key Metrics 是什么樣子；另外還需要一個后臺對所有資源進(jìn)行管理。

• 用戶層：包含用戶登錄、注冊、管理等。

• 第四是從不同服務(wù)模式下計算服務(wù)供應(yīng)商和客戶之間的責(zé)任邊界。

• 
  

• IaaS 模式下：IDC 供應(yīng)商的責(zé)任是搭建最基礎(chǔ)的硬件基礎(chǔ)設(shè)施、并對保障整個系統(tǒng)的安全。而客戶需要從 OS 底層來搭建整個計算、應(yīng)用環(huán)境、以及業(yè)務(wù)的開發(fā)。

• PaaS 模式下：類似 AWS、阿里云等云服務(wù)提供商承擔(dān)了基礎(chǔ)設(shè)施的建設(shè)、以及核心基礎(chǔ)軟件環(huán)境的搭建。如操作系統(tǒng)、數(shù)據(jù)庫、中間件、監(jiān)控服務(wù)，把這些服務(wù)抽象成了一層云，然后提供給企業(yè)進(jìn)行使用?？蛻糁恍枰獙Ｗ⒃趹?yīng)用環(huán)境搭建、及業(yè)務(wù)層面的開發(fā)。

• SaaS 模式下：云服務(wù)廠商更進(jìn)一步的把「應(yīng)用環(huán)境」也服務(wù)化，客戶僅需考慮業(yè)務(wù)層面的事情。比如應(yīng)用層比較重要的兩個模塊：認(rèn)證和授權(quán)模塊也被SaaS 服務(wù)化；甚至 User 層的用戶注冊、登錄、管理功能也被 SaaS 化，在美國的已經(jīng)有 Auth0、Okta 等廠商提供這方面的服務(wù)，在中國我們 Authing 也在做類似的事情：IDaaS 身份即服務(wù)。有了 IDaaS 客戶可以更直接開發(fā)業(yè)務(wù)，不需要操心：注冊、登錄、用戶管理、認(rèn)證、授權(quán)等功能。

回頭來看在 IaaS 時代客戶需要做很多事情，基建和研發(fā)成本極高，進(jìn)入市場的時間成本很大。但是經(jīng)過一系列「服務(wù)化」進(jìn)程后，客戶愈加僅需關(guān)注自己的業(yè)務(wù)代碼，快速實現(xiàn)、快速進(jìn)入市場進(jìn)行驗證及銷售，這也是從2019年開始，Low code/No code 的創(chuàng)業(yè)項目備受資本熱捧。

5）CaaS 容器模型

隨著技術(shù)迭代，進(jìn)入到了容器模型的時代，企業(yè)的運維需要管理更多的產(chǎn)品矩陣及服務(wù)的穩(wěn)定。首先是各種各樣的服務(wù)發(fā)現(xiàn)、Container Runtime、包括整個容器集群的管理，還有一些安全性問題、性能問題，基于角色的訪問控制（RBAC）、 LDAP/AD 的管理、以及 SSO 的實現(xiàn)等。

對于開發(fā)者、運維需要學(xué)習(xí)很多 SSO 的知識，以及其他跟業(yè)務(wù)無關(guān)的很多東西，這加重了他們管理的負(fù)擔(dān)。CaaS 容器模型讓我們整個服務(wù)的可伸縮性大大提高了，但是也大大加重了運維人員的負(fù)擔(dān)。

6）Serverless 模型

行業(yè)逐步發(fā)展到了今天的 Serverless 模型，在之前模型下客戶需要操心很多的組件。但是，進(jìn)入Serverless 模型后，客戶僅需要關(guān)心是「業(yè)務(wù)代碼」，設(shè)計好自己的業(yè)務(wù)模型，把代碼部署到云服務(wù)中，就可以完成所有的復(fù)雜的一系列的部署、運維、監(jiān)控等操作。

a. FaaS 優(yōu)勢

Serverless 帶來的好處，首先是：零運維，也叫做零管理。除了零運維和零管理之外，還有其他很多優(yōu)勢，比如說按運行時間付費，你運行多長時間，就付多少錢；沒有運行資源損耗的時候，不需要付任何錢。

舉個例子，可以看上面這張圖，藍(lán)色的線代表是每秒處理多少請求；紅色的線是處理這些請求需要的服務(wù)器數(shù)量?？梢钥吹剿{(lán)色的線有兩個峰值，這代表需要 200 臺服務(wù)器，在傳統(tǒng)的架構(gòu)下就需要準(zhǔn)備 200 臺服務(wù)器。那么有了 FaaS 之后，就不需要買那么多服務(wù)器，只需要是把這個業(yè)務(wù)邏輯寫好，然后它會自動為你進(jìn)行伸縮。

伸縮的策略也非常多，比如用機器學(xué)習(xí)來進(jìn)行預(yù)測，或者說可以用一些即時計算進(jìn)行預(yù)測等等。運維人員只需要去考慮管理更少的服務(wù)器，開發(fā)人員只需要去關(guān)心業(yè)務(wù)代碼，就可以讓企業(yè)更快進(jìn)入市場，并且能夠造一個原生的微服務(wù)，顯著降低企業(yè)的管理和維護(hù)負(fù)擔(dān)。

b. FaaS 劣勢

除了優(yōu)勢之外，F(xiàn)aaS 還有很多劣勢，沒有一個通用的標(biāo)準(zhǔn)。比如 AWS、Google，還有國內(nèi)騰訊、阿里云、華為、京東云都有 FaaS 服務(wù)，但他們沒有一個通用的標(biāo)準(zhǔn)；這也造成了：客戶被供應(yīng)商鎖定的問題，無法便捷遷移。比如說我現(xiàn)在用 AWS，每天請求可能上億，想要遷移到阿里云和騰訊云就非常的麻煩。第 2 點是 FaaS 是一個黑盒子環(huán)境，開發(fā)者需要去非常了解這個東西的底層是怎么回事，他才能敢去使用，否則他無法去預(yù)估一些潛在的風(fēng)險。第 4 是冷啟動的問題，也不算什么太大的問題，云廠商已經(jīng)解決了這類問題，有很多處理方式。

第 5 個問題是最要命的一個問題，目前的 FaaS 是沒有經(jīng)過一個非常復(fù)雜應(yīng)用案例的驗證。假如說我想用 Serverless 開發(fā)一個淘寶、QQ、微信或者一個直播軟件，目前是沒有這種案例的。一方面主要是因為生態(tài)的缺乏，另外一方面的話也是因為開發(fā)人員的思維認(rèn)知沒有提升，這絕對不是一個技術(shù)的問題，技術(shù)已經(jīng)非常成熟。

c. FaaS 廠商

下圖是全球范圍內(nèi)在做 FaaS 的廠商，第一個 OpenWhisk 是 IBM 的開源的 FaaS 框架。另外一個是大家都知道的 AWS 的 Lambda，亞馬遜的云服務(wù)算是業(yè)界的一個標(biāo)準(zhǔn)，還有 Google、微軟都有類似的服務(wù)。國內(nèi)主要是阿里云、騰訊云、華為云，除了這三家之外，其實京東、滴滴其他的云都有。另外一家就是字節(jié)跳動，他們叫做輕服務(wù)，這也是我當(dāng)時在字節(jié)跳動開發(fā)的一款服務(wù)。

此外，還有一股不可忽視的力量，就是美國的 Auth0，是一款 IDaaS - 身份認(rèn)證即服務(wù)，把身份認(rèn)證上云，他們擁有一個 Webtasks 產(chǎn)品，可以讓用戶、開發(fā)者通過他們的服務(wù)快速完成身份認(rèn)證功能，更多的精力聚焦到具體的業(yè)務(wù)方面。另外一個就是我們在做的 Authing ，未來的話也會有一個 FnSuite 這樣一款函數(shù)產(chǎn)品，會和我們的業(yè)務(wù)有一個非常好的打通。

2. Serverless 使用場景

1）無服務(wù)器的應(yīng)用后端場景

接下來介紹一下 Serverless 的使用場景。

首先第一類就是這種無服務(wù)器的應(yīng)用后端，比如說我寫了一段代碼，然后我把它 push 到 Github 上去，這個時候 Github 的 webhook，我需要讓它通知到我的 Slack 或者我的飛書。

假如沒有 Serverless 的情況下，需要自己寫一個代碼后端框架，然后自己拼接一下，寫個路由，寫完路由之后，還需要再把它部署到服務(wù)器上去，然后再部署運維。

那么有了 FaaS 之后，只需要寫個函數(shù)，把它傳到阿里云或者騰訊云上，云服務(wù)商返回一個 API 鏈接，開發(fā)者把鏈接填到 Github 上去，就完成了整個操作流程，非常簡單。

還有一種是新聞消息推送應(yīng)用，一個新的用戶，它注冊了一個應(yīng)用，然后在我們這個消息里面就推送給他一些新聞。

再比如物聯(lián)網(wǎng)的應(yīng)用的后端，比如說一個溫度的信息推送系統(tǒng)，經(jīng)過 Pub/Sub 之后來去調(diào)用一個函數(shù)，然后我們的函數(shù)來執(zhí)行一些具體業(yè)務(wù)操作，比如推送到我們后臺里面進(jìn)行監(jiān)測和管理，以及一些報警等。

這就是 Serverless 的第一類無服務(wù)器應(yīng)用后端場景，如 QQ、微博、微信 IM 以及簡單的消息推送場景，都可以使用Serverless。

2）人工智能應(yīng)用場景

第二類場景：人工智能應(yīng)用。這張圖來自 Google，大家可以從左往右看，比如通過 Slack、 Messenger、或 Google Home 和機器人對話，會發(fā)送一個 Http 請求，這個請求會在云端執(zhí)行函數(shù)，然后這個函數(shù)會請求谷歌的 Dialogflow 是谷歌的一項對話管理服務(wù)。

Dialogflow 把多輪的對話管理起來，后面的其他服務(wù)：ML、Vision API 等都是由云服務(wù)商提供的能力，該廠商的 Cloud Functions （云函數(shù)）就可以直接調(diào)用這些能力，這對云服務(wù)廠商來說是非常大的一個優(yōu)勢。

所以說 Serverless 只能由這些 BigTech 來研發(fā)，一些小公司或者創(chuàng)業(yè)公司想做Serverless 基礎(chǔ)設(shè)施基本上是不太可能的，因為，Serverless 最核心競爭優(yōu)勢不僅僅前面的函數(shù)，更重要的是服務(wù)商本身所提供其他的能力可以供函數(shù)調(diào)用。

3）實時數(shù)據(jù)處理場景

第三類場景：實時數(shù)據(jù)處理，最典型的就是物聯(lián)網(wǎng)應(yīng)用，數(shù)據(jù)量非常大，用 Serverless 也是非常匹配。假如需要 1萬 QPS ，函數(shù)可以立馬生成支持 1萬 QPS 的集群，如果你自己搭一個 EC 2 服務(wù)器或者是其他應(yīng)用的話，還需要自己去管理集群，成本會變得很大。

4）AaaS 認(rèn)證即服務(wù)場景

那么還有一類最不容忽視的一個場景是：AaaS （Authentication as a Service：認(rèn)證即服務(wù)），把用戶注冊、登錄、用戶管理、認(rèn)證及授權(quán)等模塊 SaaS 服務(wù)化。為什么需要 AaaS 這類服務(wù)呢？主要有三點原因：

第一點：身份管理，是云計算里面除了計算資源、存儲資源和網(wǎng)絡(luò)資源之外，最標(biāo)準(zhǔn)化的一個產(chǎn)品。為什么說最標(biāo)準(zhǔn)化？前面 IaaS 圖中可以看到：Stack Components 包含了注冊、登錄、注冊、用戶管理以及認(rèn)證和授權(quán)模塊，基本上所有的應(yīng)用：不管 是to B、to C、to G、to Developer 基本上都是需要的且流程非常標(biāo)準(zhǔn)；甚至在基礎(chǔ)設(shè)施層面的服務(wù)，也都需要標(biāo)準(zhǔn)化的認(rèn)證服務(wù)，比如：K8S 容器編排場景中，也都有認(rèn)證/授權(quán)這種需求，另外在多云管理、DevOps 不同工具流身份的管理等。

在沒有 AaaS 云服務(wù)之前，大家都需要自己造的輪子，那么 AaaS 云服務(wù)的出現(xiàn)就讓這種重復(fù)造輪子的事情不在發(fā)生，節(jié)省巨大的社會生產(chǎn)力，并且讓身份管理變得非常簡單安全。這個也是很多的廠商都看到的這樣一個機會。

第二點：身份管理問題在數(shù)十年間，從未得到一個很好的解決，用戶以自己隱私代價來為企業(yè)「身份管理不善」買單。比如很多站點的用戶數(shù)據(jù)泄露事故，這些用戶泄露事故不僅給企業(yè)的名聲造成很大的影響，而且，嚴(yán)重?fù)p害了用戶的隱私。近期了解到的一家公司每年花幾百萬來購買身份管理服務(wù)。AaaS云服務(wù)產(chǎn)品的出現(xiàn)，將大大降低客戶的投入成本及安全成本。

第三點：合規(guī)成本逐年上升：隨著 GDPR、CCPA 、包括加拿大的 Castle 等，這些法律出臺之后，政府對于企業(yè)在身份管理方面提出了更高的要求。假如企業(yè)要去滿足這些要求，會花費巨大的成本，而使用AaaS 云服務(wù)，就可以保證企業(yè)可以非常高效、簡單、安全的擁有一個合規(guī)身份管理產(chǎn)品。

3. Serverless 使用報告

接下來看一個 Serverless 使用報告，一起來了解產(chǎn)業(yè)現(xiàn)狀，數(shù)據(jù)來源于O’Reilly serverless survey 2019。

首先是 40% 的企業(yè)已經(jīng)采用了 Serverless，這個占比還是比較大的，60% 沒有采用，市場空間還是有很大的提升空間。

30% 的 Serverless 用戶是一線工程師，然后是架構(gòu)師、技術(shù) leader 占 25%左右；還有技術(shù)類的也不少，另外一個出乎我意料的是：VP、總監(jiān)、經(jīng)理級別的用戶也近20%；

另外報告顯示，采納 Serverless 技術(shù)的行業(yè)也非常廣泛，采用最多的是軟件行業(yè)，第二大是金融及銀行業(yè)，第三大行業(yè)是咨詢行業(yè)。所以如果要在 Serverless 領(lǐng)域創(chuàng)業(yè)的話，可能最好的客戶是金融業(yè)，要么做外包，要么服務(wù)金融業(yè)。

60% 的中大型規(guī)模企業(yè)采納 Serverless：這個數(shù)字也是比較出乎意料，我們潛意識覺得采用 Serverless 新技術(shù)的可能都是小企業(yè)，但是從圖中可以看到，其中一萬人以上規(guī)模的公司，占到了 20%。

50%的 Serverless 用戶，以經(jīng)常使用 Serverless 超過一年時間，采用 Serverless 技術(shù)超過三年時間的企業(yè)也超過了10%

然后 66% 的用戶表示，采用 Serverless 技術(shù)后效果顯著。

這是為什么要使用 Serverless 的一些調(diào)查。我們看前三個最主要的幾個理由，分別是減少運營成本、可以按序的自動的伸縮。第3個是不需要再關(guān)心服務(wù)器的維護(hù)問題，和第一點差不多，降低成本。

為什么不用 Serverless 的原因調(diào)查顯示：

• 企業(yè)在采納 Serverless 技術(shù)之后面臨最大的挑戰(zhàn)是：對于當(dāng)下員工的教育成本很高，去教育員工還是比較難的，所以如果說要在 Serverless 領(lǐng)域創(chuàng)業(yè)的話，能做一家Serverless 領(lǐng)域的咨詢公司也不錯，與教育機構(gòu)合作培訓(xùn)人才。

• 第二大挑戰(zhàn)是因為 Serverless 領(lǐng)域缺乏標(biāo)準(zhǔn)，很容易被供應(yīng)商鎖定，不容易遷移到其他供應(yīng)商，這個可能需要加快推動 Serverless 行業(yè)的標(biāo)準(zhǔn)化進(jìn)程，防止被供應(yīng)商鎖定，現(xiàn)在 CNCF 基金會也在推動著這個事情。第三大挑戰(zhàn)是集成測試、調(diào)試非常困難，這也反映了 Serverless 生態(tài)供應(yīng)鏈的不健全問題，同樣，也存在創(chuàng)業(yè)機會。

• 不采用 Serverless 最大的原因是：考慮到安全問題。如果要創(chuàng)業(yè)的話，那么去解決 Serverless 的安全性問題也是一個很大的機會。第二大原因是：因為對于 Serverless 的未知而產(chǎn)生的畏難情緒，不知道使用了 Serverless 會發(fā)生什么的問題。第 3 個原因是：底層云服務(wù)商正在遷移中，來不及采用 Serverless。

什么角色在管理公司內(nèi)部 Serverless 的基礎(chǔ)設(shè)施？首先是負(fù)責(zé)DevOps 的運營人員，第二是：軟件工程師、第三是技術(shù)架構(gòu)師。這個是一個全球調(diào)查，我認(rèn)為和中國的實際情況可能不太吻合，中國可能要反過來，第一可能是架構(gòu)師來決定。第二是具有話語權(quán)的軟件工程師來決定是否采納。

最后一個調(diào)查顯示：50%+ 的企業(yè)愿意在未來三年嘗試 Serverless，所以說 Serverless 在未來還會有一個非常大的增長。

4. Serverless 工具鏈、前景和機會

最后的話我們來聊一下，Serverless 工具鏈、前景和機會。首先我們來看工具鏈，分為三個版塊，分別是開發(fā)、部署、監(jiān)控。

1）開發(fā)工具

第一是 CLI 工具：主要是兼容商業(yè) FaaS 以及開源的 FaaS ，Servereless.com 做的非常不錯了，他們已經(jīng)兼容了十幾種 FaaS 平臺。

第二是編輯器的插件：現(xiàn)在很多程序員還是習(xí)慣使用 VS Code 或者 Sublime 之類的工具進(jìn)行開發(fā)的，所以需要一個非常方便的插件，可以便于管理、調(diào)試。

第三是 WebIDE：WebIDE 是一個衍生品，主要是作為方便去開發(fā)、調(diào)試的小工具，大多數(shù)開發(fā)者應(yīng)該還是會基于本地的編輯器插件來開發(fā)。

此外，可能還有一些其它工具有待于補充。

2）部署工具

常用的部署部署工具包括：Git 集成、CI/CD 持續(xù)集成、Hooks （用于同步消息到 IM 工具）等。那么還需要做一些 Cronjob ，比如說能夠非常方便的部署定時任務(wù)，并且我能夠發(fā)布預(yù)覽版和生產(chǎn)版。

3）監(jiān)控工具

最后我們需要 monitor 來報警，需要短信通知、公司郵件通知，還需要日志等。

我說的這三點其實只是產(chǎn)品層面的一些小打小鬧，有沒有這些功能，對 Serverless 的普及和產(chǎn)業(yè)的提高并沒有太大的影響。我覺得如果要真正促進(jìn) Serverless 發(fā)展的話，還需要做以下三件事情。

5. 三個能促進(jìn)產(chǎn)業(yè)發(fā)展的機會

第一件事情是有一個 FaaS Framework 專門用來編寫大型項目，同時他是完全兼容 FaaS 架構(gòu)的。為什么需要 FaaS Framework 呢？如果沒有 FaaS Framework 的話，我們是沒有辦法用 FaaS 編寫大型項目的。一個函數(shù)，只能做一些簡單的事情，假如說需要做一個QQ，做一個微信，一個函數(shù)是肯定不行的。

第二件事是 Content as a Service，CaaS 是 FaaS 本身的更高層級的抽象，F(xiàn)aaS 是提供計算能力，然后最重要的其實還是需要一個存儲能力，尤其是結(jié)構(gòu)化數(shù)據(jù)存儲，那么就需要一個 CaaS 將存儲云化。比如我我的 CaaS 平臺去設(shè)計一些表和字段，然后這些字段中間還可以互相連接，最后他可以馬上幫我我生成 REST API 或 GraphQL 等，并且它還有和 FaaS 結(jié)合的能力，我覺得它是未來一個很大的機會。

第三類就叫做云原生編程語言。這種編程語言的話，它完全是架構(gòu)在現(xiàn)有的云計算廠商上去的，它的邏輯循環(huán)是不變的。但是他對硬盤的讀寫是在云上，并且它兼容各大云平臺，比如說我要調(diào)用 AWS 的S3，我只需要寫原生編程語言就可以，不需要去使用任何的框架，同時它可以啟動云上的服務(wù)器進(jìn)行調(diào)試。他從語言層面就是一個可伸縮的，比如說我我寫了一個 1+1=2 這樣一個計算，假如有一億請求過來，那么在他語言層面就可以幫我調(diào)度可以抵抗一億流量的計算資源。

我覺得如果說這三件事情做好的話，能對整個產(chǎn)業(yè)有一個巨大的促進(jìn)作用。

6. 總結(jié)

最后總結(jié)一下，Serverless 是真正的云計算，它真的是按需付費，然后不需要去自己去管理任何的基礎(chǔ)設(shè)施，只需要關(guān)注自己的核心業(yè)務(wù)，目前的云計算還沒有真正做到這一點。然后小公司做 Serverlss 的話基本上沒戲，主要原因是缺乏信任。

如果是創(chuàng)業(yè)公司的話，可以從以下幾個層面切入。

• 第一是做一個 FaaS 聚合器提升開發(fā)便捷度，就像 Serverless.com 做的事情一樣，

• 第二就是做一個 FaaS 沒然后接外包，這種大型的外包業(yè)務(wù)能用 Serverless 來做最好。

• 第三是開發(fā)一個 CaaS 然后覆蓋查詢業(yè)務(wù)，然后再通過和 FaaS 打通，進(jìn)而完成一些高階操作，進(jìn)而賦能業(yè)務(wù)。

• 第四個是開發(fā)云原生變成語言，然后與教育機構(gòu)、培訓(xùn)機構(gòu)、咨詢機構(gòu)合作，培養(yǎng)人才，人才有了這個意識之后，整個產(chǎn)業(yè)才能有一個更大的改變。

看完上述內(nèi)容，你們掌握Serverless的架構(gòu)及使用場景是什么的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注億速云行業(yè)資訊頻道，感謝各位的閱讀！