典型的微服務設計

這篇章將從典型的微服務架構來說起，最後再套入我們的前幾篇設計好的 Todo List Service。

微服務通常是在一個大型專案中拆分成許多小型服務，每個服務都專注於各自的職責。例如，一個 eShop 系統可能會有 Ordering、Payment、Product、Client、Basket 等等各司其職的小型系統，我們稱之為 Domain Service。

微服務之間通常透過定義完善的介面與接口進行溝通，這些介面與接口通常會設計得十分簡單且專注，稱之為 Small Surface Area。這麼做有兩大好處：首先，這使每個 Domain Service 變得更容易理解與維護；其次，當某個微服務出現問題時，由於暴露的接口範圍有限，這些問題的影響範圍（Blast Radius）只會局限於小範圍，避免擴大到整個系統。

在這些 Small Surface Area 中，我們常使用 gRPC、Event Streaming、Message Brokers/Queues 進行通訊。其中，gRPC 提供了更高效的同步傳輸，特別適合低延遲的服務間通訊。Event Streaming 能有效處理大量資料的非同步傳輸，適合處理如交易、通知等情境。Message Brokers 則能在服務之間實現可靠的消息傳遞，常見於確保數據傳輸完整性的場合。

由於每個 Domain Service 變得簡單高效且 Blast Radius 小，開發者可以更輕鬆地構建無狀態服務，並且更加有信心地進行部署。這使得微服務架構可以提供更大的靈活性，允許各個服務獨立地進行擴展（Scale Up 和 Scale Out），這種靈活性是微服務架構最重要的價值之一。

除了 Domain 的拆分之外，微服務架構通常還會將資料庫拆分為多個針對各自 Domain 的小型資料庫。這種拆分能讓系統設計維持上述的優點，但代價是我們失去了跨資料庫的關聯一致性。換句話說，我們沒辦法跨資料庫使用 Foreign Key 來確保 Data Integrity，我們勢必得在 Application Layer 做更多的補償機制來解決問題。

當我們把系統拆散成多個服務時，便需要使用 Gateway 來處理所有的外部請求，並將這些請求路由到相應的微服務。此外，這個 Gateway 通常依賴於身份識別服務（Identity Service）來確保系統的安全性。

最後，微服務系統的複雜性無法直觀地掌握，因此追蹤 Log 變得更加困難，因此我們通常會引入許多的現代化日誌管理系統，如 OpenTelemetry、ELK（Elasticsearch、Logstash 和 Kibana），來方便地監控和分析整個系統的運行狀況。這有助於在多個微服務之間快速定位問題，從而提高系統的可觀察性（Observability, O11y）。

回到主題 Todo List Service

直接將上述套回目前的題目，

其中 RabbitMQ 是一個開源的 Message Broker，支持多種消息隊列協議，能夠在分布式系統中實現可靠的消息傳遞、負載均衡和異步通信。