微服務架構——多個小服務，一個系統 · 心智圖
微服務架構——多個小服務，一個系統. 可編輯嘅心智圖，以彩色分支、子題目同曲線連結呈現概念。 曲線表示關聯；只有方向重要時先用箭嘴。
微服務是一種架構：應用程式由許多細小、各自獨立部署的服務組成，每一個都擁有自己的資料，並且透過 API 閘道與訊息傳遞來協調，而不是靠共用狀態。
微服務架構——多個小服務，一個系統 · 心智圖
The interactive MindMap canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.
點樣閱讀呢張心智圖
- 由中央主題開始，沿住彩色分支探索相關概念。
- 曲線表示關聯；只有方向重要時先用箭嘴。
Clients & gateway
呢個分支匯集 “Web and mobile clients”, “The gateway is the single entry point: it routes each request to the right service, handles authentication and often aggregates responses from several services.”.
Independent services
呢個分支匯集 “Orders service”, “Payments service”, “Teams deploy and scale services independently”, “Users service”.
Messaging
呢個分支匯集 “Services communicate by publishing events rather than calling each other directly — so one service's change or outage never blocks another.”.
Owned data
呢個分支匯集 “The defining rule of microservices: no shared schema. Each service's data is private to it, which is what allows teams to deploy independently.”.
Observability
呢個分支匯集 “Metrics, logs and traces feed one view”.
跨分支關聯
每一項服務都可以獨立部署——架構中其餘一切之所以存在，就是為了保護這項特性。
各項服務透過訊息匯流排溝通，並各自擁有自己的資料庫；共用狀態就是反模式。
API 閘道是系統唯一的正門；用戶端從來不會直接與服務對話。
獨立性必須用可觀測性來換取——許多服務只有在單一視圖涵蓋全部時才管理得來。
微服務編排的正是 Docker 所打包的容器——這兩張圖解互相扣連。
Key relationships and takeaways
- 每一項服務都可以獨立部署——架構中其餘一切之所以存在，就是為了保護這項特性。
- 各項服務透過訊息匯流排溝通，並各自擁有自己的資料庫；共用狀態就是反模式。
- API 閘道是系統唯一的正門；用戶端從來不會直接與服務對話。
- 獨立性必須用可觀測性來換取——許多服務只有在單一視圖涵蓋全部時才管理得來。
- 微服務編排的正是 Docker 所打包的容器——這兩張圖解互相扣連。
When to use this visual
- 在團隊採用微服務之前，向他們講解微服務為甚麼存在，以及取捨實際上是甚麼。
- 為新人導入而記錄一個既有系統的服務邊界、訊息主題與資料擁有權。
- 覆核那些反模式：一個共用的資料庫，或者一項服務直接呼叫另一項服務，都是邊界洩漏。
運作方式
調整中央主題
按項目或課堂修改中央主題名稱。
擴展分支
編輯概念並加入例子或註解。
連結相關概念
畫出跨分支連結；只有方向重要時先用箭嘴。
常見問題
甚麼是微服務架構？
這是一種架構風格：應用程式由許多細小的服務組成，每一個負責一項業務能力，各自獨立部署，並擁有自己的資料。服務之間透過網絡溝通——通常是 HTTP 與一條訊息匯流排——而不是共用記憶體或資料庫。好處是可以獨立部署與團隊自主；代價則是網絡的複雜性，以及對可觀測性的需求。
為甚麼每一個微服務都要擁有自己的資料庫？
因為共用的資料就是那種會破壞獨立部署的耦合。如果兩項服務讀寫同一張表，它們就無法在不互相協調的情況下改動結構描述、擴展或部署。擁有自己的資料儲存，正是一項服務得以按自己的時間表演進與擴展的原因——這也是圖解中「每一個服務擁有自己的資料庫」那一帶所強制執行的規則。
API 閘道在微服務裡擔當甚麼角色？
閘道是系統唯一的入口。它把請求路由到對應的服務，處理身分驗證與速率限制這類橫切關注點，並且可以把幾個服務的回應匯總成一份。用戶端只與閘道對話，從不直接接觸個別服務，這令服務的拓撲可以在閘道背後自由改變。
甚麼時候不應該用微服務？
當系統細小，或者團隊細小的時候。微服務是用架構上的複雜性——網絡故障、分散式交易、可觀測性——去換取獨立部署的能力，而這場交換只有在團隊大到令獨立部署成為關鍵瓶頸時才划算。許多團隊的問題，用一個模組化良好的單體就已經解決，而那正是單體架構那張圖解的主題。
喺 QueryChart 編輯呢張心智圖
喺可編輯畫布開啟心智圖。移動概念、加入分支同畫連結。