微服務的拆分

AKF拆分原則

參考自此書 The Art of Scalability: Scalable Web Architecture, Processes, and Organizations for the Modern Enterprise
是一群技術專家總結出來對於單體應用拓展的三個維度(X-Y-Z軸).
依照這擴展模式, 可以將一個單體架構(大方塊就是一個單體系統)無限擴展.

X軸 水平擴容/複製

針對單體程序進行多個複製, 或者對資料庫進行擴容, 並組成cluster.
再透過負載均衡服務針對N個實例進行請求分配, 這樣每個實例只需要處理1/N的負載.
進而提高吞吐量與可用性.

pros

1. 理論上容易, 就是複製
2. 能快速實現

cons

1. 每個程序都能訪問到完整的數據, 所以變成資料庫之間的數據要進行複製, 成本很高
2. 組織每個人的職責難以切分, 大家還是面對這單體XD
3. 存放的資料很多, 快取命中率降低, 所需要的記憶體也增加了

Z軸 數據分區

Z軸擴展也是複製單體程序到多個實例上, 但跟X軸不同的是, 每個實例僅負責一部分的資料子集合.
換句話說, 就是根據某些規則絕對該請求到那一個實例程序上.

舉例, B2C透過user_id是偶數的去第一台, 奇數的去第二台.
又或是電商根據SKU種類去切分片;
掏寶根據用戶的請求地區進行分區, 在各區各自建立cluster, 縮短處理時間.
或者電腦版用戶來服務A, 安卓用戶來服務B, IOS用戶來服務C.

B2B通常根據公司或是集團組織進行切分.

pros

1. 提供了故障隔離性; 若有一區故障只有一部分資料與對應的客戶受影響
2. 因為資料數量變少了, 快取命中率上升了
3. 處理回應時間減少了

cons

1. 實現成本頗高, 數據分區方案不好實現
2. 程序的複雜性上升, 因為要處理分區
3. 需要提昇自動化覆蓋率, 來減少佈署與維運的成本

Y軸 功能/業務的分解

因為X跟Z軸都沒能解決開發問題還有程式或者依賴的複雜度問題.
Y軸就是來解決這維度的.
進行功能的切分, 根據業務能力來劃分.
業務能力有人會依照"動詞Verb"來劃分, 舉例:結帳、驗證、購買、註冊;
也有是按照"名詞Noun"來做分解, 舉例:客戶、訂單、報表、商品列表.
或者根據DDD的Subdomain.

定義出接口與通訊的協定. 就回到上篇的微服務的設計原則.
每個切分出來的服務都是一組專注于特定業務能力的實現, 高內聚的職責組成.

pros

1. 程式的複雜度降低了
2. 組織規劃能按照業務來劃分
3. 提供了故障隔離性
4. 因為每組服務只負責對應業務的資料快取, 所以命中率也是很高

cons

1. 服務管理難度變高

前後端分離

前後端在邏輯與物理上進行切分, 彼此都能獨立佈署, 各自專注在自身業務上.

透過後端定義好的接口與格式, 前端就能快速串接.
前後端分離後, 靜態資源也能推到CDN或是Nginx內, 減低server壓力, 讓後端資源用在處理動態資遠請求上.

無狀態服務

服務盡量無狀態化, 就能任意擴容. 這太抽象了XD
這狀態指的是如果一個資料會被多個服務彼此共享存取操作, 才能完成一次的事務處理, 這資料就稱為"狀態".
所有依賴于這資料的服務就是被稱為"有狀態的服務".
所以要想辦法把服務變成純粹無狀態的計算/業務服務.
這資料呢, 移到"有狀態資料的服務"上, 像是Redis, Database, 將這些有狀態的資料移到其他地方存放.
這樣子這些無狀態的業務服務, 就能隨時動態收放, 不必考慮數據同步問題了.

這也是為什麼資料庫很難動態擴容的原因, 因為有資料一致性與資料完整性的問題存在.

RESTful通訊風格

無狀態的HTTP協議, 很適合用來擴展.
JSON格式相對於XML輕量很多, 可讀性又強.
REFTful開發框架/套件琳瑯滿目,生態圈非常完善.
滿足RESTful特性的資源被GET時, 可以被cache, 減少回應時間, 提昇體驗.
各平台or裝置都可重複利用這些服務.

DDD社團