再論微服務

文 / 劉虹君

以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整體的服務機制保有彈性。

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