系列文章
DAY 1
微服務瞎談(1) 微服務架構興起的原因
微服務瞎談 微服務這幾年超級夯!!!工作中有些筆記跟服務使用上的經驗做些分享. 也藉此複習。基本上不會特別分享要怎做, 但會從幾個唯度來分析.還有分享幾個微服務...
DAY 2
微服務瞎談(2) 服務與架構的演化
服務與架構的演化 Gen.1 Cleint/Server or Browser/Server架構 這時代主要是C/S或者B/S模式的應用與架構, 主要是面向功能...
DAY 3
微服務瞎談(3) 微服務的拆分
微服務的拆分 AKF拆分原則 參考自此書 The Art of Scalability: Scalable Web Architecture, Processe...
DAY 4
微服務瞎談(4) 單機ACID事務 & MySQL主從同步
當開始評估怎設計微服務架構時, 就要來關心如何實現跨多個服務的事務(Transaction)交易了。事務處理才能確保資料的一致性。舉例, Order Servi...
DAY 5
微服務瞎談(5) CAP理論
CAP理論 Consistency一致性 : 所有節點上的數據都能隨時保持著同步的狀態 Availability可用性 : 每次請求都能得到一個回應, 無論...
DAY 6
微服務瞎談(6) BASE理論 & Transactional Outbox Pattern
BASE原則 CAP只侷限於原子讀寫的NoSQL場景下, 且也無法支援資料庫的事務交易這類的場景.所以在資料庫如果分片分表或是多個實例節點架構上, CAP並不適...
DAY 7
微服務瞎談(7) Saga Pattern
Saga Pattern 之前介紹的Outbox Pattern可能需要透過排程或是MQ來做訊息交換.設計上會稍微複雜, 要引入MQSaga不必引入MQ, 因為...
DAY 8
微服務瞎談(8) Saga, Choreography vs Orchestration
上篇提到Saga模式.末段的流程是把Saga的決策和執行順序的邏輯分佈在Saga的每一個參與者之中, 透過通訊交換事件的方式來溝通, 這種叫做Choreogra...
DAY 9
分散式系統中的冪等性 & Unique ID
冪等性 數學定義 自己給重複運算的結果==自己 f(f(x)) = f(x) 使用者對於同一操作發起多次請求，請求的結果是一致的，不會因為多次點選而產生副作用...