由雲端服務的環境來提供事件驅動運算平臺的應用,逐漸有崛起之勢。去年,首先由AWS推出了強調可做到無伺服器應用的Lambda,今年起,Google、IBM陸續加入戰局,2月11日Google發布了Cloud Functions的Alpha版;同月22日,IBM Bluemix也宣布即將推出OpenWhisk,這套平臺可根據不同事件,或是直接透過網頁應用、行動App、其他端點裝置,來執行應用程式邏輯的反應。

有了OpenWhisk,開發者只需要處理動作的內容,以及當特定事件發生時,所要執行的動作。而這些動作本身,可以是一小段的JavaScript程式碼片段、Swift程式碼,或是嵌在Docker container裡面的二進位程式(binary programs)。

部署與執行OpenWhisk的動作,也相當快速,只要事件觸發器啟動,即可開始進行,無需架設叢集或伺服器。

當應用系統面對各種已知、可能會發生的情況,開發者都希望能夠做到自動因應,但可能需要手動執行許多工作。首先,要設法產生更多臺伺服器,並且規畫所需的資源容量;接著,需要安裝、設定與更新應用伺服器,並設定網路;然後,開始部署微服務,以及設定擴展規模機制,確保系統的高可用性;最後,我們需要設定事件記錄與監控,以及建立伺服器、應用伺服器與整體環境的安全性弱點修補計畫。

相對地,這些也是運用事件驅動運算平臺的最大價值,能夠幫忙應變,並省去各種事前、事中、事後的處理作業。

OpenWhisk的基本使用架構

OpenWhisk的事件來源,主要是Bluemix services或外部的services,而執行的動作則是來自開發者以偏好語言寫成的程式碼,或是Docker container裡面所嵌入的二進位程式(binary programs)。一旦特定事件觸發器(Trigger)啟動後,即可快速部署與執行當中的程式碼。而且,開發者還可以在觸發器上,綁定指定的規則以便執行應有的動作。

同時,由於OpenWhisk執行動作的頻率,持續配合觸發器啟動的頻率,因此可擴展執行規模。換言之,有越多觸發器啟動,就會有越多動作執行;所以,如果沒有觸發器啟動,就不會執行動作相關的程式碼,所以也不隨隨便便耗用IT基礎架構的資源。

此外,資源不再需要回復到足以執行程式的狀態,因此也沒有相關的成本負擔。相較之下,需長期、持續執行的虛擬機器或container,就必須部署多個虛擬機器或container,透過產生多臺伺服器的方式來分攤負載,以紓解單一執行實例用盡資源的情況。

OpenWhisk提供分散式運算服務,可在各種事件發生時,執行指定的應用程式邏輯,做出反應。
這套服務的架構包含幾個重要元件:

    事件觸發器(Trigger)是指由不同情況所產生的事件類型。

    動作(Action),可將實際的程式碼封裝成可執行的狀態。這當中支援多種程式語言,可綁定Node.js、Swift,以及任何一種封裝在Docker Container環境內的二進位程式。而當中,可執行的動作,運用到任何開放的生碳系統,舉凡Bluemix services裡面的分析、資料處理、認知處理,或是第三方的services。

    規則(Rule)是指事件觸發器與動作之間的結合。

    套件(Package)是統一描述外部services的方式。

將這些結合起來之後,開發者可以運用現代的抽象化與串連等處理機制,來組裝出所需的應用程式,而這些機制,能透過命令列的方式來建立、存取、更新與刪除。若要更方便地採用相關的措施,可透過特定的軟體開發套件,例如OpenWhisk iOS SDK。

 

在OpenWhisk可執行的動作類型

OpenWhisk執行動作的方式也相當特別,對於應用程式分解成多個小型建構模塊(building blocks)來執行的作法——也就是目前相當流行的微服務(microservices),OpenWhisk動作可以在其中執行,而且,基礎架構的成本不會隨著執行的建構模塊數量增加,提高。事實上,它允許任何粒度層級的分解,只會在呼叫各自的微服務時,會產生執行時期的成本。

有了OpenWhisk這類型服務,開發者可以更專心於程式碼的處理上,而不需要針對監控、漏洞修補,或底層系統、儲存、網路的防護等日常維護作業,耗費心思。

而且,由於OpenWhisk的動作程式碼是獨立執行,而且相當輕量,因此開發者能同時建立建構模塊的儲存庫,以便重複使用各種組合方式上,而不需要額外的基礎架構成本。

此外,對於與觸發器相關的動作,我們可以透過OpenWhisk 提供的API、CLI或iOS SDK來直接執行。而且,不論是透過事件觸發器或直接呼叫,開發者都可以依序串接不同的動作,OpenWhisk動作順序或連鎖反應,能以最少甚至不用程式碼,即可產生複雜的動作結果。

 

若要使用命令列介面來執行OpenWhisk的動作,Bluemix提供OpenWhisk CLI的輔助操作說明,增加開發者上手的速度。

若要在OpenWhisk建立動作,目前原生支援的程式語言是Node.js和Swift,以後者來說,許多iOS平臺的App開發者可藉此運用本身既有的開發技巧,來實作伺服器端的程式邏輯,而不需要顧慮維護作業的進行,也因此能更聚焦在開發行動App的工作上。

在Bluemix的網頁介面上,開發者可直接定義動作、事件觸發器與規則的作業方式。

開發者也可在此建立較複雜的自動化步驟,並設定在動作和事件觸發器上。

若要分析事件驅動作業在不同時間下的成效與執行結果,也可透過Bluemix的網頁介面來進行,這樣的功能有助於動作與事件觸發器的設計與最佳化。

可運用套件封裝的方式擴充,增加使用彈性

若要擴充使用功能,OpenWhisk也能透過套件封裝(Package)的方式,來增加服務與事件供應器。一個OpenWhisk套件包含的元件,主要有:進料器(feed)、動作(action)。每個進料器是一段程式碼,能夠設定事件觸發器的啟動,而事件觸發器(例如NoSQL資料庫裡面發生記錄變更的情況)的建立方式,則需要事件觸發器類型的指定,也就是進料器。一個封裝好的OpenWhisk動作本身就是一個可移植的邏輯操作,服務供應商可以透過這種方式,讓開發者能夠將OpenWhisk動作用於服務之中,作為事件來源,或是當做API呼叫服務的目標。如此一來,開發者不需建構用戶端邏輯動作,可節省負擔。

舉例來說,若有一個旅遊照片的應用系統,開發者只需撰寫圖片套用清晰化效果的程式碼,然後上傳到OpenWhisk、建立動作,並且設定成當資料庫回報有人上傳圖片到系統中,就自動觸發上述圖片處理的動作,執行起來相當簡單,不需要仰賴後端伺服器虛擬機器或是container,因此沒有系統狀態回復的相關成本。

產品資訊

●原廠:IBM(02)8723-8888

●建議售價:廠商未提供

●支援程式語言:Node.js、Swift

●預設套件支援的內部與外部服務:Watson、Cloudant、The Weather 、Company、Watson、Slack、GitHub等

●動作直接呼叫管道:OpenWhisk API、OpenWhisk CLI、OpenWhisk  iOS SDK

 

 

 


Advertisement

更多 iThome相關內容