微服務的顆粒度難題：找到合適的微服務大小

來源：小技術君

前言

在微服務架構風格中，微服務通常按照單一職責原則（SRP）設計，作為一個單獨部署的軟體單元，專注於做一件事情。我們作為開發人員往往傾向於儘可能將服務設計得更小，卻沒有考慮為什麼要這樣做！關於服務顆粒度的主觀性，即什麼是單一職責，是我們作為開發人員在微服務顆粒度方面犯錯的地方。為了克服開發團隊在確定微服務大小時面臨的困境，理解顆粒度的驅動因素是至關重要的。

顆粒度

在微服務中，有兩個概念——模組化，涉及將系統拆分為獨立的部分，另一個是——顆粒度，涉及這些獨立部分的大小。

確定顆粒度的合適水平——服務的大小之一是微服務架構中許多困難的部分，我們作為開發人員很難解決。顆粒度不是由服務中的類或程式碼行數來定義的，而是由服務所做的事情決定的——因此，在正確確定服務顆粒度時存在這種難題。

服務的顆粒度分為兩種相反的力量——顆粒度分解器和顆粒度整合器。

顆粒度分解器

我應該在什麼時候考慮將服務拆分成更小的部分？然而，

顆粒度整合器

我應該在什麼時候考慮將服務重新組合？

顆粒度分解器

由於我們生活在微服務和奈米服務的時代，大多數開發團隊透過隨意拆分服務並忽視隨之而來的後果而犯錯。為了找到合適的大小，應該在不同的引數上進行權衡分析，並根據微服務的上下文和邊界做出明智的決定。

顆粒度分解器的驅動因素為何拆分服務提供了指導和理由。讓我們看看這些驅動因素如何影響微服務大小的分析，以一個例子為例。

示例：考慮一個典型的通知服務，負責透過簡訊、電子郵件或郵寄的紙質信件通知客戶。

讓我們透過分解器驅動因素對這種情況進行分析，並找到合適的大小。我們從以下開始：

服務範圍和功能

服務是否執行了太多無關的事情？服務的範圍和功能主要取決於兩個屬性——首先是內聚性，即特定服務操作的程度和方式相互關聯。第二個是元件的整體大小，通常用責任的數量、服務的入口點數量或兩者的組合來衡量。 場景：看看通知服務，有人可能說將此服務拆分為三個單一用途的服務。但這是正確的嗎？答案是否定的！因為這個服務具有相對強的內聚性，即所有這些功能都與一個目標相關，即通知，並且具有一個單一的目的。因此，無需拆分服務，因為它應該是一個執行三個任務的服務。接下來是：

程式碼波動

更改是否僅限於服務的某一部分？程式碼波動是原始碼更改的速率。我們必須衡量服務中原始碼更改的頻率，這有助於充分理由拆分服務。 場景：假設我們對服務功能有以下指標：

現在，如果我們按照更改的度量標準進行分析，郵寄信件通知部分的頻繁更改也要求測試簡訊和電子郵件，因此作為單個服務，它增加了測試範圍和部署風險。那麼我們該如何解決呢？

如果我們將此服務拆分為兩個獨立服務，電子通知和郵寄通知，頻繁的更改現在隔離到其自己的服務中，因此測試範圍減小，部署風險降低。

可擴充套件性和吞吐量

服務的部分是否需要以不同的方式擴充套件？可以客觀地測量服務不同功能的可擴充套件性需求，以量化服務是否

應該被拆分。

場景：再次考慮通知服務示例，測量單個服務的可擴充套件性需求如下：

在這種情況下，作為單個服務，電子郵件和郵寄信件功能必須不必要地擴充套件以滿足簡訊通知的需求，影響成本和彈性，即啟動的平均時間。這完全證明了將通知服務拆分為獨立服務——簡訊、電子郵件和信件，因為它允許每個服務獨立擴充套件以滿足其各自不同的吞吐量需求。

容錯性

是否存在導致服務內關鍵功能失敗的錯誤？在特定領域內應用程式即使發生致命崩潰（例如OOM），仍然能夠繼續執行的能力。 場景：考慮到通知服務的情況，假設電子郵件功能繼續出現OOM錯誤併發生致命崩潰，整個合併服務會中斷，包括簡訊和郵寄信件處理。將這個單一的合併通知服務拆分成三個獨立服務為客戶通知領域提供了一定程度的容錯性。因此，電子郵件功能的致命錯誤不會影響簡訊或郵寄信件。 進一步：現在這裡可能會出現一個問題，因為電子郵件是唯一與頻繁崩潰有關的問題，為什麼不將簡訊和郵寄信件功能合併？這是一個合理的問題。如果記得，當我們討論程式碼波動的情景時，我們將郵寄信件與電子郵件分開，然後將簡訊和郵寄信件合併成一個——電子通知。如果我們在那裡能夠做到這一點，為什麼在這裡不行呢？因為電子郵件和簡訊是相關的，它們都是電子通知的一部分。但在這裡，簡訊和郵寄通知沒有任何共同之處，無法合併。

注意：記住，如果一個服務因為它執行多個無關的任務而難以命名，那麼考慮拆分該服務。其次，無論出於哪種驅動因素拆分服務，都要始終檢查是否可以透過“剩餘”功能形成強內聚性。因此，將通知服務分解為三個獨立服務在這裡是有道理的。最後但並非最不重要的驅動因素是：

可擴充套件性

服務是否始終在擴充套件以新增新功能？在服務擴充套件時新增附加功能的能力。 場景：假設我們要向通知服務新增新功能，例如移動推送通知、桌面通知、社交媒體通知等。這些新功能當然可以新增到單個合併的通知服務中。然而，每次新增新的通知時，整個通知服務都需要進行測試，並且所有通知的功能都需要不必要地部署到生產環境。

注意：僅在事先知道計劃並希望將額外的合併功能作為領域的一部分時才應用此場景。