又來到了一周的開始，真不想去上班QQ，總之，這次來介紹臺灣企業近年來熱衷的微服務架構吧！
簡介
上週提到過，微服務架構的設計初衷是為了解耦服務之間的關係，使每個服務能夠獨立更新和維護，從而提高擴展性，而服務之間則透過 API 交換資料。這種獨立的服務設計讓多個團隊能夠更方便地同時進行開發，避免程式碼衝突。因此，在臺灣隨著敏捷開發方法（Scrum）的普及，越來越多的團隊開始採用微服務架構。
依賴與耦合
介紹到這裡，相信有些人心中會產生疑問：什麼是耦合？它與依賴有關嗎？其實，這兩個概念相當相似。簡單來說，依賴指的是程式碼之間的關聯性。例如，功能 B 需要依賴功能 A 才能實現，或是類別 C 繼承自類別 D 等等。當依賴關係越來越多，維護就變得愈加困難。有時，你可能只是想修正 A 功能的小錯誤，卻發現 B、C、D 等其他功能也受到影響，結果原本的小調整卻變成了大項目，讓你不得不先盤點哪些功能有依賴，再將參數隔離，工作量驟增。
耦合則可以理解為程式碼間依賴的程度。原則上，我們希望耦合越低越好，只維持最低限度的依賴[註1]，這樣才能有助於後續的擴展與維護。
有關依賴及依賴注入的更詳細內容，可以參考這位前輩寫的文章菜雞與物件導向 (14): 依賴反轉原則 | 伊果的沒人看筆記本。
回到微服務
在介紹完耦合與依賴後，就讓我們回到微服務架構吧！微服務架構的主要優點包括：
- 模組化設計：每個微服務專注於特定業務功能，使系統更加模組化，方便開發與維護。
- 獨立部署：各服務可以獨立部署和更新，不會互相影響，提高開發和部署的靈活性。
- 技術多樣性：不同微服務可根據需求選擇最合適的技術，增加技術選擇的靈活性。
- 擴展性：微服務架構容易針對特定服務進行擴展，從而提高整體系統的可擴展性和性能。
- 容錯性：由於每個微服務獨立運行，單一服務的故障不會影響整體系統，提升容錯能力。
- 易於維護和測試：每個微服務都是小而專注的功能單元，讓程式碼庫更簡潔，易於維護和測試。
不難發現，這些優點都基於「將服務獨立出來」的理念。雖然獨立的服務會使整體系統更加複雜，但對於各服務而言，卻提供了更高的靈活性與擴展性，特別適合快速迭代的現代環境。
如何解耦
雖然微服務架構的設計初衷是為了減少耦合，但在實踐中，如果設計或管理不當，仍可能導致高耦合。以下是兩個常見情況及其解決方案：
1. 共享資料庫
- 問題：如果多個微服務共享同一個資料庫，會增加耦合度，降低獨立部署和擴展的能力。
- 解決方案：每個微服務應擁有自己的資料庫，通過服務接口進行數據交換，而非直接訪問其他服務的資料庫。
2. API 的變更
- 問題：當一個微服務的 API 發生變更時，依賴該 API 的其他服務也需同步更新。
- 解決方案：採用向後兼容的 API 設計原則[註2]，並使用版本控制管理 API 的變更，從而減少對其他服務的影響。
總結
總之，微服務架構仍然需要仔細的設計和管理，以避免高耦合問題。通過採取適當的設計模式和工具，我們可以有效減少微服務之間的耦合，實現系統的高可用性和可擴展性！
[註1] 需要注意的是，這並不是說完全不依賴，畢竟將程式碼複製貼上一份並不是好的做法，因為這樣其實不符合 Clean Code 的原則，實務上也會使後續維護變得困難，例如相似功能的預設值不同，導致需要逐一檢查確認。
[註2] 向後兼容的 API 設計原則的主要理念是希望不影響現有使用者，避免因 API 的變更而導致系統中斷或故障。主要做法包括「添加新參數」、「為參數設定預設值」、「在 URL 中加上版本號」等。
