這陣子因為公司的專案正在準備導入 微服務 ，所以買了這本書來研究，看完之後決定把讀書心得給記錄下來，在還沒讀之前，有好多對這個架構的疑問，像是分散式系統怎麼做 Transaction …等，但書上的內容都有得到解答，書中會以 MallBots 的服務(是個基礎電商系統)，帶我們慢慢的了解微服務架構。

那我們就從第一章開始吧！第一章主要是介紹 MicroService 與 Event-Driven 基礎概念。

先談談，為何要使用 MicroService？

多數企業在開發系統時，一開始都是使用一整套的系統(就是所有功能包含在一個系統裡)，我們公司也不例外，其實這樣的開發很方便，仿間也有好多 Framework 可以使用(Laravel, RoR…等)，尤其是套好的 ORM，真的很好使用，這對剛開始的團隊來說，真的是很方便。

  • 風險提高：每次修改或上線都需重新部署整個系統，任何小錯誤都可能造成全站故障。
  • 維護困難：功能愈來愈多，程式碼愈來愈雜，跨部門修改相互影響，開發速度放慢。
  • 擴展不靈活：所有功能都打包在一起，無法針對單一模組進行資源調整或獨立擴容。
  • 開發瓶頸：團隊人數變多，協作容易踩線。不同模組互相耦合，難以獨立開發或部署。

於是開始思考是否導入 MicroService

微服務架構是為了解決傳統整體式架構在系統成長過程中所面臨的各種瓶頸。它透過「將系統拆分成獨立的、小而專注的服務」來降低耦合、提升彈性、加速開發與部署速度。

  1. 獨立部署、降低風險 每個服務都可以獨立開發與部署。當某個功能需要修改或上線時，只需要更新那個服務，無需重新部署整個系統，大幅降低部署時的風險與等待時間。

  2. 擴展更有彈性 服務彼此獨立，讓系統可以針對流量較高的部分（如訂單、搜尋）進行水平擴充，而不需要為整個應用程式升級硬體。這讓基礎建設更有效率，也節省成本。

  3. 開發協作更清晰 每個微服務都專注在特定業務領域，適合由小團隊負責。開發團隊可以在不干擾彼此的情況下同時進行工作，清楚劃分責任，提升開發效率與團隊合作流暢度。

  4. 技術選擇自由 不同微服務之間可以採用最合適的程式語言（例如一個服務用 Go 處理高併發，一個用 Python 做資料分析），讓技術選型回到業務本質，而不是被框架給侷限。

  5. 更符合現代 DevOps 與自動化流程 微服務天生適合搭配容器化（如 Docker）、自動化部署（CI/CD）、監控與追蹤工具。這不僅提升開發速度，也讓系統更容易監控、追蹤問題與維運。

談談優點後，來看看遇到哪些挑戰

微服務也並非全能，也不是導入後就不會帶來其他問題。事實上，開始轉型至微服務將會提升系統的複雜度。若對架構管理、部署流程或經驗不足，微服務反而可能成為負擔。

這也是我們為何要讀這本書的原因。

以下是常見的挑戰：

  1. 分散系統的複雜度 原本整體是系統的 Func 呼叫，現在變成跨服務的 API，需要處理網路延遲、重試機制、版本控管與失敗容錯，這些都會大幅提高設計與測試的複雜度。

  2. 資料一致性困難 整體式系統通常共用一個資料庫，資料一致性容易維持(一個 Transaction 就做完的事)；但在微服務中，每個服務可能擁有自己的資料庫，跨服務的交易與資料同步需要引入額外機制（例如：最終一致性、Saga Pattern）。

  3. 部署與監控門檻提高 微服務數量增加後，部署流程更複雜，維運工作也變得繁瑣。你需要完整的 CI/CD 流程、自動化部署工具、集中式日誌系統、分散式追蹤（Distributed Tracing）等來支撐日常營運。

  4. 開發環境複雜化 在本地開發時，模擬整個系統變得困難。開發人員往往需要模擬多個服務或依賴外部環境，增加開發成本與測試不確定性。

  5. 組織與溝通挑戰 微服務的本質其實是一種組織的拆分。如果團隊沒有明確的職責邊界，或溝通不順暢，很容易產生重複邏輯、相互依賴、版本混亂等問題。技術轉型需要配合組織與流程的同步改革。

說明完了挑戰，可能勸退了不少人，但別急，多數的問題在書中都有提出解決方案！

介紹完了 MicroService ，那 Event-Driven 又是什麼？

在微服務架構中，每個服務都獨立運作，但業務流程往往需要跨服務合作。這時如果每個服務之間都透過 API 相互呼叫，不僅會造成高度耦合，一個 內部的 API 如果壞了，其他有用到這個的服務的都跟著一起上天堂了。這就是為什麼 Event-Driven Architecture（事件驅動架構） 常被用來搭配微服務，它讓服務之間以事件（Event）為訊號進行溝通，而不是彼此直接呼叫，達到更鬆耦合、可擴展的設計。

圖中示例是當系統完成訂單時，必須透過 API 方式 告訴其他系統已經完成訂單了，讓其他系統可以在完成這筆訂單做其他事，如：庫存系統必須把店內庫存減少，報表必須做更新等等。在這個過程中，如果 HTTP 或 GRPC 有問題，就會造成某部分的系統完成訂單，而某部分失效等，這樣就會造成系統的不一致。而 Event-Driven 不用像 HTTP 或 GRPC 一定要確認對方有收到訊息(一定要 Request 成功)，我們只要將發生的事件丟給 Message Broker，然後讓其他系統去訂閱這個事件即可。不需要擔心對方有沒有收到訊息，我們只要確保我們的事件有送到 Message Broker，接下來交給 Message Broker 進行處理。

以此，我們可以藉由事件驅動的方式，當訂單完成時，就發送一個訂單完成的非同步事件，讓其他系統去訂閱。在訂閱的系統中，當有事件發生時，就會去做相對應的事情。每個系統只管發送事件成功與否，後續藉由 Message Broker 來管理，這樣可以達到系統的解耦，每個系統不需要知道其他系統的存在，只需要知道有哪些事件可以訂閱即可。比起用 API 方式，我們不必須要知道當這件事件發生時，要送給哪些系統，也不需管理當 API 有問題時，要如何處理。

Summary

這一章主要是介紹 MicroService 與 Event-Driven 的基礎概念，雖然這些概念在網路上都可以找到，但書中有更詳細的說明與範例，讓我們更能了解這些概念的運作方式。接下來的章節會針對這些概念進行深入的探討，並且會有實際的範例來說明如何在 Golang 中實作這些概念。