[DevOps] 維運日記 -3 我也要來碗 Micro-service

I caught a code

Published in

I Caught a Code

9 min readOct 12, 2022

一些觀念的釐清

前言

大約在進入公司三個月左右，工作上開始遇到單體式架構慢慢遷移為微服務架構的階段，我在這階段的工作是將已存在的功能慢慢抽出解耦，自成一個 service，單獨佈署到 k3s cluster 中。於是我也開始好奇，之前我常常把微服務跟分散式系統搞混，兩者是一樣的東西嗎？還是微服務是基於分散式系統而發展出的一種架構呢？

這篇就用我的筆記來探討一下兩者的差異

什麼是分散式系統

分散式系統 (distributed system) 是由一組電腦（也可以是一群軟/硬體的節點）所組成，彼此間以通訊技術傳遞或同步訊息，透過資源交換、互相合作來完成一個共同的目標。它的相反是集中式系統 (centralized controlled system)，所有的組件都由一個統一的邏輯單位做控制與處理，資源也集中一處，最著名的例子是 IBM 的大型主機 Mainframe。

想像一個學校要舉辦園遊會，如果全部的事務都只能經過校長同意（集中式），那麼校長就有處理不完的事情，且時間資源有限，每件都是同一人審核，事情都不用做了。若校長某天請假，那麼整個活動籌備就停擺，後面的事情也都不用做了。

若讓學校不同處室各自處理任務（分散式），互相交換進度，那麼不只能夠減少校長的負擔，事情也能減少延遲、同步推行，有人請假有人遞補，最後園遊會也能因為各部會的分工而更有效率地完成。

對我來說，分散式系統就像是這樣的概念。

分散式系統的例子

Networks
Telecommunication networks
Distributed Real-time Systems
Parallel Processing

分散式系統特色

資源共享：不同節點之間可以共享軟硬體資源或數據，也能互相溝通
同步處理：多個節點能夠同步運行同一功能，不影響彼此
擴展性：當運算或效能的需求增加，分散式系統就能夠很輕易地透過增加機器，進行水平擴展
容錯率高：由於資料分佈在多個地方、且有拷貝，當一台機器或整個通訊網路掛掉時，也不至於影響到整體行為
承載量大：透過負載平衡，資源能被有效利用，流量能夠分散不造成單一節點崩潰
低延遲：將節點就近佈署，減少數據傳輸的實體距離，來達到低延遲

它要解決什麼問題

分散式系統最主要的任務是避免效能瓶頸 (bottleneck) 或單點故障 (single point of failure)。

當系統的規模小、流量不大、功能簡單時，一般的集中式系統尚可應付。一旦業務需求變多、商業邏輯更複雜、流量更大時，因任何業務邏輯都只透過中心處控制與進出，容易造成阻塞延遲 (network congestion and delay)、資源分配不均的問題，資料集中一處，丟失風險大。更麻煩的是，往往一個功能壞掉，整個系統便停擺。

為了解決對於中心控制或儲存單位的過度依賴，人們開始將系統拆分，透過訊息傳遞了解共同任務，各自運算將結果整合送出，這也是後來的雲端服務的基礎。

因此分散式系統是基於擴展數量及便利性而生的一種架構。

缺點/trade-offs

當系統架構變得過度複雜，即使以節點為單位來管理，在維護上也會形成重大的挑戰，要如何去統整、管理這些系統也是重要的課題。

由於分佈在多臺伺服器上，故障排除和診斷問題難度較高。
開放式系統的特性讓分散式計算機系統存在著資料的安全性和共享的風險問題。
不同機器間的傳輸，在資料的一致性上也難以維護。
通訊網路的安全性和保密性，資料安全的問題。
水平分佈的機器多，通訊成本高昂

Complexity v.s, Performance

一個好的分散式系統架構，應該需要更嚴謹的管理，節點間的通訊也要保持暢通、安全，才能讓訊息流通，減少延遲與丟包狀況，再單一節點出狀況時也要能以最快速度通知。以下是在設計分散式系統幾個常見的挑戰：

Data Integration & Consistency

在無法預測某個節點什麼時候會斷線、掛掉或重啟時，資料的儲存會是極大的挑戰。

Network and Communication Failure

當網路或節點間的溝通出現問題，訊息的傳遞也會亂掉，例如順序不對、傳遞到錯誤的節點等等，連帶造成相關 feature 故障。

Management Overhead

越縝密的管理也代表人力或時間成本的支出增加，除了管理外還須埋許多 log，方便監控節點的運作情形或 debug 錯誤。

什麼是微服務

Source: https://www.weave.works/blog/microservices-and-continuous-delivery

微服務架構算是一種分散式系統的實現，根據 IBM 對微服務的定義：

微服務（或微服務架構）是一種雲端原生架構方法，其中由許多鬆散連結且可獨立部署的小型元件或服務組成單一應用程式。這些服務通常擁有自己的技術堆疊，其中包括資料庫和資料管理模型；透過 REST API、事件串流與訊息分配管理系統的組合彼此相互通訊；而且依商業功能組織起來，其中區隔服務的界線通常稱為有界限的環境定義。

一個微服務架構的應用程式，會將產品依照商業邏輯或功能性去做拆分，形成獨立的服務，透過網路控制彼此的通訊，利用 RESTful endpoints 做資料傳輸，而這些服務各自有備份，因此在某一服務斷線時，很快又能替補上來，減少 service down time，亦不影響整個系統的表現。

這些微服務彼此低耦合，不需要依靠彼此才能運作。不同的微服務間也能使用不同程式語言做開發，這也帶來了分工的好處，畢竟某些語言在針對某些功能實作上有自己的強項可發揮。

而在資源分配上，相較過去單體式開發在擴展上容易造成某些地方資源閒置，各自的微服務能夠自己針對進來的流量去分配資源，達到有效的資源利用。

微服務的特色

不同的服務可以使用不同的程式語言來撰寫，發揮最大效益
元件可以個別獨立擴充，在不影響整體應用程式的情況下可以開發或更新部份服務
功能上的解耦
佈署快速，產品迭代週期短，能夠配合敏捷的方式做開發
強調服務間的隔離性
服務彼此之間透過 API gateway 做溝通與資料交換，可以有效減少來自客戶端的請求

這邊提一下設置 API gateway 的好處，在工作上我們是直接開一個 Proxy service 作為 API gateway：

① 提供統一服務入口，讓微服務對前臺透明

② 聚合後臺的服務，節省流量，提升效能

③ 提供安全，過濾，流控等API管理功能

它要解決什麼問題

微服務架構 (micro-services) 經常被拿來跟單體式架構 (monolithic) 做比較，傳統單體式架構屬於一條龍服務，不同的功能間彼此緊密相連，牽一髮而動全身。在這種情況下，不管是維護 debug 或是擴充、開發，都顯得綁手綁腳，並且在團隊協作上也會需要等來等去，無法各自就功能快速的進行獨立的開發佈署。

微服務架構的出現讓快速佈署、獨立開發變得更加彈性與效率。也因為容器化技術的進步，服務備份、通訊控制、覆載平衡、資源的共享與分配等都變得更加輕鬆。

透過容器技術跟 k8s orchestration ，微服務的每個 service 對應到的 DB 也可以進行 sharding，來增進讀寫的效率，搭配覆載平衡若流量還是過多，能夠很輕易的把單一服務進行水平擴展，增加容器進行導流，也能夠在容器健康狀態不佳時，暗地維護，減少 service down time。