因此今天我們來談下面對這種情況我們可以從哪些思路下手去解決。

兩個微服務本身緊耦合則進行合併

如果兩個微服務間出現大量接口相互調用，即可以認爲緊耦合。或者我原來的判斷標準，即兩個微服務對應的後臺數據表，其中30%以上都需要兩個微服務交叉訪問，那麼就認爲兩個微服務本身耦合性極強。

在這種情況下處理措施就是原來微服務劃分的太細了，需要對兩個微服務進行合併。

交叉依賴轉變爲共性依賴

要知道在傳統軟件開發裏面往往是不允許兩個組件交叉依賴的。但是在新的IOC和微服務開發裏面，大量都是反射調用，兩個組件相互依賴不會有問題。但是這本身也不是一種很好的設計方法。

如果兩個微服務或多個微服務相互依賴內容本身具備共性。那麼最好的做法就是將共性內容全部移出，下沉爲一個共性基礎微服務模塊再朝上提供服務。

即將兩個微服務依賴內容下沉，將交叉依賴轉變爲對底層的共性依賴。

對某個微服務實現單元進行遷移

爲什麼出現這種場景？

簡單來說就是原來的微服務模塊劃分和業務功能劃分不合理。比如上圖中的微服務A中的A1部分。這個部分內容需要大量被微服務B調用，但是A1實際依賴微服務A中其它部分的內容卻很少。

這種就是典型的A1部分功能劃分位置不合理。最好的做法就是將A1功能從微服務A遷移到微服務B，實現對原有業務劃分不合理的糾正。

將細粒度服務轉變爲真正的粗粒度服務

服務本身應該具備粗粒度屬性，暴露僅僅需要暴露的內容。比如微服務A實現客戶信用檢查和評級。微服務B需要客戶信用。有兩種做法

第一種是B調用A多個接口，把客戶基本信息，客戶交易信息，客戶違約信息全部查詢過來，然後自己計算客戶信用。這就是我們說的典型細粒度服務接口。

第二種即是隻需要輸入客戶編碼，微服務A返回最早的信用評級。

對於後者就是我們常說的粗粒度接口或領域服務，服務間的交互應該以領域服務和粗粒度服務爲主，避免掉完全的數據庫表的CRUD類服務接口。