添加链接
link管理
链接快照平台
  • 输入网页链接,自动生成快照
  • 标签化管理网页链接

本堂課程作為此系列的準備課程,針對不了解 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)。
  •