微服務架構中的服務邊界與服務識別

前言

在我們進行微服務架構設計和改造過程中，一個不可避免的問題是如何確定服務邊界、如何進行服務識別，微服務的劃分粒度究竟如何確認。我們可能會聽到，服務既不能太大，也不能太小，當然這是一個籠統的概念。那麼，問題來了，究竟多大是大，多小是小。

比如，以下原則是否可行？

• 一個微服務應該包含N行程式碼

• 將系統中每一個功能都定義為一個服務

另外，考慮一個問題：如果服務劃分太細，會出現什麼問題？

• 服務爆炸

• 服務交叉引用

• 程式碼過度耦合

所以，接下來，我們將討論在微服務架構設計中，如何進行服務定義與劃分。

良好設計的服務包含的五個特徵

一個設計良好的服務應包含以下五個特徵：

特徵一：服務不與其他服務共享資料庫

舉個例子：如果你定義了一個微服務後臺需要訪問某個表，與此同時存在別的多個服務也需要訪問同一個表，那麼這就意味著你的資料庫就是一個耦合資料來源。一個良好設計的服務應只包含特定的獨有的資料庫表，並且不與其他服務共享。

我們在開發新服務時一個主要基本原則是，它們不應該跨越資料庫邊界。每個服務都應該依賴於它自己的底層資料儲存集，在這樣的前提下，我們才可以進行集中訪問控制，審計日誌記錄，快取邏輯。

特徵二：服務應包含儘可能少的資料庫表

正如我們之前所提及，微服務的理想大小是足夠小，但不能無限小。每個服務的資料庫表數量也是如此。

特徵三：一個服務要麼包含完整的業務含義，要麼是放之四海皆通用的公共服務。

我們通常會通過定義服務的輸入輸出來確定服務邊界，比如：服務既可以是一個開放的API，也可以是一個處理程式（處理檔案並進行資料儲存，比如我們常見的日誌處理服務），把握好這一點，你才有可能設計良好的服務。

特徵四：一個良好的服務應首先確保其資料可用性。

在設計微服務時，我們需要考慮系統中哪些服務將依賴於這個新服務，假如服務當機導致資料不可用會對系統產生哪些影響。考慮到這一點，我們就可以適當地為該服務設計資料備份和恢復系統。

特徵五：在一個業務系統中，一個服務只能是並且唯一的可信來源。

舉個例子，當我們從電子商務網站訂購東西時，會生成一個訂單ID。其他服務可以使用此訂單ID查詢訂單服務，以獲得關於訂單的完整資訊，基於釋出/訂閱的理念，在服務之間傳遞的資料應該只能是訂單ID，而不是訂單本身的屬性資訊，只有訂單服務擁有完整的訂單資訊，並且只有訂單服務是特定訂單資訊的唯一可信來源。

更大組織的服務設計考量

對於更大的組織，整個團隊都可以專注於擁有某個特定服務，在確定服務邊界時，需要考慮組織機構因素。另外，還有兩個需要注意的問題：獨立的釋出計劃和不同的正常執行時間的重要性。實際實踐中，比較成功的做法是，微服務的實現要麼是基於軟體設計原則，比如基於領域驅動設計或者是面向服務架構設計，要麼是基於可以很好的反映組織架構的設計原則。

比如，對於支付團隊來說，他們可以支付服務或信用卡驗證服務，這就是他們向外界提供的服務，這其實與軟體無關，這就是從組織架構的角度來講，他們作為一個業務部門可以向外界提供的所有服務。

說到團隊，這就涉及到一個著名的“兩個披薩原則”：即團隊大小不宜超過兩個披薩可以供給的人數

如何確認一個服務是否太小或者沒有正確定義

這裡有幾個指標可以來判斷：

• 服務之間是否過度依賴：如果兩個服務在不斷地相互呼叫，那麼這就是過度耦合，將他們整合到一起或許是一個更好的選擇。

• 如果單獨定義、設定服務所花費的精力和代價遠遠大於其帶來的好處和便利，那麼你就需要考慮你所定義的這個服務是否過小。

https://buttercms.com/books/microservices-for-startups/microservice-boundaries-5-characteristics-to-guide-your-design