溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
Serverless的架構及使用場景是什么，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。
Serverless 正在改變未來軟件開發的模式和流程，對于大多數應用而言，借助 Serverless 服務，開發者可以將絕大多數精力投入在業務邏輯的開發整合上，大大縮短開發周期，降低運維成本。本文將探討 Serverless 生態中缺少的工具以及潛在的創業機會。
我們目前創業做的事情跟 Serverless 也是非常強相關的，目前聚焦研發一款 IDaaS 身份即服務產品 Authing。我之前在字節跳動負責一款日活過億的 Serverless 產品 LarkCloud。我個人對 Serverless 保持著長期的關注，對 Serverless 行業的發展也有很多想法，今天也跟大家分享一下。
關于Serverless 架構，在看這個架構之前，我們先來回顧一下云計算的發展。圖中藍色這部分是由用戶來進行管理的這一部分，黃色這一部分是由云服務商來進行管理的。從早期的 On-Premises 到 FaaS ，這是云計算的發展歷程。
On-Premises 的時候，機房所有的硬件、操作系統、容器、運行時環境、應用、函數等都需要自己管理；發展到 IaaS 之后，那么開發商他們不需要維護自己的硬件了，但是還是需要維護很多東西。
后來 CaaS 服務出現，容器即服務，我們自己不需要再維護操作系統層面的東西，只需要維護容器，K8s 這么短時間火起來，這也是一個很重要的原因。
那么再往下就是像阿里云、AWS 這種云計算 PaaS 平臺出來，做了很多周邊的一些工具，比如說各種各樣的監控、報警，還有整個的服務器管理的控制臺，然后有了這種服務之后，讓客戶連這些服務也不用自己來管理了，只需要管理自己的應用就好了，這就是 PaaS 服務。
再到現在，出現 FaaS 的產品形態，最右邊的 FaaS 是藍色的，下層所有模塊都是黃色的，由云服務商提供，中間還有一個灰色模塊 Application ，需要云服務商和用戶一起進行管理。
那么這是 FaaS 的一個演進歷史，總的來說 FaaS、PaaS、CaaS 等服務發展出來的緣由：就是讓更多的客戶能夠專心自己的業務，而不需要去維護底層這么多跟業務無關的基礎設施。
接下來看一下 Serverless 架構，這里我們以 AWS 的一些服務為例，最左邊的一個User Agent（用戶），從瀏覽器去訪問一個系統，首先會經過一個API Gateway，API Gateway會出發一個函數 Cloud Function，在AWS中叫 Lambda，然后 Lambda 會去執行一些獲取資源、業務操作，這些資源都是受限的，它可能是亞馬遜的 DynamoDB、也可能是 AWS S3 存儲、也可能是亞馬遜的 EC2，也可能是你自己的一個社交數據以及通訊錄好友等。
這些資源默認是受限的，受限的時候就需要去訪問一個無服務器的身份認證系統，即圖中的 Authing ，用戶通過 Authing 進行登錄，認證完成之后會獲取一個 Token，然后用戶帶 Token 去請求資源，這個時候這個后端必須驗證 Token 是合法的，才能夠獲取用戶有權限訪問的資源。這是 Serverless 整體的訪問的一個流程。
現在很多人把 Serverless 分為兩塊，一塊叫做 FaaS（函數即服務）Functions as a Service的縮寫，只需要執行一個函數，上傳一個函數，然后這些函數來執行一些操作，比如說讀取你的通訊、你的地址，或讀取其他的業務信息。
另外一塊叫做 BaaS（后端即服務），全稱是 Backend as a Service，就是把整個 BaaS 代碼上傳到服務器，然后它會自動給你做一些彈性伸縮。
其實函數的粒度更細一些，然后我們今天主要探討的還是FaaS，BaaS 現在發展的不是特別好，我個人也不是很看好 BaaS 這塊的市場。
接下來我們了解一下 FaaS 的生命周期，FaaS 的全稱是 Functions as a Service，開發者只需要開發一個函數，然后這個函數會根據函數的訪問量來自動的做一些收縮。FaaS 有觸發器，就是從哪一方進行調用，比如：你在瀏覽器上請求一個 FaaS ，那么就是收到一個 HTTP 請求。又如說某個圖片被上傳到了騰訊云的 OSS 里面（OSS 是騰訊的存儲服務），那么上傳成功之后有一個回調消息，這個消息會去觸發 FaaS 函數，這個就叫做 Webhook。還有一類物聯網場景，比如溫度采集器，測量到溫度之后，會有一種 Pub/Sub 這種消息模型，這種消息模型是異步的，也是會執行這樣一個 FaaS 觸發器。
那么一旦是觸發了 FaaS 的執行，就會啟動一個VM （虛擬機），那么這個 VM （虛擬機）目前主要分為兩類：一類是直接 Fork 進程，然后在進程里執行這段代碼，另一類就是去啟動一個容器，然后在容器里面執行。在 Process 進程里執行代碼的方式是不太安全的，所以現在很多人都轉向了容器。當然容器的問題在于冷啟動時間會非常長，也就是說假如這個函數本身執行時間只有 200 毫秒，如果加上容器的啟動時間可能也是 200 毫秒，總共的時間可能變成了 400 毫秒，那么就會造成一些網絡延遲，最后對用戶體驗產生影響。
啟動了這樣一個 VM 之后，就會去運行這個函數，運行結束之后就會把這個實例給銷毀掉，同時云服務商會根據你的運行時間來計算、所耗費的資源如：CPU、內存、包括帶寬等等，然后計算這次運行花多少錢，來進行一次扣費。
這就是 FaaS 函數的生命周期，接下來給大家剖析一下：為什么我們要用 FaaS ？
首先，我們先來看 IaaS 模型。分別從四個視角來看一下 IaaS 的整體架構：
第一是從 Service Models 視角，即服務模式，分為 IaaS、PaaS、SaaS。
第二是從 Cloud Stack 視角，闡釋來云計算是由最底層基礎設施層、應用程序棧、應用程序、用戶層 來構成。
第三是從 Stack Components 視角，來看一下詳細的構成組件：
基礎設施層：就是各種各樣的硬件資源，如CPU、網絡、帶寬、硬盤等等，由基礎設施廠商來提供服務，并保障最基礎的系統安全。
Application Stack：就是需要構建應用所需要的基礎軟件技術棧，包括了操作系統、編程語言、應用服務器、中間件、數據庫（關系數據庫、圖數據庫、亦或是非關系數據庫等）、還有報警監控服務、DevOps、CI/CD、API Gateway 等。
Application 層：開發者去建立自己的業務模型、業務應用的時候所需要的開發組件，「認證、授權」是其中最基礎的組件，然后是 UI（即用戶界面）、一些事務，比如你的支付、或直播的事務等。另外是一些報告，涉及與業務相關的用戶的增長數據的報告、管理業務的使用情況，Key Metrics 是什么樣子；另外還需要一個后臺對所有資源進行管理。
用戶層：包含用戶登錄、注冊、管理等。
第四是從不同服務模式下計算服務供應商和客戶之間的責任邊界。
IaaS 模式下：IDC 供應商的責任是搭建最基礎的硬件基礎設施、并對保障整個系統的安全。而客戶需要從 OS 底層來搭建整個計算、應用環境、以及業務的開發。
PaaS 模式下：類似 AWS、阿里云等云服務提供商承擔了基礎設施的建設、以及核心基礎軟件環境的搭建。如操作系統、數據庫、中間件、監控服務，把這些服務抽象成了一層云，然后提供給企業進行使用。客戶只需要專注在應用環境搭建、及業務層面的開發。
SaaS 模式下：云服務廠商更進一步的把「應用環境」也服務化，客戶僅需考慮業務層面的事情。比如應用層比較重要的兩個模塊：認證和授權模塊也被SaaS 服務化；甚至 User 層的用戶注冊、登錄、管理功能也被 SaaS 化，在美國的已經有 Auth0、Okta 等廠商提供這方面的服務，在中國我們 Authing 也在做類似的事情：IDaaS 身份即服務。有了 IDaaS 客戶可以更直接開發業務，不需要操心：注冊、登錄、用戶管理、認證、授權等功能。
回頭來看在 IaaS 時代客戶需要做很多事情，基建和研發成本極高，進入市場的時間成本很大。但是經過一系列「服務化」進程后，客戶愈加僅需關注自己的業務代碼，快速實現、快速進入市場進行驗證及銷售，這也是從2019年開始，Low code/No code 的創業項目備受資本熱捧。
隨著技術迭代，進入到了容器模型的時代，企業的運維需要管理更多的產品矩陣及服務的穩定。首先是各種各樣的服務發現、Container Runtime、包括整個容器集群的管理，還有一些安全性問題、性能問題，基于角色的訪問控制（RBAC）、 LDAP/AD 的管理、以及 SSO 的實現等。
對于開發者、運維需要學習很多 SSO 的知識，以及其他跟業務無關的很多東西，這加重了他們管理的負擔。CaaS 容器模型讓我們整個服務的可伸縮性大大提高了，但是也大大加重了運維人員的負擔。
行業逐步發展到了今天的 Serverless 模型，在之前模型下客戶需要操心很多的組件。但是，進入Serverless 模型后，客戶僅需要關心是「業務代碼」，設計好自己的業務模型，把代碼部署到云服務中，就可以完成所有的復雜的一系列的部署、運維、監控等操作。
a. FaaS 優勢
Serverless 帶來的好處，首先是：零運維，也叫做零管理。除了零運維和零管理之外，還有其他很多優勢，比如說按運行時間付費，你運行多長時間，就付多少錢；沒有運行資源損耗的時候，不需要付任何錢。
舉個例子，可以看上面這張圖，藍色的線代表是每秒處理多少請求；紅色的線是處理這些請求需要的服務器數量。可以看到藍色的線有兩個峰值，這代表需要 200 臺服務器，在傳統的架構下就需要準備 200 臺服務器。那么有了 FaaS 之后，就不需要買那么多服務器，只需要是把這個業務邏輯寫好，然后它會自動為你進行伸縮。
伸縮的策略也非常多，比如用機器學習來進行預測，或者說可以用一些即時計算進行預測等等。運維人員只需要去考慮管理更少的服務器，開發人員只需要去關心業務代碼，就可以讓企業更快進入市場，并且能夠造一個原生的微服務，顯著降低企業的管理和維護負擔。
b. FaaS 劣勢
除了優勢之外，FaaS 還有很多劣勢，沒有一個通用的標準。比如 AWS、Google，還有國內騰訊、阿里云、華為、京東云都有 FaaS 服務，但他們沒有一個通用的標準；這也造成了：客戶被供應商鎖定的問題，無法便捷遷移。比如說我現在用 AWS，每天請求可能上億，想要遷移到阿里云和騰訊云就非常的麻煩。第 2 點是 FaaS 是一個黑盒子環境，開發者需要去非常了解這個東西的底層是怎么回事，他才能敢去使用，否則他無法去預估一些潛在的風險。第 4 是冷啟動的問題，也不算什么太大的問題，云廠商已經解決了這類問題，有很多處理方式。
第 5 個問題是最要命的一個問題，目前的 FaaS 是沒有經過一個非常復雜應用案例的驗證。假如說我想用 Serverless 開發一個淘寶、QQ、微信或者一個直播軟件，目前是沒有這種案例的。一方面主要是因為生態的缺乏，另外一方面的話也是因為開發人員的思維認知沒有提升，這絕對不是一個技術的問題，技術已經非常成熟。
c. FaaS 廠商
下圖是全球范圍內在做 FaaS 的廠商，第一個 OpenWhisk 是 IBM 的開源的 FaaS 框架。另外一個是大家都知道的 AWS 的 Lambda，亞馬遜的云服務算是業界的一個標準，還有 Google、微軟都有類似的服務。國內主要是阿里云、騰訊云、華為云，除了這三家之外，其實京東、滴滴其他的云都有。另外一家就是字節跳動，他們叫做輕服務，這也是我當時在字節跳動開發的一款服務。
此外，還有一股不可忽視的力量，就是美國的 Auth0，是一款 IDaaS - 身份認證即服務，把身份認證上云，他們擁有一個 Webtasks 產品，可以讓用戶、開發者通過他們的服務快速完成身份認證功能，更多的精力聚焦到具體的業務方面。另外一個就是我們在做的 Authing ，未來的話也會有一個 FnSuite 這樣一款函數產品，會和我們的業務有一個非常好的打通。
接下來介紹一下 Serverless 的使用場景。
首先第一類就是這種無服務器的應用后端，比如說我寫了一段代碼，然后我把它 push 到 Github 上去，這個時候 Github 的 webhook，我需要讓它通知到我的 Slack 或者我的飛書。
假如沒有 Serverless 的情況下，需要自己寫一個代碼后端框架，然后自己拼接一下，寫個路由，寫完路由之后，還需要再把它部署到服務器上去，然后再部署運維。
那么有了 FaaS 之后，只需要寫個函數，把它傳到阿里云或者騰訊云上，云服務商返回一個 API 鏈接，開發者把鏈接填到 Github 上去，就完成了整個操作流程，非常簡單。
還有一種是新聞消息推送應用，一個新的用戶，它注冊了一個應用，然后在我們這個消息里面就推送給他一些新聞。
再比如物聯網的應用的后端，比如說一個溫度的信息推送系統，經過 Pub/Sub 之后來去調用一個函數，然后我們的函數來執行一些具體業務操作，比如推送到我們后臺里面進行監測和管理，以及一些報警等。
這就是 Serverless 的第一類無服務器應用后端場景，如 QQ、微博、微信 IM 以及簡單的消息推送場景，都可以使用Serverless。
第二類場景：人工智能應用。這張圖來自 Google，大家可以從左往右看，比如通過 Slack、 Messenger、或 Google Home 和機器人對話，會發送一個 Http 請求，這個請求會在云端執行函數，然后這個函數會請求谷歌的 Dialogflow 是谷歌的一項對話管理服務。
Dialogflow 把多輪的對話管理起來，后面的其他服務：ML、Vision API 等都是由云服務商提供的能力，該廠商的 Cloud Functions （云函數）就可以直接調用這些能力，這對云服務廠商來說是非常大的一個優勢。
所以說 Serverless 只能由這些 BigTech 來研發，一些小公司或者創業公司想做Serverless 基礎設施基本上是不太可能的，因為，Serverless 最核心競爭優勢不僅僅前面的函數，更重要的是服務商本身所提供其他的能力可以供函數調用。
第三類場景：實時數據處理，最典型的就是物聯網應用，數據量非常大，用 Serverless 也是非常匹配。假如需要 1萬 QPS ，函數可以立馬生成支持 1萬 QPS 的集群，如果你自己搭一個 EC 2 服務器或者是其他應用的話，還需要自己去管理集群，成本會變得很大。
那么還有一類最不容忽視的一個場景是：AaaS （Authentication as a Service：認證即服務），把用戶注冊、登錄、用戶管理、認證及授權等模塊 SaaS 服務化。為什么需要 AaaS 這類服務呢？主要有三點原因：
第一點：身份管理，是云計算里面除了計算資源、存儲資源和網絡資源之外，最標準化的一個產品。為什么說最標準化？前面 IaaS 圖中可以看到：Stack Components 包含了注冊、登錄、注冊、用戶管理以及認證和授權模塊，基本上所有的應用：不管 是to B、to C、to G、to Developer 基本上都是需要的且流程非常標準；甚至在基礎設施層面的服務，也都需要標準化的認證服務，比如：K8S 容器編排場景中，也都有認證/授權這種需求，另外在多云管理、DevOps 不同工具流身份的管理等。
在沒有 AaaS 云服務之前，大家都需要自己造的輪子，那么 AaaS 云服務的出現就讓這種重復造輪子的事情不在發生，節省巨大的社會生產力，并且讓身份管理變得非常簡單安全。這個也是很多的廠商都看到的這樣一個機會。
第二點：身份管理問題在數十年間，從未得到一個很好的解決，用戶以自己隱私代價來為企業「身份管理不善」買單。比如很多站點的用戶數據泄露事故，這些用戶泄露事故不僅給企業的名聲造成很大的影響，而且，嚴重損害了用戶的隱私。近期了解到的一家公司每年花幾百萬來購買身份管理服務。AaaS云服務產品的出現，將大大降低客戶的投入成本及安全成本。
第三點：合規成本逐年上升：隨著 GDPR、CCPA 、包括加拿大的 Castle 等，這些法律出臺之后，政府對于企業在身份管理方面提出了更高的要求。假如企業要去滿足這些要求，會花費巨大的成本，而使用AaaS 云服務，就可以保證企業可以非常高效、簡單、安全的擁有一個合規身份管理產品。
接下來看一個 Serverless 使用報告，一起來了解產業現狀，數據來源于O’Reilly serverless survey 2019。
首先是 40% 的企業已經采用了 Serverless，這個占比還是比較大的，60% 沒有采用，市場空間還是有很大的提升空間。
30% 的 Serverless 用戶是一線工程師，然后是架構師、技術 leader 占 25%左右；還有技術類的也不少，另外一個出乎我意料的是：VP、總監、經理級別的用戶也近20%；
另外報告顯示，采納 Serverless 技術的行業也非常廣泛，采用最多的是軟件行業，第二大是金融及銀行業，第三大行業是咨詢行業。所以如果要在 Serverless 領域創業的話，可能最好的客戶是金融業，要么做外包，要么服務金融業。
60% 的中大型規模企業采納 Serverless：這個數字也是比較出乎意料，我們潛意識覺得采用 Serverless 新技術的可能都是小企業，但是從圖中可以看到，其中一萬人以上規模的公司，占到了 20%。
50%的 Serverless 用戶，以經常使用 Serverless 超過一年時間，采用 Serverless 技術超過三年時間的企業也超過了10%
然后 66% 的用戶表示，采用 Serverless 技術后效果顯著。
這是為什么要使用 Serverless 的一些調查。我們看前三個最主要的幾個理由，分別是減少運營成本、可以按序的自動的伸縮。第3個是不需要再關心服務器的維護問題，和第一點差不多，降低成本。
為什么不用 Serverless 的原因調查顯示：
企業在采納 Serverless 技術之后面臨最大的挑戰是：對于當下員工的教育成本很高，去教育員工還是比較難的，所以如果說要在 Serverless 領域創業的話，能做一家Serverless 領域的咨詢公司也不錯，與教育機構合作培訓人才。
第二大挑戰是因為 Serverless 領域缺乏標準，很容易被供應商鎖定，不容易遷移到其他供應商，這個可能需要加快推動 Serverless 行業的標準化進程，防止被供應商鎖定，現在 CNCF 基金會也在推動著這個事情。第三大挑戰是集成測試、調試非常困難，這也反映了 Serverless 生態供應鏈的不健全問題，同樣，也存在創業機會。
不采用 Serverless 最大的原因是：考慮到安全問題。如果要創業的話，那么去解決 Serverless 的安全性問題也是一個很大的機會。第二大原因是：因為對于 Serverless 的未知而產生的畏難情緒，不知道使用了 Serverless 會發生什么的問題。第 3 個原因是：底層云服務商正在遷移中，來不及采用 Serverless。
什么角色在管理公司內部 Serverless 的基礎設施？首先是負責DevOps 的運營人員，第二是：軟件工程師、第三是技術架構師。這個是一個全球調查，我認為和中國的實際情況可能不太吻合，中國可能要反過來，第一可能是架構師來決定。第二是具有話語權的軟件工程師來決定是否采納。
最后一個調查顯示：50%+ 的企業愿意在未來三年嘗試 Serverless，所以說 Serverless 在未來還會有一個非常大的增長。
最后的話我們來聊一下，Serverless 工具鏈、前景和機會。首先我們來看工具鏈，分為三個版塊，分別是開發、部署、監控。
第一是 CLI 工具：主要是兼容商業 FaaS 以及開源的 FaaS ，Servereless.com 做的非常不錯了，他們已經兼容了十幾種 FaaS 平臺。
第二是編輯器的插件：現在很多程序員還是習慣使用 VS Code 或者 Sublime 之類的工具進行開發的，所以需要一個非常方便的插件，可以便于管理、調試。
第三是 WebIDE：WebIDE 是一個衍生品，主要是作為方便去開發、調試的小工具，大多數開發者應該還是會基于本地的編輯器插件來開發。
此外，可能還有一些其它工具有待于補充。
常用的部署部署工具包括：Git 集成、CI/CD 持續集成、Hooks （用于同步消息到 IM 工具）等。那么還需要做一些 Cronjob ，比如說能夠非常方便的部署定時任務，并且我能夠發布預覽版和生產版。
最后我們需要 monitor 來報警，需要短信通知、公司郵件通知，還需要日志等。
我說的這三點其實只是產品層面的一些小打小鬧，有沒有這些功能，對 Serverless 的普及和產業的提高并沒有太大的影響。我覺得如果要真正促進 Serverless 發展的話，還需要做以下三件事情。
第一件事情是有一個 FaaS Framework 專門用來編寫大型項目，同時他是完全兼容 FaaS 架構的。為什么需要 FaaS Framework 呢？如果沒有 FaaS Framework 的話，我們是沒有辦法用 FaaS 編寫大型項目的。一個函數，只能做一些簡單的事情，假如說需要做一個QQ，做一個微信，一個函數是肯定不行的。
第二件事是 Content as a Service，CaaS 是 FaaS 本身的更高層級的抽象，FaaS 是提供計算能力，然后最重要的其實還是需要一個存儲能力，尤其是結構化數據存儲，那么就需要一個 CaaS 將存儲云化。比如我我的 CaaS 平臺去設計一些表和字段，然后這些字段中間還可以互相連接，最后他可以馬上幫我我生成 REST API 或 GraphQL 等，并且它還有和 FaaS 結合的能力，我覺得它是未來一個很大的機會。
第三類就叫做云原生編程語言。這種編程語言的話，它完全是架構在現有的云計算廠商上去的，它的邏輯循環是不變的。但是他對硬盤的讀寫是在云上，并且它兼容各大云平臺，比如說我要調用 AWS 的S3，我只需要寫原生編程語言就可以，不需要去使用任何的框架，同時它可以啟動云上的服務器進行調試。他從語言層面就是一個可伸縮的，比如說我我寫了一個 1+1=2 這樣一個計算，假如有一億請求過來，那么在他語言層面就可以幫我調度可以抵抗一億流量的計算資源。
我覺得如果說這三件事情做好的話，能對整個產業有一個巨大的促進作用。
最后總結一下，Serverless 是真正的云計算，它真的是按需付費，然后不需要去自己去管理任何的基礎設施，只需要關注自己的核心業務，目前的云計算還沒有真正做到這一點。然后小公司做 Serverlss 的話基本上沒戲，主要原因是缺乏信任。
如果是創業公司的話，可以從以下幾個層面切入。
第一是做一個 FaaS 聚合器提升開發便捷度，就像 Serverless.com 做的事情一樣，
第二就是做一個 FaaS 沒然后接外包，這種大型的外包業務能用 Serverless 來做最好。
第三是開發一個 CaaS 然后覆蓋查詢業務，然后再通過和 FaaS 打通，進而完成一些高階操作，進而賦能業務。
第四個是開發云原生變成語言，然后與教育機構、培訓機構、咨詢機構合作，培養人才，人才有了這個意識之后，整個產業才能有一個更大的改變。
看完上述內容，你們掌握Serverless的架構及使用場景是什么的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
