本堂課程作為此系列的準備課程,針對不了解 Serverless 的人,介紹 Serverless 概念、特點以及 Open Source Serverless 平台 Apache OpenWhisk 和基於它實做的企業版本 IBM Functions 的概況。
雲端計算的發展趨勢
在課程一開始先帶我們來回顧雲端計算的發展趨勢。
雲端計算的發展趨勢(圖片來源:
課程講義
)
由圖中可以發現架構演變的趨勢,是朝著
簡單
、
便捷
與
低成本
實現
商業邏輯
(Business Logic)的方向前進。
從最開始裸機的配置與開發;接著進入 IaaS 飛速發展,在這期間以 OpenStack 為代表的社區逐漸的成長,發展出許多的雲端平台公司;到之後發展出以 docker 為代表的 containers,而使得 Kubernetes 和 Mesos 等容器調度工具廣為人知。
docker、Swarm、Kubernetes 和 Mesos
文章中所說的 docker 指的是 docker 技術本身。而一般看到的 Docker、 Kubernetes 與 Mesos 的比較文章,更有可能是比較與 Docker Swarm 比較,三者皆為容器調度工具。
三者較可閱讀:
1.
Docker、Kubernetes 和 Apache Mesos 对比中的一些误区
2.
2016年容器技术思考:Docker, Kubernetes, Mesos 将走向何方?
由發展史看可以看出,隨著一系列的發展,對底層的屏蔽是日趨增加。
在裸機的時代,開發人員還需要操心系統的設定與維護;而到了 container 階段,則是已經將執行環境抽離,消除底層系統和基礎架構差異性所帶來的問題。
換句話說,隨著對底層屏蔽的增加,使的開發人員能
專注於功能或程式本身的開發設計
,加速整個開發流程的推進。
而在最近幾年的技術中,又將粒度再次縮小,提出了所謂的 Function as a Service(FaaS),也就是 Serverless,試圖讓開發人員程從系統、運行環境、軟體相依性等複雜的環境中解脫。
什是 Serverless?
Serverless 是雲端計算 IaaS 、 PaaS 的下一個方向,但這像技術並非實現字面意上的『無伺服器』,而是由第三方雲端計算平台供應商負責後端基礎設施的維護,以服務(aaS)的方式為開發者提供所需功能,例如:認證、授權與資料庫服務等。
簡單地說,這裡所強調的『無伺服器』,指的是我們的
程式碼不會明確地被部署在某些特定的軟體或者硬體的伺服器上
,不需要在伺服器上持續執行行程以等待 HTTP 請求或 API 調用;是通過某種事件機制來觸發程式碼的執行,此時供應商才會將此服務進行部署。這樣的架構可以讓開發人員更專注程式碼的運行,而不需要分心管理任何的基礎設施。
目前已有有些這樣的服務:
由第三方供應,且無須安裝、管理和維護,只在需要的時候使用,並按照使用資源計費
。
例如實務上,有些開發人員為了更專注於商業邏輯相關程式碼的開發,會將與商業邏輯邏輯無關的部分委託給第三方,像是上述所提到的認證、授權與資料庫服務等,這些都是
Backend-as-a-Service(BaaS)
。
也有的將整個程式運行環境給託管出去的,將開發出來的函式直接放動雲端去當作服務在調用,也就是
Function-as-a-Service(FaaS)
。
這兩類型的服務都被稱作 Serverless,也都是雲端計算的發展方向。
這邊整理兩種服務的特性:
Function-as-a-Service(FaaS)
片段程式碼,按需執行、按需擴展、無需管理任何基礎設施相關部分。
事件驅動行計算。函式被事件觸發或是被 HTTP 請求調用。
Backend-as-a-Service(BaaS)
第三方基於 API 的服務,實現應用開發中的基礎功能模塊。
這些 API 像服務一樣,自動擴展,無需管理。
兩者都強調:
按需執行、按需擴展、無需管理
。這樣的模式是將軟體開發中的複雜性全部抽出,給開發人員更多的自由,並降低開發門檻;但從另一方面來說,這是將複雜性全留給雲端計算平台供應商。
Serverless 要點
Serverless 僅是一個概念,目前還沒有一個普遍公認的權威的定義,但此概念所要實現的目標表達就是:
無需管理、按需執行、按需擴展、按使用來計費
P.S. 對於按使用來計費,我有兩種理解,按調用次數或使用資源來收費,不過兩種的核心的使用了才付費,就看平台供應商的計價方式了。
至於所使用究竟是 FaaS 或 BaaS 則是次要的。但若採用的 FaaS ,對於函式還是有些要求:
為事件驅動的調用方式。
函式是無狀態、短暫的、且是有限制的,例如:所需記憶體的限制、執行時間的限制。
另外,因為 FaaS 可被 HTTP 調用,因此 API Gateway 設定也是其中的要點。
雲端計算的的目標是:期望計算資源如同水資源一樣的便捷,打開就可以享用。
按她的比喻來理解,現行的 VM 或是 containers 像是一般水龍頭,打開後除非主動關閉,不然就會 24 小時運行,即便此時無人使用,但還是會佔用資源。
而 Serverless 則像是使用了感應式水龍頭,手伸出去了,資源才會被調用執行,結束後資源就自動停用。
FaaS 與 PaaS 的比較
在第一次看到 FaaS 的觀念時,覺得它像是更專注提供某種功能的 PaaS,所以查了一下兩者的比較。
在
維基百科上
提到:
以平台即服務(PaaS)為基礎,無伺服器運算提供一個微型的架構 …
所以可以推測 FaaS 是 PaaS 的上層,但還不到 SaaS。
而在
AWS 的官方博客
上,則是有說到些兩者的差異:
啟動和停止
大部分 PaaS 應用無法針對每個請求啟動和停止整個應用,而 FaaS 生來就是為了實現這樣的目的。
兩者在維運方面最大的差異在於
縮放能力
。對於大部分 PaaS 平台,租戶依然需要考慮縮放,就算將它設置為自動縮放,依然無法在具體請求的層面上進行縮放。但是對於 FaaS 應用,這種問題完全是透明的。
快速開發/快速響應
對於使用者來說最重要的是快速響應,因為底層全部被屏蔽了,只需專注商業邏輯的開發,無需煩心操作系統、運行環境、版本相容…等問題。 借助 Serverless,或許只需要幾個小時,來完成新的實做邏輯即即可,不用再去重新配置環境。
在 Serverless 架構的中,
橫向擴展是完全自動的、有彈性的、且由平台供應商所管理
,使用者僅需支付您所需要的計算能力。
『綠色』計算
想想剛剛水龍頭的例子,就可以理解了。
對開發者友好
恩…不用管硬體配置,只要寫程式就好。這對我這個討厭配置環境的人來說,真的是非常友好 XDDD 每次配環境都會在坑裡掙扎超久的 Orz
在降低成本上包含了兩個方面,即基礎設施的成本和人員(運營/開發)的成本。
Opensource Serverless 平台 - Apache OpenWhisk
Apache OpenWhisk(圖片來源:
CNCF Cloud
)
OpenWhisk 是一個開源 FaaS 平台,現在已經脫離孵化器,是 Apache 的一個頂級項目,也在 IBM 公有雲上有做了驗證。它是一個典型的
事件驅動型
的程式編輯模型。
事件驅動顧名思義就是,事件來了才去做一件事情。以講師給的流程圖為例:
當事件源觸動觸發器後進入系統,然後在系統中通過規則的匹配去決定要觸發的動作,最終產生所需的結果。通常來說,輸入與輸出的的資料格式都是 Json。
Apache OpenWhisk 理念(圖片來源:
課程講義
)
在這邊出現了幾個詞,
觸發器 (Trigger)
、
動作 (Action)
與
規則 (Rule)
,這些詞我跟下一節的筆記整理在一起。
OpenWhisk 程式編輯模型
Apache OpenWhisk 程式編輯模型(圖片來源:
課程講義
)
觸發器 (Trigger)
觸發器可以對外界數據源,如資料庫的增刪查改、 github 上的 push、issue…等,進行對應的反應。
不過在 OpenWhisk 中觸發器僅某類別事件的具名頻道,換句話說僅是
一個名字
。觸發器要對反應特定類型事件的宣告,再藉由使用者或是透過事件來源觸發觸發器。
以資料庫更新為例,若是事件來源觸發,在 OpenWhisk 之外會有一個 Event provider,由它監聽資料庫。當 provider 監聽到更新事件時,再由它通知 Trigger 資料更新了。
Trigger(圖片來源:
課程講義
)
動作 (Action)
動作是執行某個特定動作的一段程式碼,它將會在 openwhisk 中執行。使用所選擇的語言來撰寫 Action,或者直接將 Docker 以映像檔提供執行。
Action 中什麼都可以放,諸如:計算、資料格式轉換、資料抽取、第三方 API 調用…等,程式寫的出來的都行。但必須注意的是,在 FaaS 中是
無狀態
的,不應該存在狀態的紀錄,而且
短時運行
的。在 openwhisk 中預設最長執行時間為是 5 分鐘,若超過 5 分鐘則不建議使用 Faas 執行,或是必須在要切成更小的粒度分開執行。
Action(圖片來源:
課程講義
)
動作序列 / 動作串 (Sequence)
全稱是 Action Sequence,這並不在講師的講義中,僅出現在講解過程中出現。
動作序列顧名思義,就是把一系列的動作鏈結來。它是一串按順序呼叫的動作,其中某個動作的輸出會傳遞為下一個動作的輸入,達到動作重複使用的目的。
規則 (Rule)
規則會建立觸發器與動作(序列)的關聯。每次觸發觸發器時,規則都會使用觸發事件作為輸入,並呼叫關聯的動作(序列)。使用適當的規則集時,單一觸發器事件可能會呼叫多個動作,也可能會呼叫動作以作為多個觸發程式的事件的回應。
Rule(圖片來源:
課程講義
)
套件 (Package)
就是一個集合,可能包含 action、trigger、rule…等,可以利用套件來新增與服務及事件提供者的整合。
這邊講師沒多說,不過
IBM 的名詞解釋
舉了個例子:
使用 IBM Cloudant 變更資訊來源所建立的觸發程式,會將服務配置成在每次修改文件或將其新增至 IBM Cloudant 資料庫時發動觸發程式。套件中的動作代表服務提供者可設為可用的可重複使用邏輯,如此,開發人員可以使用服務作為事件來源,以及呼叫該服務的 API。
Apache OpenWhisk 的部署方式
Apache OpenWhisk 的部署看理來很簡單,只要支援 docker 的設備都可以安裝,Apache 已將相關內容都把包成 docker image。相關配置步驟可以看這兩份官方的說明文件:
文件1
、
文件2
…不過有沒有真的這麼簡單,可能要頭洗下去才知道。
Apache OpenWhisk的部署方式(圖片來源:
課程講義
)
IBM Functions
先前提過 OpenWhisk 有在
IBM 公有雲
上有做了驗證,所以這邊講師就示範了在公有雲上的簡單操作。
建立 Action
從入口處點選
開始建立
费良宏 (2017-01-18)。
从IaaS到FaaS—— Serverless架构的前世今生
。檢自 亚马逊AWS官方博客 (2020-03-25)。
協同撰寫。
無伺服器計算
。檢自 維基百科 (2020-03-25)。
(2018-11)。
IBM Cloud Functions
。檢自 IBM Cloud 其他服務說明 (2020-03-25)。
Shashikanh (2019-07-25)。
“Hello, World” in IBM Cloud Functions vs Express Serverless Platform — A Developer’s Perspective
。檢自 IBM Cloud - Medium (2020-03-25)。
(2019-07-12)。
Cloud Functions 的運作方式 - Cloud Functions 術語
。檢自 IBM Cloud (2020-03-25)。
Linux中国 (2017-08-04)。
Docker、Kubernetes 和 Apache Mesos 对比中的一些误区
。檢自 Linux 开源评论 - 知乎 (2020-03-25)。
jolestar (2017-02-17)。
2016年容器技术思考:Docker, Kubernetes, Mesos 将走向何方?
。檢自 午夜咖啡 (2020-03-25)。
Abel Avram,大愚若智 譯 (2016-06-26)。
FaaS、PaaS 和无服务器体系结构的优势
。檢自 infoq (2020-03-27)。
Get hands-on experience with Serverless Computing using IBM Cloud Functions
。檢自 IBM Developer (2020-03-27)。
1
雲端計算的發展趨勢
-
1.1
什是 Serverless?
-
1.2
Serverless 要點
-
1.3
FaaS 與 PaaS 的比較
-
1.4
Serverless 架構的優點
2
Opensource Serverless 平台 - Apache OpenWhisk
-
2.1
OpenWhisk 程式編輯模型
-
2.2
Apache OpenWhisk 的部署方式
3
IBM Functions
-
3.1
建立 Action
-
3.2
建立 Trigger
4
其他連結
5
參考資料