分散式單體的六大病症

1. 鎖定部署
當兩個服務需要一起部署時，它們是耦合的。如果它們在一個單體中，這很容易管理。但是，如果它們是實際上應該獨立管理的獨立服務，部署可能會變得緩慢和痛苦。我們可以透過識別耦合的原因並重構我們的解決方案來解決這個問題。

如果這兩個服務使用共享程式碼，則解決方案可以重組程式碼以共享一個單獨管理的庫。如果他們使用共享基礎設施，這可能意味著將服務拆分到不同的主機上。

2.版本耦合
如果服務 A 直接呼叫服務 B 的一個版本，則每次更新服務 B 時，我們都需要更新服務 A 的配置。這種更改耦合會使管理兩個應用程式的生命週期變得複雜，但這是可能的。

理想情況下，服務 A 應該呼叫服務 B 的端點，該端點不是特定版本，並且也由服務 B 管理。這通常可以透過使用 CNAMES 的 DNS 來完成，如下所示：
A1.domain.com > 呼叫 > B.domain.com > B1.domain.com
而不是：
A1.domain.com > 呼叫 > B1.domain.com

3. 雙向依賴
如果服務 A 呼叫服務 B 並且服務 B 呼叫服務 A，則很難測試對任一系統的更改。發生這種情況時，我們可以選擇同時更改整個環境，測試透過舊版和新版軟體傳送到的事件，或者在如何路由訊息方面顯著增加複雜性。

4.共享資料庫訪問
當兩個服務共享相同的資料庫訪問許可權時，無需直接呼叫服務即可輕鬆地從另一個域中提取資料。這可能導致在資料庫層連線的耦合服務。當服務修改它自己的資料庫結構時，它不應該影響任何其他服務。反之如果是這樣，那麼服務是耦合的。

共享資料庫以節省管理工作並沒有錯，但這應該透過安全性進行嚴格控制以防止耦合。使用 Postgres 執行此操作的常用方法是為每個服務使用單獨的使用者和模式。如果一個服務想要訪問另一個服務的資料，它應該直接呼叫下游服務。

5. 共享佇列
與共享資料庫訪問導致耦合的方式相同，共享佇列也是如此。如果兩個服務直接與一個共享佇列通訊，那麼任何一個服務都無法安全地修改、更改或重定向訊息，而不會有破壞這兩個服務的風險。

應儘可能避免共享佇列，並且任何佇列都應由單個服務擁有並且不暴露給其他服務。

6.企業服務匯流排
企業服務匯流排 (ESB) 是另一種常見的資料儲存模式，類似於共享資料庫和共享佇列，但規模更大。ESB 旨在允許透過中央匯流排傳送和接收任何訊息。這意味著一旦服務向匯流排傳送訊息，就不清楚誰在使用該訊息，正在使用它做什麼，以及它是否成功。這些問題不容易解決，這意味著我們的系統不僅會與其他系統耦合，而且會超出我們可能意識到的範圍。

概括
無論您的系統架構如何，您都應該能夠清楚地確定您的系統是單體、微服務還是分散式單體。透過共享部署、共享資料和雙向依賴識別與其他服務的耦合在此過程中至關重要。這樣做將使我們能夠構建我們的架構，這樣我們就可以避免最終成為分散式單體。