微服務架構——多個小服務，一個系統
在一張互動畫布上呈現微服務架構：用戶端層、API 閘道、各自獨立部署的服務、訊息傳遞、每個服務專屬的資料儲存，以及可觀測性。
微服務是一種架構：應用程式由許多細小、各自獨立部署的服務組成，每一個都擁有自己的資料，並且透過 API 閘道與訊息傳遞來協調，而不是靠共用狀態。
微服務架構——多個小服務，一個系統
The interactive FlowJam canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.
How to read this visual
- 先由上而下讀左邊那一欄：用戶端到閘道，再到服務——這就是請求路徑。
- 跟著每一項服務伸出的箭頭走：去到訊息匯流排、去到它自己的資料庫，以及去到可觀測性。
- 右邊那幾帶是系統的共用基礎設施——訊息傳遞、資料與可觀測性——這就是每一項服務都指向它們的原因。
請求路徑
「網頁與流動用戶端」啟動整個流程，而「API 閘道負責路由與匯總」是唯一的入口——把每一個請求路由到對應的服務、處理身分驗證，並且經常把幾個服務的回應組裝成一份。閘道是每一個用戶端都會看見的那一個組件，這就是它坐落在用戶端層與服務之間的原因。
各項服務
「訂單服務」、「用戶服務」與「付款服務」是各自獨立部署的單元。每一個都由自己的團隊擁有，並按自己的節奏發布。圖解把每一項服務都連到訊息匯流排——服務以事件而不是直接呼叫來溝通——同時也連到它自己的資料庫，因為擁有自己的資料，正是一項服務得以獨立部署的原因。
共用的基礎設施
「訊息匯流排解耦各項服務」讓一項服務可以在不知道誰會消費的情況下發布事件。「每一個服務擁有自己的資料庫」是那條防止共用狀態造成耦合的規則。「指標、日誌與追蹤匯聚成單一視圖」則是令一個由許多服務組成的系統在運作上保持清醒的可觀測性——沒有它，一次故障跨越邊界之後就是看不見的。這三帶既是這套架構的代價，也是它的回報。
Key relationships and takeaways
- 每一項服務都可以獨立部署——架構中其餘一切之所以存在，就是為了保護這項特性。
- 各項服務透過訊息匯流排溝通，並各自擁有自己的資料庫；共用狀態就是反模式。
- API 閘道是系統唯一的正門；用戶端從來不會直接與服務對話。
- 獨立性必須用可觀測性來換取——許多服務只有在單一視圖涵蓋全部時才管理得來。
- 微服務編排的正是 Docker 所打包的容器——這兩張圖解互相扣連。
When to use this visual
- 在團隊採用微服務之前，向他們講解微服務為甚麼存在，以及取捨實際上是甚麼。
- 為新人導入而記錄一個既有系統的服務邊界、訊息主題與資料擁有權。
- 覆核那些反模式：一個共用的資料庫，或者一項服務直接呼叫另一項服務，都是邊界洩漏。
運作方式
把服務改名成你自己的系統
把訂單、用戶與付款換成你真實的服務，並補上這三項通用服務未涵蓋的部分，每一項在「服務」那一帶各佔一個方框。
為你的訊息主題命名
在訊息匯流排上標註你的服務實際發布與訂閱的事件，令解耦是具體的，而不是斷言出來的。
把資料擁有權對應出來
在每一項服務通往它資料庫的那條連線上，寫下真實的儲存（PostgreSQL、一個快取、一個搜尋索引）以及它擁有甚麼，藉此檢查每項服務各有一個資料庫這條規則是否成立。
加入故障與擴展的分支
插入真實的路徑——一項服務在匯流排上的重試與斷路器、一項熱門服務向外擴展的複本——每一條都終結於一個明確的狀態。
常見問題
甚麼是微服務架構？
這是一種架構風格：應用程式由許多細小的服務組成，每一個負責一項業務能力，各自獨立部署，並擁有自己的資料。服務之間透過網絡溝通——通常是 HTTP 與一條訊息匯流排——而不是共用記憶體或資料庫。好處是可以獨立部署與團隊自主；代價則是網絡的複雜性，以及對可觀測性的需求。
為甚麼每一個微服務都要擁有自己的資料庫？
因為共用的資料就是那種會破壞獨立部署的耦合。如果兩項服務讀寫同一張表，它們就無法在不互相協調的情況下改動結構描述、擴展或部署。擁有自己的資料儲存，正是一項服務得以按自己的時間表演進與擴展的原因——這也是圖解中「每一個服務擁有自己的資料庫」那一帶所強制執行的規則。
API 閘道在微服務裡擔當甚麼角色？
閘道是系統唯一的入口。它把請求路由到對應的服務，處理身分驗證與速率限制這類橫切關注點，並且可以把幾個服務的回應匯總成一份。用戶端只與閘道對話，從不直接接觸個別服務，這令服務的拓撲可以在閘道背後自由改變。
甚麼時候不應該用微服務？
當系統細小，或者團隊細小的時候。微服務是用架構上的複雜性——網絡故障、分散式交易、可觀測性——去換取獨立部署的能力，而這場交換只有在團隊大到令獨立部署成為關鍵瓶頸時才划算。許多團隊的問題，用一個模組化良好的單體就已經解決，而那正是單體架構那張圖解的主題。
用 QueryChart（FlowJam）編輯這張圖解
把上面這張微服務畫布開啟為你自己的圖表——把服務改名成你系統裡的服務，並把你真實的邊界畫出來。