財經

以Coffee Shop 來比喻微服務

文 / 劉虹君

疫情之下許多企業紛紛進行數位轉型,微服務是其中最火的一項。用生活中Coffee shop的情境,來比喻微服務,幫助大家有效理解、掌握微服務運作方式的概念。

銀行傳統系統架構所面臨的問題及微服務進駐運作模式,想像你今天是一位Coffee shop的店長,在喧鬧的東區經營著一家Coffee shop,店內員工分成內外場。內場人員負責簡餐製作、咖啡飲料製作等。外場人員則負責招呼客人、客人點餐、結帳收銀、送餐等任務。

而金融行業傳統系統的架構就如同這Coffee shop,其架構分為「核心服務系統」與「外圍服務系統」。Coffee shop 的內場人員負任務如同銀行的「核心服務系統」。Coffee Shop 的外場人員負責任務如同銀行的「外圍服務系統」。

核心服務系統與外圍服務系統 相輔相成

銀行的「核心服務系統」為負責提供業務可以持續營運的核心架構,好比Coffee shop的業務營運核心架構就是負責簡餐製作、咖啡飲料製作、準備食材等,而銀行的業務營運核心架構則是:「存款、放款、財富管理」等金融服務項目。

銀行的「外圍服務系統」為連結顧客與核心系統服務間的橋樑,好比Coffee Shop的外場人員就是負責「負責招呼客人、客人點餐、結帳收銀、送餐」,而銀行的外圍系統則是:「網路銀行、ATM、代收代付」等,以擴充原本銀行的金融服務內容。

銀行的「核心服務系統」就像大樓的樑柱,不能隨意地變動,隨意的更改核心系統的架構很容易造成既有營運業務的停擺,發生金融風險,因此,銀行為了同時能確保核心系統服務的運作,就會增設一些外圍系統來幫忙,但外圍系統與核心系統處理任務的資料邏輯不同,所以我們會需要一個中繼站作為雙方的橋樑,就如同Coffee shop的外場人員使用訂餐單號與內場人員傳達顧客的用餐需求一樣,這個訂餐單號(Coffee shop 的訂單系統)就是銀行的中台,能讓銀行的外圍系統有效地把需求傳遞給核心系統。

當Coffee shop的營運非常順利,越來越多人前往你的店來購買或用餐,此時你發現了幾個問題:

一、內場人員同時要處理很多事情,假若今天在內場人員的工作項目中,新增加一個「清潔」工作,整個內場人員的服務流程勢必都要做調整。

二、由於店內總共才 三位正職成員,一人負責收銀,二人負責製作餐飲,然而一到中午的尖峰時刻,製作食物的速度無法跟上來客的速度,導致店內常常大排長龍,若為了中午巔峰時刻就多雇用一位正職,那閒置的人力該如何處理?

上述這些問題就是傳統銀行系統架構遇到的問題:「高耦合、服務擴充缺乏彈性」。

什麼是微服務

雖然目前Coffee Shop生意興隆,但店內目前的「外場」與「內場」的運作機制,不論是在製作餐飲食物或人力資源調配上,都欠缺彈性的狀況下,無形中也增加了營運的負擔。

或許你會想到可以聘用數名工讀生,將原本外場與內場的服務進行細分化,原本內場製作餐點和飲料的任務全部都是由兩個人承擔,為了提升製作簡餐和飲料的效率,把內場流程,拆解為「備料」與「製作」,「備料」包含準備食材、切菜、水果,「製作」包含調配飲料比例、煮咖啡和餐點,外場則是把招呼客人與收銀任務拆分,讓店員們的分工更加明確。

而中午尖峰時刻也可以透過聘用工讀生的方式來解決這個問題,將工讀生的上班時間劃分為早、中、晚三個時段,隨時根據Coffee shop的各時段的業務多寡,來配置工讀生的人力。

當你決定將店內的外場與內場服務拆成更細微的服務後,會發現原本包裹在一起的服務,切分成更細小的任務,並讓店員各司其職,加速整體Coffee shop營運的效率。而原先常因中午訂單爆量,透過聘用工讀生,以彈性工時的方式,根據店內各時段的業務多寡來配置人力。

微服務解決了傳統銀行系統架構所碰到的問題,讓每個服務應用得以:「高內聚、保持服務擴充彈性」來提供顧客金融需求。

以英國數位銀行 Monzo 管理微服務的新聞為例,新聞中有提到這間銀行的微服務架構包含兩個核心技術:Docker 與 Kubernetes (K8S)。Docker 其實是一套虛擬化的容器技術,套用Coffee shop的場景來比喻,Docker 就如同Coffee Shop的業務守則,店員只要閱讀了業務守則後,就可以執行製作餐飲任務,他們理解業務守則的內容後,都能勝任調配飲料比例、與製作簡餐的工作。

當我們理解什麼是 Docker 後,又會面臨一個問題,也就是我們該如何有效地管理這些店員呢?這時 Kubernetes (K8S) 就派上用場了,Kubernetes (K8S) 的架構主要分為兩層:第一層是 Master,第二層是 Node,Master 就像是大總管一樣負責管理、調派與維護這些 Node 節點,Node 節點則是負責運作與執行包含在 Node 裡面節點的任務。

微服務具有彈性可調配

同樣以Coffee Shop的場景做比喻,當我們聘用越來越多的工讀生來協助我們完成製作餐飲的任務時,由於人手變多,需要一位同仁擔任人員調度和安排工作的事宜,如同店長的角色,這位店長就是 Kubernetes (K8S) 中的 Master,而底下的正職與工讀生就是 Kubernetes (K8S) 中的 Node。

而 Kubernetes 裡面的Node,又可以被拆分成四個層次,分別為Node、Pod、Container與 Application:

1. Node:就是 Kubernetes 的運算節點,處理於平台上發生的各種需求,就如同Coffee Shop的店員。

2. Pod:則為 Kubernetes 運作的最小單位,一個 Pod 可以對應到許多的應用服務,但為了確保運行效率,一般都會以一個 Pod 對應一個應用服務來設計,就如同Coffee Shop製作咖啡的咖啡機,不會被拿去作為煮熱水或擺飾來使用。

3. Container:是一個虛擬化的容器技術,如 Docker,就如同Coffee Shop的業務守則一樣,裡面包含煮餐點、製作飲料等作法。

4. Application:是一個應用程式,如 Excel,提供特定的服務應用,如切水果,就是提供後續製作Coffee shop的水果茶的服務。

綜合上述我們可以理解,Kubernetes (K8S) 中的 Master 可根據目前各個 Node 的工作處理情形管理,就好比Coffee Shop的店長根據目前店內的業務量,決定我要在內場服務還是外場等服務上做人力的增減、分配資源,讓Coffee Shop整體的服務機制保有彈性。

微服務是近年來備受關注的話題,尤其是當國外的一些知名技術公司成功實踐了微服務以後,這股熱潮就吹遍了國內的大街小巷,我們也看到很多的專案使用了微服務。

延伸閱讀

Back to top button