前言

微服務是一種 無共享的架構，另一層意思是 “儘量不共享” 模式(share-as-little-as-possible)， 因為總有一些 程式碼 會在微服務之間共享。然後如果太過頻繁的使用 共享程式碼 最終會出現 依賴噩夢，這就是共享反模式。

正文

共享反模式

微服務是一種 無共享的架構，另一層意思是 “儘量不共享” 模式(share-as-little-as-possible)， 因為總有一些 程式碼 會在微服務之間共享。比如 不提供一個身份驗證的微服務，而是將身份驗證的程式碼打包成一個 jar 檔案：security.jar，保證其它服務都能使用。如果安全檢查是 服務級別

然後如果太過頻繁的使用最終會出現 依賴噩夢，如圖 1-1 所示，其中每個服務都依賴於 多個自定義共享庫。

這種共享級別不僅破壞了每個 服務的限界上下文，而且還引入了幾個問題，包括整體 可靠性、變更控制、可測試性 和 部署能力。

1. 過多依賴

在面向物件的軟體開發過程中，經常會遇到 共享 的問題，特別是從 單一分層 結構遷移到 微服務結構 時，圖 1-2 展示 抽象類和共享，它們最終在多數單塊分層體系結構中共享。

微服務架構 的主要目標就是共享要儘可能的少，這有助於維護服務的 限界上下文，使我們能夠快速的 測試

建立 抽象類 和 介面 是 面向物件程式設計 的最重要做法，那我們如何來處理數百個服務共享的程式碼？

2. 共享程式碼的技術

要避免這個 反模式 的最好辦法就是 程式碼不共享，但是實際工作中總會有一些程式碼需要進行共享，那這些共享程式碼應該放到哪裡呢？

圖 1-3 給了四個最基本的技術：

• 共享專案
• 共享庫
• 複製
• 服務合併

相關連結

歡迎關注技術公眾號： 零壹技術棧

本帳號將持續分享後端技術乾貨，包括虛擬機器基礎，多執行緒程式設計，高效能框架，非同步、快取和訊息中介軟體，分散式和微服務，架構學習和進階等學習資料和文章。