在設計基於微服務的系統時，衡量和優化正確的指標至關重要。為每個微程式碼庫和微團隊設計本地邊界絕對很容易。但是，要構建一個完整系統，我們必須將系統級別設計也考慮在內。微服務與系統級別的設計有關，而不是僅僅與單個服務有關。

在基於微服務的系統中，我們通過最小化服務的公共介面（使之成為微服務）來平衡本地和全球的複雜性。您公開的服務越小，其實現越簡單，因此其本地複雜性也就越低。從全域性複雜性的角度來看，較小的公共介面在服務之間產生較少的依賴關係和連線。

這種方法聽起來似乎很簡單。如果微服務只是具有微公共介面的服務，那麼我們可以將公共介面限制為僅有一種方法的介面。不能比這更小了，那應該這就是是完美的微服務嗎？

並非如此。為了形成系統，服務必須彼此互動並共享對每個服務狀態的更改。因為服務介面只有一個方法，這個方法只是本地功能操作，無法與其他服務互動，因此，我們必須使用用於在服務之間整合的公共方法來實現這種更改，那麼這種呼叫就變成蜘蛛網式的呼叫：

全域性複雜性開始增加，不僅最終的系統陷入了混亂，而且為了整合的目的，我們還不得不將公共介面擴充套件到我們最初的意圖之外。這將我們帶到了重要的一點：

對於整合功能比業務相關的功能更重要的的服務來說，這是一種不斷增長的分散式大泥球。

因此，可以將服務的公共介面最小化的閾值不僅取決於服務本身，而且還主要取決於該服務所屬的系統。對微服務的適當分解應該平衡系統的全域性複雜性和服務的區域性複雜性。

設計服務邊界

設計微服務的邊界很困難，而且可能不可能在第一時間就正確。這使得設計相當複雜的基於微服務的系統成為一個迭代過程。

因此，更安全的方法是從更寬的邊界開始，可能是適當的有界上下文的邊界，然後隨著對系統及其業務領域的更多瞭解，將它們分解為微服務。它與包含核心業務領域的服務特別相關。

這就是全部嗎？

儘管最小化服務的公共介面是設計微服務的良好指導原則，但這仍然只是一種啟發，並不能取代常識。實際上，微介面只是對更基本但更復雜的設計原理（耦合和內聚）的一種抽象。

例如，如果兩個服務具有微公共介面，但是必須在分散式事務中進行協調，則它們之間仍然彼此高度耦合。

也就是說，針對微介面仍然是一種強大的啟發式方法，可以解決不同型別的耦合問題，例如功能，開發和語義。但這是另一個部落格的主題。