本文為作者投稿，經 INSIDE 編審後刊載，原文刊載於 Medium。作者 Alex，留著商科人的血，卻喜歡接觸科技人的新鮮事，熱愛學習各種科技新知，但始終懷抱著一顆數位金融的靈魂，喜歡用淺顯易懂的比喻，來解釋複雜的科技概念，期望成為一位兼具商業思維與科技氣息的混血人。
近年來銀行因數位化的衝擊，紛紛採用微服務 (Microservice) 或 Open API 的方式進行數位轉型，這時我們不禁會好奇地在想，到底什麼是微服務？到底什麼是 Open API？他們是同一種東西嗎？兩者之間又有何關聯？，銀行為何要採行微服務或 Open API 的方式進行數位轉型？
有鑑於此，我們將用生活中飲料店的情境，來比喻 Open API 與微服務 (Microservice) 的概念，希望能幫助大家有效理解、掌握這兩者運作方式的概念與其之間的關係。
本篇文章結構如下：
- 傳統銀行系統架構所面臨的問題？
- 什麼是微服務 (Microservice)？
- 什麼是 Open API？
- 微服務 (Microservice) 與 Open API 之間的關係
一、傳統銀行系統架構所面臨的問題？
想像你今天是一位飲料店的店長，在車水馬龍的大街上經營著一家飲料店，你將店員們劃分成：「內場」與「外場」，內場人員主要負責煮茶、煮珍珠、切水果、製冰塊、搖飲料等製作飲料的任務，外場人員則負責招呼客人、客人點餐、結帳收銀、交付飲料等任務。
而傳統銀行的架構就如同這家飲料店，其架構可被拆分為「核心服務系統」與「外圍服務系統」，就如同將飲料店將服務的店員劃分成「內場」與「外場」是一樣的。
「核心服務系統」就如同飲料店的「內場」，負責提供業務可以持續營運的核心架構，好比飲料店的業務營運核心架構就是製作飲料的服務，製作飲料的服務包含：「煮茶、煮珍珠、切水果、製冰塊、搖飲料」，而銀行的業務營運核心架構則是：「存款、放款、財富管理」等金融服務項目。
「外圍服務系統」就如同飲料店的「外場」，作為連結顧客與核心系統服務間的橋樑，好比飲料店的外場人員就是負責「負責招呼客人、客人點餐、結帳收銀、交付飲料」，而銀行的外圍系統則是：「網路銀行、ATM、代收代付」等，以擴充原本銀行的金融服務內容。
但由於銀行的「核心服務系統」就如同一棟大樓的骨架一樣，不能隨意地更換樑柱，隨意的更改核心系統的架構很容易造成既有營運業務的停擺，而發生金融風險，有鑑於此，銀行為了同時能確保核心系統服務的運作，就會需要增設許多外圍系統來幫忙，但外圍系統與核心系統處理任務的資料邏輯不盡相同，因此我們會需要一個中繼站作為雙方的橋樑，就如同飲料店的外場人員使用飲料單號與內場人員傳達顧客的飲料需求一樣，這個單號就是 ETL 資料轉換工具，能讓銀行的外圍系統有效地把需求傳遞給核心系統。
由於飲料店的運作非常順利，使你的事業蒸蒸日上，然而當越來越多人前往你的飲料店來購買飲料，此時你發現了幾個問題：
- 內場人員同時要處理很多事情，假若今天在內場人員的工作項目中，新增加一個「掃地」工作，整個內場人員的服務流程勢必都要做調整。
- 由於店內總共才 3 位正職成員，1 人負責收銀，2 人負責製作飲料，然而一到中午的尖峰時刻，製作飲料的速度無法跟上來客的速度，導致飲料店常常大排長龍，但上午、下午的離峰時刻，飲料店可以有效負荷來客數，因此不可能只因為中午是巔峰時刻而多雇用一名人員。
上述這些問題就是傳統銀行系統架構遇到的問題：「高耦合、服務擴充缺乏彈性」。
高耦合為明明只是一個很小的需求異動，但會連帶影響到跟它有相依關係的部份，假若今天在內場人員的工作項目中，新增加一個「掃地」工作，整個內場人員的服務流程勢必都要做調整。
服務擴充缺乏彈性則表示，當今天一到中午的巔峰時刻，製作飲料的速度無法跟上來客的速度，導致飲料店常常大排長龍，但上午、下午的離峰時刻，飲料店可以有效負荷來客數，因此不可能只因為中午是巔峰時刻而多雇用一名正職人員，若只為了中午時刻就多雇用一位正職，那閒置的人力該如何處理？
上述情境就如同這篇新聞：「口罩實名制 2.0 網路系統擴 3 倍備戰 700 萬人次」所述，為了因應這次武漢肺炎疫情，緊急加大 3 倍主機容量備戰，第一銀行及合庫商銀擔任收款行，然而一旦疫情趨緩，這些閒置的資源該如何處理？
二、什麼是微服務 (Microservice)？
雖然目前飲料店生意興隆，但飲料店目前的「外場」與「內場」的運作機制，不論是在製作飲料或力資源調配上，都欠缺彈性的狀況下，無形中也增加了飲料營運的負擔。
於是你又陷入一陣思考的漩渦之中，忽然間你拍了一下大腿說：「我現在有一個大膽的想法！」，就是聘用數名工讀生，並將原本外場與內場的服務進行細分化，原本內場製作飲料的任務全部都是由兩個人承擔，為了提升製作飲料的效率，如今我們把內場製作飲料的流程，拆解為「備料」與「製作」，「備料」包含煮茶、煮珍珠、切水果，「製作」包含調配比例、搖飲料，外場則是把招呼客人與收銀任務拆分，讓店員們的分工更加明確。
此外先前飲料店常會因為中午尖峰時刻，而導致店員手忙腳亂，造成許多人只能在飲料店外面苦苦等候，我們可以透過聘用工讀生的方式來解決這個問題，將工讀生的上班時間劃分為早、中、晚三個時段，隨時根據飲料店的各時段的業務多寡，來配置工讀生的人力。
當你決定將飲料店的外場與內場服務拆成更細微的服務後，你發現：
- 當將原本包裹在一起的服務，切分成更細小的任務，並讓店員各司其職，加速整體飲料店營運的效率。
- 原先常因中午飲料訂單爆量，苦無多餘人力幫忙協助處理的問題，透過聘用工讀生，以彈性工時的方式，根據飲料店的各時段的業務多寡，來配置工讀生的人力，不用擔心因為多聘用一位正職人員，而造成閒置人力的情形發生。
微服務解決了傳統銀行系統架構所碰到的問題，讓每個服務應用得以：「高內聚、保持服務擴充彈性」來提供顧客金融需求。
讓我們以英國數位銀行 Monzo 管理微服務的新聞為例，新聞中有提到這間銀行的微服務架構包含兩個核心技術：Docker 與 Kubernetes (K8S)。
Container 周報第 123 期：1,600 個微服務怎麼管？英國當紅網銀 Monzo 秘訣大公開
Docker 其實是一套虛擬化的容器技術，若以運輸業來舉例，Docker 是一個貨櫃箱，裡面可以放入許多不同的貨物，如：汽車、油桶，他們可以任意被不同的運輸工具所搭載、運送，不會受限於交通工具的限制，未來發生異動時，只需更動貨櫃箱裡面的內容就好。
因此英國數位銀行 Monzo 先是以 Docker 把不同的應用程式程式(貨物)進行裝箱 (Container)，然後讓裝箱好的應用程式可以自由地在不同的平台上運行。套用飲料店的場景來比喻，Docker 就如同飲料店的業務守則，店員只要閱讀了業務守則後，就可以執行製作飲料的任務，因此業務守則不僅限於某位特定員工才能閱讀，不論是讓 A 員工或是 B 讓員工閱讀，他們理解業務守則的內容後，都能勝任調配飲料比例、與搖飲料的工作。
當我們理解什麼是 Docker 後，又會面臨一個問題，也就是我們該如何有效地管理這些店員呢？這時 Kubernetes (K8S) 就派上用場了，Kubernetes (K8S) 的架構主要分為兩層：第一層是 Master，第二層是 Node，Master 就像是大總管一樣負責管理、調派與維護這些 Node 節點，Node 節點則是負責運作與執行包含在 Node 裡面節點的任務。
同樣以飲料店的場景做比喻，當我們聘用越來越多的工讀生來協助我們完成製作飲料的任務時，由於人手變多，需要一位同仁擔任人員調度和安排工作的事宜，如同飲料店組長的角色，這位組長就是 Kubernetes (K8S) 中的 Master，而底下的正職與工讀生就是 Kubernetes (K8S) 中的 Node。
而 Kubernetes 裡面的Node，又可以被拆分成四個層次，分別為 Node、Pod、Container與 Application：
- Node：就是 Kubernetes 的運算節點，處理於平台上發生的各種需求，就如同飲料店的店員。
- Pod：則為 Kubernetes 運作的最小單位，一個 Pod 可以對應到許多的應用服務，但為了確保運行效率，一般都會以一個 Pod 對應一個應用服務來設計，就如同飲料店切水果使用的砧板，不會被拿去作為放置茶包來使用。
- Container：是一個虛擬化的容器技術，如 Docker，裡面可以被放入許多應用程式，就如同飲料店的業務守則一樣，裡面包含煮茶、煮珍珠等作法。
- Application：是一個應用程式，如 Excel，提供特定的服務應用，如切水果，就是提供後續製作水果茶的服務。
此外在 Kubernetes上，我們可以用 Cluster 群集的方式來劃分不同的微服務區塊，就如同連鎖飲料店常以服務所在的區域來劃分不同的分店，如信義敦化店、大安店等。
綜合上述我們可以理解，Kubernetes (K8S) 中的 Master 可根據目前各個 Node 的工作處理情形管理，就好比飲料的組長根據目前飲料的業務量，決定我要在切水果、煮珍珠、搖飲料還是收銀結帳等服務上做人力的增減、分配資源，讓飲料店整體的服務機制保有彈性。
此外身為店長的你，為了要確保飲料店的衛生條件有符合水準，於是你定期會邀請食品衛生人員和飲料店的衛生環境，確保顧客所購買的飲料符合一定的品質水準。這樣的審核機制，就如同 Monzo 開發了一個微服務通訊剖析 rpcmap，可以自動分析每一支 Go 語言程式，找出對 service.ledger 微服務的所有呼叫來源，來建立白名單，確保 Monzo 微服務是安全且可靠，不會隨意地被不明來源所使用。
三、什麼是 Open API？
某天你在核對這個月份的飲料店營收數字時，發現飲料店的整體經營狀況持續下滑，因此你決定要想辦法提升目前的銷售業績，於是你開始思考，原本顧客只能以透過前往飲料店的方式來購買飲料，為何不要給予顧客更多購買飲料的方式呢？當我們能讓顧客以更多元的方式取得我們的飲料，或許就能突破目前只能以單一管道購買飲料的困境，拓展我們的顧客群體，提升飲料店的業績。
當你決定引進電話點餐、外送服務、Line 線上點餐，並與點餐 app 合作 (如 Uber Eats)，讓顧客購買飲料這件事，不再僅限於實體飲料店，開放至各個服務場景之中。上述飲料店的情境就好比銀行執行 Open API 的做法，將原本所在核心系統內的金融服務資料釋放出來，延伸至各個生活場景之中，讓顧客不再僅限於經由銀行取得金融服務，亦可以透過與銀行之合作廠商的金融服務產品來滿足金融需求，就如同當銀行透過 Open API 的方式將帳戶查詢 API 開放出來時，你只要透過一個應用程式服務，如麻布記帳，就能夠快速查詢、掌握你手頭上共有多少存款餘額，不用再登入不同家的銀行 app 來查詢。
然而當你試著將購買飲料的服務向外拓展時，你發現顧客於訂購飲料時會存在兩個問題：
- 顧客所提供的資訊都很不一致，有些人只留姓名、飲料名稱，有些人留手機、飲料、甜度冰塊也沒寫。
- 當飲料店菜單做更換時，必須通知手機叫餐 app、Line 線上點餐等服務廠商，讓他們也要一併變更儲存於上面的菜單內容。
上述情境正式說明銀行在執行 Open API 所面臨的問題：「各系統儲存資料的規格不一致、當 API 資料接口發生異動時，資料規格就要一起異動」。
各系統儲存資料的規格不一致的問題，就如同顧客於訂購飲料時，所提供的資訊都很不一致，有些人只留姓名、飲料名稱，有些人留手機、飲料、甜度冰塊也沒寫，店員在接收到這些需求後，必須要種新歸納、整理，而銀行的業務是由許多不同的系統所支撐，有帳戶系統、貸款系統、財富管理系統等，這些不同的系統儲存資料的格式都不一樣，因此 IT 人員在製作一 API 程式時，必須要先將各系統上送的資料進行「抽取 (Extract)、轉換 (Transform)、上送 (Load)」的動作，也就是使用 ETL 工具執行清理、整理。
另一個面臨的問題在於：「當 API 資料接口發生異動時，資料規格就要一起異動」，API 背後是以 Oauth2.0 搭配 Restful 的方式來運作，資料傳輸的規格以 JSON 為主，當雙方定義好資料的拋送與接收方式後，API 就可以於每次被呼叫時，將定義好的所需資料傳送給對方，然而這面臨一個問題，就是當 API 資料接口發生異動時，API 的資料傳輸規格也要更著異動。就如同當飲料店菜單做更換時，必須通知手機叫餐 app、LINE 線上點餐等服務廠商，讓他們也要一併變更儲存於上面的菜單內容，缺乏服務擴充或異動彈性。
從上述的情境我們可以了解到，銀行透過 Open API 的方式，雖能有效地將封存在銀行的資料釋放出來，讓第三方合作廠商有機會使用這些資料去開發不同的金融服務與產品，然而每家銀行的 API 開發規格都不一樣，若一家新創的金融科技公司想要取用不同銀行所提供的 API 服務時，勢必要和每一家銀行個別談定資料拋轉與接收的規格，既耗時又耗力。
這時就會需要有一個統籌機構跳出說：「我們來統一開發 API 的規格吧！」，統一制定 API 開發規格，節省金融科技與各銀行間洽談、定義、開發規格的時間，就如同今天你這家飲料店決定統一訂購飲料的規格，顧客於訂購飲料時必須留下，姓名、手機、飲料名稱、甜度冰塊這四種資訊，以便於店員可以順利的製作顧客所需的飲料。
這也是為何 Open API 這件事情，大多是由政府單位發起並制定監管機制，如英國 Open API 政策是由市場管理局 (CMA) 所發起，新加坡是由新加坡金管局所發起，就如同台灣是由金管會所發起，由財金公司負責打造開放 API 平台，若是由私人銀行所發起，會造成 API 規格零碎化，無法有效地監管與拓展 Open API 的金融服務應用。
【開放銀行特別報導】財金開放 API 平臺終於上路，23 家銀行與 6 家 TSP 搶先布局，但下一階段才是更大的挑戰
四、Open API 與微服務 (Microservice)之間的關係
從生活中飲料店的情境中，我們可以了解到，微服務則是將服務應用打包成一個模組，就好比各部門都有行銷人員，每個行銷人員都要負責不同的類型的行銷任務，何不把這些各部門的行銷人員作打包，各部門不再擁有這些行銷人員，讓他們組成一個團隊，由行銷主管負責統籌、調派這些行銷人員，變成一個提供行銷服務的模組。
Open API 是一個定義好的資料傳輸、拋轉的接口，就好比台鐵窗口的售票員，你跟他說我想點一份大麥克套餐，他不會理你，但你跟他說我想要買一張台北到台中的單程票，他會很樂意為你服務。
而微服務 (Microservice) 與 Open API 兩者間並不互斥，且可以共同運作，就以行銷部門的運作為例，我們將散落於各單位的行銷人員集中管理，建立一支行銷團隊，由行銷主管統一調度這些行銷人員的工作內容，提供業務部門執行行銷活動的服務，而行銷部門的每一位成員就好比一個 API 接口，負責處理來自業務部門傳遞過來的各種訊息，業務部門丟過來的訊息可以是紙條、Email、或一通電話，行銷人員需要負責去收集、整理這些訊息，整理好後，開始執行行銷任務，而主管負責調派、管理這些行銷人員，並負責與外部廠商洽談行銷合作。
然而當某天貸款業務單位的行銷需求量突然暴增，已經超越原先負責貸款行銷任務的同仁的工作負荷量時，行銷主管趕忙將負責財富管理行銷的同仁，調派去處理貸款業務單位的行銷需求，又或是當哪天存款的行銷需求下降時，就可以縮編負責存款行銷的人員，讓行銷團隊隨時保有服務的擴充性與彈性，能夠根據目前環境的變化，及時地做出因應與調整。
我們可以從上述舉例了解，此行銷團隊就是以微服務 (Microservice) 的概念所設立，裡面所包含的行銷人員像是一個作業單位，兼負起收集業務單位的需求，並執行行銷任務，主管則是擔任管理、調派人員與負責與聯絡外部廠商洽談行銷合作，確保整個行銷團隊能正常運作。
因此不論是微服務 (Microservice) 或 Open API 的解決方案，都是希望能夠解放傳統銀行這隻笨重的大象，讓他能夠以更輕、更快的方式提供民眾多樣性的金融服務與產品，提升顧客整體的金融服務體驗與品質。
責任編輯：Chris
核稿編輯：Mia
延伸閱讀：
"飲料" - Google 新聞
March 31, 2020 at 12:05PM
https://ift.tt/2WR8tL4
【FinTech 觀點】用飲料店當例子，簡單理解微服務與 Open API ! - INSIDE 硬塞的網路趨勢觀察
"飲料" - Google 新聞
https://ift.tt/3bjfGr9
Shoes Man Tutorial
Pos News Update
Meme Update
Korean Entertainment News
Japan News Update
Bagikan Berita Ini
0 Response to "【FinTech 觀點】用飲料店當例子，簡單理解微服務與 Open API ! - INSIDE 硬塞的網路趨勢觀察"
Post a Comment