一、 無服務器（Serverless）計算是什么

云計算涌現(xiàn)出很多改變傳統(tǒng)IT架構(gòu)和運維方式的新技術(shù)，比如虛擬機、容器、微服務，無論這些技術(shù)應用在哪些場景，降低成本、提升效率是云服務永恒的主題。過去十年來，我們已經(jīng)把應用和環(huán)境中很多通用的部分變成了服務。Serverless的出現(xiàn)，帶來了跨越式變革。Serverless把主機管理、操作系統(tǒng)管理、資源分配、擴容，甚至是應用邏輯的全部組件都外包出去，把它們看作某種形式的商品——廠商提供服務，我們掏錢購買。過去是“構(gòu)建一個框架運行在一臺服務器上，對多個事件進行響應”，Serverless則變?yōu)椤皹?gòu)建或使用一個微服務或微功能來響應一個事件”，做到當訪問時，調(diào)入相關資源開始運行，運行完成后，卸載所有開銷，真正做到按需按次計費。這是云計算向縱深發(fā)展的一種自然而然的過程。
Serverless是一種構(gòu)建和管理基于微服務架構(gòu)的完整流程，允許你在服務部署級別而不是服務器部署級別來管理你的應用部署。它與傳統(tǒng)架構(gòu)的不同之處在于，完全由第三方管理，由事件觸發(fā)，存在于無狀態(tài)（Stateless）、暫存（可能只存在于一次調(diào)用的過程中）計算容器內(nèi)。構(gòu)建無服務器應用程序意味著開發(fā)者可以專注在產(chǎn)品代碼上，而無須管理和操作云端或本地的服務器或運行時。Serverless真正做到了部署應用無需涉及基礎設施的建設，自動構(gòu)建、部署和啟動服務。
國內(nèi)外的各大云廠商 Amazon、微軟、Google、IBM、阿里云、騰訊云、華為云相繼推出Serverless產(chǎn)品，Serverless也從概念、愿景逐步走向落地，在各企業(yè)、公司應用開來。

專注于為中小企業(yè)提供成都做網(wǎng)站、成都網(wǎng)站制作、成都外貿(mào)網(wǎng)站建設服務,電腦端+手機端+微信端的三站合一,更高效的管理,為中小企業(yè)天元免費做網(wǎng)站提供優(yōu)質(zhì)的服務。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動了上1000家企業(yè)的穩(wěn)健成長，幫助中小企業(yè)通過網(wǎng)站建設實現(xiàn)規(guī)模擴充和轉(zhuǎn)變。

二、 理解Serverless技術(shù)---FaaS和BaaS
Serverless由開發(fā)者實現(xiàn)的服務端邏輯運行在無狀態(tài)的計算容器中，它由事件觸發(fā)， 完全被第三方管理，其業(yè)務層面的狀態(tài)則被開發(fā)者使用的數(shù)據(jù)庫和存儲資源所記錄。
Serverless涵蓋了很多技術(shù)，分為兩類：FaaS和BaaS。
1）Function-as-a-Service (FaaS)
? 小段代碼，按需執(zhí)?，按需擴展，無需管理任何基礎實施相關的部分。
? 事件驅(qū)動型計算。函數(shù)被事件觸發(fā)或者被HTTP請求調(diào)用。
2）Backend-as-a-Service (BaaS)
? 第三方基于API的服務，實現(xiàn)應用開發(fā)中的基礎功能模塊。
? 這些API像服務一樣，自動擴展，無需管理。

1.Faas
FaaS意在無須自行管理服務器系統(tǒng)或自己的服務器應用程序，即可直接運行后端代碼。其中所指的服務器應用程序，是該技術(shù)與容器和PaaS（平臺即服務）等其他現(xiàn)代化架構(gòu)最大的差異。
FaaS可以取代一些服務處理服務器（可能是物理計算機，但絕對需要運行某種應用程序），這樣不僅不需要自行供應服務器，也不需要全時運行應用程序。
FaaS產(chǎn)品不要求必須使用特定框架或庫進行開發(fā)。在語言和環(huán)境方面，F(xiàn)aaS函數(shù)就是常規(guī)的應用程序。例如AWS Lambda的函數(shù)可以通過Javascript、Python以及任何JVM語言（Java、Clojure、Scala）等實現(xiàn)。然而Lambda函數(shù)也可以執(zhí)行任何捆綁有所需部署構(gòu)件的進程，因此可以使用任何語言，只要能編譯為Unix進程即可。FaaS函數(shù)在架構(gòu)方面確實存在一定的局限，尤其是在狀態(tài)和執(zhí)行時間方面。
在遷往FaaS的過程中，唯一需要修改的代碼是“主方法/啟動”代碼，其中可能需要刪除頂級消息處理程序的相關代碼（“消息監(jiān)聽器接口”的實現(xiàn)），但這可能只需要更改方法簽名即可。在FaaS的世界中，代碼的其余所有部分（例如向數(shù)據(jù)庫執(zhí)行寫入的代碼）無須任何變化。
相比傳統(tǒng)系統(tǒng)，部署方法會有較大變化 – 將代碼上傳至FaaS供應商，其他事情均可由供應商完成。目前這種方式通常意味著需要上傳代碼的全新定義（例如上傳zip或JAR文件），隨后調(diào)用一個專有API發(fā)起更新過程。
FaaS中的函數(shù)可以通過供應商定義的事件類型觸發(fā)。對于亞馬遜AWS，此類觸發(fā)事件可以包括S3（文件）更新、時間（計劃任務），以及加入消息總線的消息（例如Kinesis）。通常你的函數(shù)需要通過參數(shù)指定自己需要綁定到的事件源。
大部分供應商還允許函數(shù)作為對傳入Http請求的響應來觸發(fā)，通常這類請求來自某種該類型的API網(wǎng)關（例如AWS API網(wǎng)關、Webtask）。

2.Baas
BaaS（Backend as a Service，后端即服務）是指我們不再編寫或管理所有服務端組件，可以使用領域通用的遠程組件（而不是進程內(nèi)的庫）來提供服務。理解BaaS，需要搞清楚它與PaaS的區(qū)別。
首先BaaS并非PaaS，它們的區(qū)別在于：PaaS需要參與應用的生命周期管理，BaaS則僅僅提供應用依賴的第三方服務。典型的PaaS平臺需要提供手段讓開發(fā)者部署和配置應用，例如自動將應用部署到Tomcat容器中，并管理應用的生命周期。BaaS不包含這些內(nèi)容，BaaS只以API的方式提供應用依賴的后端服務，例如數(shù)據(jù)庫和對象存儲。BaaS可以是公共云服務商提供的，也可以是第三方廠商提供的。其次從功能上講，BaaS可以看作PaaS的一個子集，即提供第三方依賴組件的部分。

BaaS服務還允許我們依賴其他人已經(jīng)實現(xiàn)的應用邏輯。對于這點，認證就是一個很好的例子。很多應用都要自己編寫實現(xiàn)注冊、登錄、密碼管理等邏輯的代碼，而對于不同的應用這些代碼往往大同小異。完全可以把這些重復性的工作提取出來，再做成外部服務，而這正是Auth0和Amazon Cognito等產(chǎn)品的目標。它們能實現(xiàn)全面的認證和用戶管理，開發(fā)團隊再也不用自己編寫或者管理實現(xiàn)這些功能的代碼。

三、 無服務器（Serverless）計算如何工作？
與使用虛擬機或一些底層的技術(shù)來部署和管理應用程序相比，無服務器計算提供了一種更高級別的抽象。因為它們有不同的抽象和“觸發(fā)器”的集合。
拿計算來講，這種抽象有一個特定函數(shù)和抽象的觸發(fā)器，它通常是一個事件。以數(shù)據(jù)庫為例，這種抽象也許是一個表，而觸發(fā)器相當于表的查詢或搜索，或者通過在表中做一些事情而生成的事件。
比如一款手機游戲，允許用戶在不同的平臺上為全球頂級玩家使用高分數(shù)表。當請求此信息時，請求從應用程序到API接口。API接口或許會觸發(fā)AWS的Lambda函數(shù)，或者無服務器函數(shù)，這些函數(shù)再從數(shù)據(jù)庫表中獲取到數(shù)據(jù)流，返回包含前五名分數(shù)的一定格式的數(shù)據(jù)。
一旦構(gòu)建完成，應用程序的功能就可以在基于移動和基于 Web 的游戲版本中重用。
這跟設置服務器不同，不是必須要有Amazon EC2實例或服務器，然后等待請求。環(huán)境由事件觸發(fā)，而響應事件所需的邏輯只在響應時執(zhí)行。這意味著，運行函數(shù)的資源只有在函數(shù)運行時被創(chuàng)建，產(chǎn)生一種非常高效的方法來構(gòu)建應用程序。

四、 無服務器（Serverless）適用于哪些場景？

在現(xiàn)階段，Serverless主要應用在以下幾個場景。首先在Web及移動端服務中，可以整合API網(wǎng)關和Serverles服務構(gòu)建Web及移動后端，幫助開發(fā)者構(gòu)建可彈性擴展、高可用的移動或 Web后端應用服務。在IoT場景下可高效的處理實時流數(shù)據(jù)，由設備產(chǎn)生海量的實時信息流數(shù)據(jù)，通過Serverles服務分類處理并寫入后端處理。另外在實時媒體資訊內(nèi)容處理場景里，用戶上傳的音視頻到對象存儲OBS，通過上傳事件觸發(fā)多個函數(shù)，分別完成高清轉(zhuǎn)碼、音頻轉(zhuǎn)碼等功能，滿足用戶對實時性和并發(fā)能力的高要求。無服務器計算還適合于任何事件驅(qū)動的各種不同的用例，這包括物聯(lián)網(wǎng)，移動應用，基于網(wǎng)絡的應用程序和聊天機器人等。這里簡單說兩個場景，方便大家思考。
場景一：應用負載有顯著的波峰波谷
Serverless 應用成功與否的評判標準并不是公司規(guī)模的大小，而是其業(yè)務背后的具體技術(shù)問題，比如業(yè)務波峰波谷明顯，如何實現(xiàn)削峰填谷。一個公司的業(yè)務負載具有波峰波谷時，機器資源要按照峰值需求預估；而在波谷時期機器利用率則明顯下降，因為不能進行資源復用而導致浪費。

業(yè)界普遍共識是，當自有機器的利用率小于 30%，使用 Serverless 后會有顯著的效率提升。對于云服務廠商，在具備了足夠多的用戶之后，各種波峰波谷疊加后平穩(wěn)化，聚合之后資源復用性更高。比如，外賣企業(yè)負載高峰是在用餐時期，安防行業(yè)的負載高峰則是夜間，這是受各個企業(yè)業(yè)務定位所限的；而對于一個成熟的云服務廠商，如果其平臺足夠大，用戶足夠多，是不應該有明顯的波峰波谷現(xiàn)象的。

場景二：典型用例 - 基于事件的數(shù)據(jù)處理
視頻處理的后端系統(tǒng)，常見功能需求如下：視頻轉(zhuǎn)碼、抽取數(shù)據(jù)、人臉識別等，這些均為通用計算任務，可由函數(shù)計算執(zhí)行。
開發(fā)者需要自己寫出實現(xiàn)邏輯，再將任務按照控制流連接起來，每個任務的具體執(zhí)行由云廠商來負責。如此，開發(fā)變得更便捷，并且構(gòu)建的系統(tǒng)天然高可用、實時彈性伸縮，用戶不需要關心機器層面問題。

五、Serverless 的問題
對于企業(yè)來說，支持Serverless計算的平臺可以節(jié)省大量時間和成本，同時可以釋放員工，讓開發(fā)者得以開展更有價值的工作，而不是管理基礎設施。另一方面可以提高敏捷度，更快速地推出新應用和新服務，進而提高客戶滿意度。但是Serverless不是完美的，它也存在一些問題，需要慎重應用在生產(chǎn)環(huán)境。
1、不適合長時間運行應用
Serverless 在請求到來時才運行。這意味著，當應用不運行的時候就會進入 “休眠狀態(tài)”，下次當請求來臨時，應用將會需要一個啟動時間，即冷啟動時間。如果你的應用需要一直長期不間斷的運行、處理大量的請求，那么你可能就不適合采用 Serverless 架構(gòu)。如果你通過 CRON 的方式或者 CloudWatch 來定期喚醒應用，又會比較消耗資源。這就需要我們對它做優(yōu)化，如果頻繁調(diào)用，這個資源將會常駐內(nèi)存，第一次冷啟之后，就可以一直服務，直到一段時間內(nèi)沒有新的調(diào)用請求進來，則會轉(zhuǎn)入“休眠”狀態(tài)，甚至被回收，從而不消耗任何資源。
2、完全依賴于第三方服務
當你所在的企業(yè)云環(huán)境已經(jīng)有大量的基礎設施的時候，Serverless 對于你來說，并不是一個好東西。當我們采用某云服務廠商的 Serverless 架構(gòu)時，我們就和該服務供應商綁定了，那么我們再將服務遷到別的云服務商上就沒有那么容易了。

我們需要修改一下系列的底層代碼，能采取的應對方案，便是建立隔離層。這意味著，在設計應用的時候，就需要隔離 API 網(wǎng)關、隔離數(shù)據(jù)庫層，考慮到市面上還沒有成熟的 ORM 工具，讓你既支持Firebase，又支持 DynamoDB等等。這些也將帶給我們一些額外的成本，可能帶來的問題會比解決的問題多。

3、缺乏調(diào)試和開發(fā)工具
當我使用 Serverless Framework 的時候，遇到了這樣的問題：缺乏調(diào)試和開發(fā)工具。后來，我發(fā)現(xiàn)了 serverless-offline、dynamodb-local 等一系列插件之后，問題有一些改善。然而，對于日志系統(tǒng)來說，這仍然是一個艱巨的挑戰(zhàn)。

每次你調(diào)試的時候，你需要一遍又一遍地上傳代碼。而每次上傳的時候，你就好像是在部署服務器，并不能總是快速地定位出問題在哪。后來，找了一個類似于 log4j 這樣的可以分級別記錄日志的 Node.js 庫 winston。它可以支持 error、warn、info、verbose、debug、silly 六個不同級別的日志，再結(jié)合大數(shù)據(jù)進行日志分析過濾，才能快速定位問題。
4、構(gòu)建復雜
Serverless 很便宜，但是這并不意味著它很簡單。AWS Lambda的 CloudFormation配置是如此的復雜，并且難以閱讀及編寫（JSON 格式），雖然CloudFomation提供了Template模板，但想要使用它的話，需要創(chuàng)建一個Stack，在Stack中指定你要使用的Template,然后aws才會按照Template中的定義來創(chuàng)建及初始化資源。

而Serverless Framework的配置更加簡單，采用的是 YAML 格式。在部署的時候，Serverless Framework 會根據(jù)我們的配置生成 CloudFormation 配置。然而這也并非是一個真正用于生產(chǎn)的配置,真實的應用場景遠遠比這復雜。

六、總結(jié)
云計算經(jīng)過這么多年的發(fā)展，逐漸進化到用戶僅需關注業(yè)務和所需的資源。比如，通過K8S這類編排工具，用戶只要關注自己的計算和需要的資源（CPU、內(nèi)存等）就行了，不需要操心到機器這一層。

Serverless架構(gòu)讓人們不再操心運行所需的資源，只需關注自己的業(yè)務邏輯，并且為實際消耗的資源付費?？梢哉f，隨著Serverless架構(gòu)的興起，真正的云計算時代才算到來了。

任何新概念新技術(shù)的落地，本質(zhì)上都是要和具體業(yè)務去結(jié)合，去真正解決具體問題。雖然Serverless很多地方不成熟，亟待完善。不過Serverless自身的優(yōu)越特性，對于開發(fā)者來說，吸引力是巨大的。相信隨著技術(shù)的飛速發(fā)展，Serverless在未來還有無限可能！

文章標題：通通透透看無服務器計算：由來、場景和問題
本文URL：http://aaarwkj.com/article40/pegjho.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供響應式網(wǎng)站、定制開發(fā)、Google、虛擬主機、網(wǎng)站策劃、網(wǎng)站制作

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)