通通透透看無伺服器計算:由來、場景和問題

天翼雲開發者社群發表於2023-03-16

本文分享自天翼雲開發者社群 @《通通透透看無伺服器計算:由來、場景和問題 》,作者: 我是小朋友

連結:

https://www.ctyun.cn/developer/article/358337908473993?track=|cp:cz_bk|tgdy:wenzhang|ttjh:bokeshequ|key:bw303|pf:PC

 

一、 無伺服器( Serverless)計算是什麼

 

雲端計算湧現出很多改變傳統 IT架構和運維方式的新技術,比如虛擬機器、容器、微服務,無論這些技術應用在哪些場景,降低成本、提升效率是雲服務永恆的主題。過去十年來,我們已經把應用和環境中很多通用的部分變成了服務。Serverless的出現,帶來了跨越式變革。Serverless把主機管理、作業系統管理、資源分配、擴容,甚至是應用邏輯的全部元件都外包出去,把它們看作某種形式的商品——廠商提供服務,我們掏錢購買。過去是“構建一個框架執行在一臺伺服器上,對多個事件進行響應”,Serverless則變為“構建或使用一個微服務或微功能來響應一個事件”,做到當訪問時,調入相關資源開始執行,執行完成後,解除安裝所有開銷,真正做到按需按次計費。這是雲端計算向縱深發展的一種自然而然的過程。


Serverless是一種構建和管理基於微服務架構的完整流程,允許你在服務部署級別而不是伺服器部署級別來管理你的應用部署。它與傳統架構的不同之處在於,完全由第三方管理,由事件觸發,存在於無狀態(Stateless)、暫存(可能只存在於一次呼叫的過程中)計算容器內。構建無伺服器應用程式意味著開發者可以專注在產品程式碼上,而無須管理和操作雲端或本地的伺服器或執行時。Serverless真正做到了部署應用無需涉及基礎設施的建設,自動構建、部署和啟動服務。


國內外的各大雲廠商 Amazon、微軟、Google、IBM、阿里雲、騰訊雲、華為雲相繼推出Serverless產品,Serverless也從概念、願景逐步走向落地,在各企業、公司應用開來。

 

二、 理解 Serverless技術---FaaS和BaaS

Serverless由開發者實現的服務端邏輯執行在無狀態的計算容器中,它由事件觸發, 完全被第三方管理,其業務層面的狀態則被開發者使用的資料庫和儲存資源所記錄。

Serverless涵蓋了很多技術,分為兩類:FaaS和BaaS。

1)Function-as-a-Service (FaaS)

• 小段程式碼,按需執⾏,按需擴充套件,無需管理任何基礎實施相關的部分。

• 事件驅動型計算。函式被事件觸發或者被HTTP請求呼叫。

2)Backend-as-a-Service (BaaS)

• 第三方基於API的服務,實現應用開發中的基礎功能模組。

• 這些API像服務一樣,自動擴充套件,無需管理。

 

1.Faas

FaaS意在無須自行管理伺服器系統或自己的伺服器應用程式,即可直接執行後端程式碼。其中所指的伺服器應用程式,是該技術與容器和PaaS(平臺即服務)等其他現代化架構最大的差異。


FaaS可以取代一些服務處理伺服器(可能是物理計算機,但絕對需要執行某種應用程式),這樣不僅不需要自行供應伺服器,也不需要全時執行應用程式。


FaaS產品不要求必須使用特定框架或庫進行開發。在語言和環境方面,FaaS函式就是常規的應用程式。例如AWS Lambda的函式可以透過Javascript、Python以及任何JVM語言(Java、Clojure、Scala)等實現。然而Lambda函式也可以執行任何捆綁有所需部署構件的程式,因此可以使用任何語言,只要能編譯為Unix程式即可。FaaS函式在架構方面確實存在一定的侷限,尤其是在狀態和執行時間方面。


在遷往 FaaS的過程中,唯-一需要修改的程式碼是“主方法/啟動”程式碼,其中可能需要刪除頂-級訊息處理程式的相關程式碼(“訊息監聽器介面”的實現),但這可能只需要更改方法簽名即可。在FaaS的世界中,程式碼的其餘所有部分(例如向資料庫執行寫入的程式碼)無須任何變化。


相比傳統系統,部署方法會有較大變化 – 將程式碼上傳至FaaS供應商,其他事情均可由供應商完成。目前這種方式通常意味著需要上傳程式碼的全新定義(例如上傳zip或JAR檔案),隨後呼叫一個專有API發起更新過程。


FaaS中的函式可以透過供應商定義的事件型別觸發。對於亞馬遜AWS,此類觸發事件可以包括S3(檔案)更新、時間(計劃任務),以及加入訊息匯流排的訊息(例如Kinesis)。通常你的函式需要透過引數指定自己需要繫結到的事件源。


大部分供應商還允許函式作為對傳入 Http請求的響應來觸發,通常這類請求來自某種該型別的API閘道器(例如AWS API閘道器、Webtask)。

 

2.Baas

BaaS(Backend as a Service,後端即服務)是指我們不再編寫或管理所有服務端元件,可以使用領域通用的遠端元件(而不是程式內的庫)來提供服務。理解BaaS,需要搞清楚它與PaaS的區別。

首先 BaaS並非PaaS,它們的區別在於:PaaS需要參與應用的生命週期管理,BaaS則僅僅提供應用依賴的第三方服務。典型的PaaS平臺需要提供手段讓開發者部署和配置應用,例如自動將應用部署到Tomcat容器中,並管理應用的生命週期。BaaS不包含這些內容,BaaS只以API的方式提供應用依賴的後端服務,例如資料庫和物件儲存。BaaS可以是公共雲服務商提供的,也可以是第三方廠商提供的。其次從功能上講,BaaS可以看作PaaS的一個子集,即提供第三方依賴元件的部分。

 

BaaS服務還允許我們依賴其他人已經實現的應用邏輯。對於這點,認證就是一個很好的例子。很多應用都要自己編寫實現註冊、登入、密碼管理等邏輯的程式碼,而對於不同的應用這些程式碼往往大同小異。完全可以把這些重複性的工作提取出來,再做成外部服務,而這正是Auth0和Amazon Cognito等產品的目標。它們能實現全面的認證和使用者管理,開發團隊再也不用自己編寫或者管理實現這些功能的程式碼。

 

三、 無伺服器( Serverless)計算如何工作?

與使用虛擬機器或一些底層的技術來部署和管理應用程式相比,無伺服器計算提供了一種更高-級別的抽象。因為它們有不同的抽象和 “觸發器”的集合。


拿計算來講,這種抽象有一個特定函式和抽象的觸發器,它通常是一個事件。以資料庫為例,這種抽象也許是一個表,而觸發器相當於表的查詢或搜尋,或者透過在表中做一些事情而生成的事件。


比如一款手機遊戲,允許使用者在不同的平臺上為全球頂-級玩家使用高分數表。當請求此資訊時,請求從應用程式到 API介面。API介面或許會觸發AWS的Lambda函式,或者無伺服器函式,這些函式再從資料庫表中獲取到資料流,返回包含前五名分數的一定格式的資料。


一旦構建完成,應用程式的功能就可以在基於移動和基於 Web 的遊戲版本中重用。

這跟設定伺服器不同,不是必須要有 Amazon EC2例項或伺服器,然後等待請求。環境由事件觸發,而響應事件所需的邏輯只在響應時執行。這意味著,執行函式的資源只有在函式執行時被建立,產生一種非常高效的方法來構建應用程式。

 

四、 無伺服器( Serverless)適用於哪些場景?

 

在現階段, Serverless主要應用在以下幾個場景。首先在Web及移動端服務中,可以整合API閘道器和Serverles服務構建Web及移動後端,幫助開發者構建可彈性擴充套件、高可用的移動或 Web後端應用服務。在IoT場景下可高效的處理實時流資料,由裝置產生海量的實時資訊流資料,透過Serverles服務分類處理並寫入後端處理。另外在實時媒體資訊內容處理場景裡,使用者上傳的音影片到物件儲存OBS,透過上傳事件觸發多個函式,分別完成高畫質轉碼、音訊轉碼等功能,滿足使用者對實時性和併發能力的高要求。無伺服器計算還適合於任何事件驅動的各種不同的用例,這包括物聯網,移動應用,基於網路的應用程式和聊天機器人等。這裡簡單說兩個場景,方便大家思考。


場景一:應用負載有顯著的波峰波谷

Serverless 應用成功與否的評判標準並不是公司規模的大小,而是其業務背後的具體技術問題,比如業務波峰波谷明顯,如何實現削峰填谷。一個公司的業務負載具有波峰波谷時,機器資源要按照峰值需求預估;而在波谷時期機器利用率則明顯下降,因為不能進行資源複用而導致浪費。

 

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

 

場景二:典型用例 - 基於事件的資料處理

影片處理的後端系統,常見功能需求如下:影片轉碼、抽取資料、人臉識別等,這些均為通用計算任務,可由函式計算執行。

開發者需要自己寫出實現邏輯,再將任務按照控制流連線起來,每個任務的具體執行由雲廠商來負責。如此,開發變得更便捷,並且構建的系統天然高可用、實時彈性伸縮,使用者不需要關心機器層面問題。

 

五、 Serverless 的問題

對於企業來說,支援 Serverless計算的平臺可以節省大量時間和成本,同時可以釋放員工,讓開發者得以開展更有價值的工作,而不是管理基礎設施。另一方面可以提高敏捷度,更快速地推出新應用和新服務,進而提高客戶滿意度。但是Serverless不是完美的,它也存在一些問題,需要慎重應用在生產環境。


1、不適合長時間執行應用

Serverless 在請求到來時才執行。這意味著,當應用不執行的時候就會進入 “休眠狀態”,下次當請求來臨時,應用將會需要一個啟動時間,即冷啟動時間。如果你的應用需要一直長期不間斷的執行、處理大量的請求,那麼你可能就不適合採用 Serverless 架構。如果你透過 CRON 的方式或者 CloudWatch 來定期喚醒應用,又會比較消耗資源。這就需要我們對它做最佳化,如果頻繁呼叫,這個資源將會常駐記憶體,第一次冷啟之後,就可以一直服務,直到一段時間內沒有新的呼叫請求進來,則會轉入“休眠”狀態,甚至被回收,從而不消耗任何資源。


2、完全依賴於第三方服務

當你所在的企業雲環境已經有大量的基礎設施的時候, Serverless 對於你來說,並不是一個好東西。當我們採用某雲服務廠商的 Serverless 架構時,我們就和該服務供應商繫結了,那麼我們再將服務遷到別的雲服務商上就沒有那麼容易了。

 

我們需要修改一下系列的底層程式碼,能採取的應對方案,便是建立隔離層。這意味著,在設計應用的時候,就需要隔離 API 閘道器、隔離資料庫層,考慮到市面上還沒有成熟的 ORM 工具,讓你既支援Firebase,又支援 DynamoDB等等。這些也將帶給我們一些額外的成本,可能帶來的問題會比解決的問題多。

 

3、缺乏除錯和開發工具

當我使用 Serverless Framework 的時候,遇到了這樣的問題:缺乏除錯和開發工具。後來,我發現了 serverless-offline、dynamodb-local 等一系列外掛之後,問題有一些改善。然而,對於日誌系統來說,這仍然是一個艱鉅的挑戰。

 

每次你除錯的時候,你需要一遍又一遍地上傳程式碼。而每次上傳的時候,你就好像是在部署伺服器,並不能總是快速地定位出問題在哪。後來,找了一個類似於 log4j 這樣的可以分級別記錄日誌的 Node.js 庫 winston。它可以支援 error、warn、info、verbose、debug、silly 六個不同級別的日誌,再結合大資料進行日誌分析過濾,才能快速定位問題。


4、構建複雜

Serverless 很便宜,但是這並不意味著它很簡單。AWS Lambda的 CloudFormation配置是如此的複雜,並且難以閱讀及編寫(JSON 格式),雖然CloudFomation提供了Template模板,但想要使用它的話,需要建立一個Stack,在Stack中指定你要使用的Template,然後aws才會按照Template中的定義來建立及初始化資源。

 

Serverless Framework的配置更加簡單,採用的是 YAML 格式。在部署的時候,Serverless Framework 會根據我們的配置生成 CloudFormation 配置。然而這也並非是一個真正用於生產的配置,真實的應用場景遠遠比這複雜。

 

六、總結

雲端計算經過這麼多年的發展,逐漸進化到使用者僅需關注業務和所需的資源。比如,透過 K8S這類編排工具,使用者只要關注自己的計算和需要的資源(CPU、記憶體等)就行了,不需要操心到機器這一層。

 

Serverless架構讓人們不再操心執行所需的資源,只需關注自己的業務邏輯,並且為實際消耗的資源付費。可以說,隨著Serverless架構的興起,真正的雲端計算時代才算到來了。

 

任何新概念新技術的落地,本質上都是要和具體業務去結合,去真正解決具體問題。雖然 Serverless很多地方不成熟,亟待完善。不過Serverless自身的優越特性,對於開發者來說,吸引力是巨大的。相信隨著技術的飛速發展,Serverless在未來還有無限可能!

————————————————

版權宣告:本文為 CSDN博主「weixin_34124939」的原創文章,遵循CC 4.0 BY-SA版權協議,轉載請附上原文出處連結及本宣告。

原文連結: https://blog.csdn.net/weixin_34124939/article/details/85017690

 


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70014251/viewspace-2940054/,如需轉載,請註明出處,否則將追究法律責任。

相關文章