關於Microservices（微服務）的介紹和想法

本週寫的題目是Microservices，跟上兩周寫的Cloud及Open API也很有關連。要了解Microservices，首先要先了解 Service-Oriented Architecture (SOA)。

傳統我們認識的系統，尤其是back-end 的平台，大多都以一個整體形式出現 (monolithic application)，所有無論是產品定義，業務邏輯，流程，審批，UI，static data，parameters，報表，統統都放在一個平台之上。以銀行作為例子，一般的核心系統，財資系統，理財產品平台等，都以這種形式出現。後來系統慢慢演變，為了更有效分工管理，同步開發，系統裏出現了modular-base的概念，基礎可以分成不同的module，由不同團隊營運，但原則上還是一整個系統。

SOA是互聯網世界的產物，原理是把原身為整體系統的各項功能，變為獨立個體，並且可分散到網絡上不同地方，以web services 形式在網絡上互通。

SOA 其中一個最大好處是將application layer 從platform 獨立出來，以往我們在整體系統上，無論怎麼應用modular concept，始終application 選定了某個平台，就要整體放在同一平台上。盡量選擇一個平台獲得最大好處，但也要容忍一些不是太好的地方，在SOA容許各項功能分為獨立個體，代表這些獨立個體可以各自建立在最適合的平台，實際各自實施方法並不太重要，只要大家符合同一套Architecture，並提供API互通即可，這提供了一個機會供各個個體獨立持續開發。

SOA另一好處是可以建立一些公用service，有好些服務是很多系統都需要，但以往的做法是各自做，浪費了很多資源。用一個很簡單的例子，比如一個服務就是查詢某一日是否公眾假期，在銀行的世界裏，可以說幾乎每一個後台系統也要儲 holiday table。另一個常見例子則是用戶職級權限，也是定義在各個系統上。SOA 原則上可以提供獨立統一接口供其它service 使用，減少重覆開發甚至參差不齊的情況。

SOA以Web Services 為基礎，可更容易與Open API或其它API management 平台對接，是本欄一直推崇的未來系統協作模式。

初步講了SOA後回到Microservices，Microservices 是SOA 其中較特殊的一種，在SOA 的要求之上，更加著重 lightweight，分工更加精細，之前提一中土弓Cloud 所著重的 Scalability，其中一個重要先決條件就是Service lightweight，容易Scale up/down，而Microservices 正符合這個要求。

不過要實施 Microservices 也還有不少問題要解決。其一是Service 分得太散，系統容易失去整體視圖，亦更難去解構service 之間的關連性，需要更有系統的辦法管理。另外不同service由不同團隊負責，也會出現像人員分配的問題，需要防止多人做同樣的工作，或有工作跌入灰色地帶。而且還有network latency 的問題，試想一個program，要做任何事也要找其它service 幫忙，技術上可行但恐怕等候時間太長。

原則上，目前並沒有一個統一的說法，究竟有多lightweight 才算是Microservices。一般來說，lightweight 的目標為容易scale up，但也要考慮以上的各點。不過在現階段，即使沒有真正或全面的Microservices，至少我們可以先向SOA過渡，例如先把公用service 分拆成獨立個體，減少資源浪費。

另外也可以考慮是把一些周邊module 分拆，好處是可先為現有系統功能減磅，而不影響核心業務。始終業務也需要持續營運，如果選擇big band 方案綑綁一次搬遷到SOA架構的方案，項目需時太長會很難支持新增業務，遷移風險也頗大。