微服務依賴於其他人做任何事

Question

目前我處理微服務並遇到幾個問題（關於服務之間的關係），我很難找到一個好的答案/最佳實踐。如果你能給我一個提示或建議你如何處理這件事，那將是非常好的。

因爲這些問題是不針對特定的項目，我儘量做到儘可能明確用下面的例子：

讓我們假設你想建什麼樣的YouTube頻道觀察員，即日誌不同種類的頻道（元數據）數據（視頻，小時視圖/子數，當前訂閱），這些數據是以特定時間間隔導入的。

所以有兩個主要功能的應用程序所提供的，應該形成一個微服務的每個：

• 添加/刪除要收看的頻道（=>管理器服務）
• 進口信息（=>進口服務）

這兩個服務提供了一個API來相互溝通。

管理器服務連接到一個數據庫，該數據庫包含需要觀看的頻道及其基本信息（姓名，聯繫人......）以及這些觀察頻道當前訂閱的頻道，而導入服務有一個數據庫，其中包含所有其他更多面向時間序列的信息（視頻，小時視圖/子計數）。

要添加頻道只有頻道url必須指定。所有其他信息（名稱，聯繫人...）都由導入服務添加（但也可以由用戶修改）。

如果沒有導入服務可用，所有導入服務在沒有管理服務信息的情況下完全沒有用，而且管理服務只能顯示用戶指定的頻道信息（最壞情況：只有頻道URL）。總的來說：他們非常依賴對方。

這麼多的一般架構。

我這裏是，該進口服務依賴於管理員服務數據庫，以這樣一個偉大的程度的數據，並對其進行修改的問題：

1. 難道是共享經理是個好主意這兩個服務之間的服務數據庫還是隻能通過提供的API訪問？
2. 無論數據庫是否共享：兩個服務都需要該通道的模型類。分享這些可以嗎？
3. 這種架構是否甚至是一個好主意（如果我們假設還有其他服務需要基本的頻道信息）？

Answer 1

當兩個微服務緊密耦合時，我會建議您想要合併它們。爲什麼你想要微服務呢？這是一個大型項目，應該增長很多，可能有獨立的團隊正在努力？ 不要僅僅因爲它們很酷，而是因爲需要而做微服務。在一個相對較小的單人項目中，我通常不會建議使用微服務。

我會做一些閱讀微服務。io關於何時使用微服務體系結構以及何處拆分。