前言

在微服務(wù)架構(gòu)風(fēng)格中，微服務(wù)通常按照單一職責(zé)原則（SRP）設(shè)計(jì)，作為一個單獨(dú)部署的軟件單元，專注于做一件事情。我們作為開發(fā)人員往往傾向于盡可能將服務(wù)設(shè)計(jì)得更小，卻沒有考慮為什么要這樣做！關(guān)于服務(wù)顆粒度的主觀性，即什么是單一職責(zé)，是我們作為開發(fā)人員在微服務(wù)顆粒度方面犯錯的地方。為了克服開發(fā)團(tuán)隊(duì)在確定微服務(wù)大小時面臨的困境，理解顆粒度的驅(qū)動因素是至關(guān)重要的。

顆粒度

在微服務(wù)中，有兩個概念——模塊化，涉及將系統(tǒng)拆分為獨(dú)立的部分，另一個是——顆粒度，涉及這些獨(dú)立部分的大小。

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

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

顆粒度分解器

我應(yīng)該在什么時候考慮將服務(wù)拆分成更小的部分？然而，

我應(yīng)該在什么時候考慮將服務(wù)重新組合？

顆粒度分解器

由于我們生活在微服務(wù)和納米服務(wù)的時代，大多數(shù)開發(fā)團(tuán)隊(duì)通過隨意拆分服務(wù)并忽視隨之而來的后果而犯錯。為了找到合適的大小，應(yīng)該在不同的參數(shù)上進(jìn)行權(quán)衡分析，并根據(jù)微服務(wù)的上下文和邊界做出明智的決定。

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

示例：考慮一個典型的通知服務(wù)，負(fù)責(zé)通過短信、電子郵件或郵寄的紙質(zhì)信件通知客戶。

讓我們通過分解器驅(qū)動因素對這種情況進(jìn)行分析，并找到合適的大小。我們從以下開始：

1.服務(wù)范圍和功能

服務(wù)是否執(zhí)行了太多無關(guān)的事情？服務(wù)的范圍和功能主要取決于兩個屬性——首先是內(nèi)聚性，即特定服務(wù)操作的程度和方式相互關(guān)聯(lián)。第二個是組件的整體大小，通常用責(zé)任的數(shù)量、服務(wù)的入口點(diǎn)數(shù)量或兩者的組合來衡量。 場景：看看通知服務(wù)，有人可能說將此服務(wù)拆分為三個單一用途的服務(wù)。但這是正確的嗎？答案是否定的！因?yàn)檫@個服務(wù)具有相對強(qiáng)的內(nèi)聚性，即所有這些功能都與一個目標(biāo)相關(guān)，即通知，并且具有一個單一的目的。因此，無需拆分服務(wù)，因?yàn)樗鼞?yīng)該是一個執(zhí)行三個任務(wù)的服務(wù)。接下來是：

2.代碼波動

更改是否僅限于服務(wù)的某一部分？代碼波動是源代碼更改的速率。我們必須衡量服務(wù)中源代碼更改的頻率，這有助于充分理由拆分服務(wù)。

場景：假設(shè)我們對服務(wù)功能有以下指標(biāo)：

現(xiàn)在，如果我們按照更改的度量標(biāo)準(zhǔn)進(jìn)行分析，郵寄信件通知部分的頻繁更改也要求測試短信和電子郵件，因此作為單個服務(wù)，它增加了測試范圍和部署風(fēng)險。那么我們該如何解決呢？

如果我們將此服務(wù)拆分為兩個獨(dú)立服務(wù)，電子通知和郵寄通知，頻繁的更改現(xiàn)在隔離到其自己的服務(wù)中，因此測試范圍減小，部署風(fēng)險降低。

3.可擴(kuò)展性和吞吐量

服務(wù)的部分是否需要以不同的方式擴(kuò)展？可以客觀地測量服務(wù)不同功能的可擴(kuò)展性需求，以量化服務(wù)是否應(yīng)該被拆分。

場景：再次考慮通知服務(wù)示例，測量單個服務(wù)的可擴(kuò)展性需求如下：

在這種情況下，作為單個服務(wù)，電子郵件和郵寄信件功能必須不必要地?cái)U(kuò)展以滿足短信通知的需求，影響成本和彈性，即啟動的平均時間。這完全證明了將通知服務(wù)拆分為獨(dú)立服務(wù)——短信、電子郵件和信件，因?yàn)樗试S每個服務(wù)獨(dú)立擴(kuò)展以滿足其各自不同的吞吐量需求。

4.容錯性

是否存在導(dǎo)致服務(wù)內(nèi)關(guān)鍵功能失敗的錯誤?在特定領(lǐng)域內(nèi)應(yīng)用程序即使發(fā)生致命崩潰(例如OOM)，仍然能夠繼續(xù)運(yùn)行的能力。 場景：考慮到通知服務(wù)的情況，假設(shè)電子郵件功能繼續(xù)出現(xiàn)OOM錯誤并發(fā)生致命崩潰，整個合并服務(wù)會中斷，包括短信和郵寄信件處理。將這個單一的合并通知服務(wù)拆分成三個獨(dú)立服務(wù)為客戶通知領(lǐng)域提供了一定程度的容錯性。因此，電子郵件功能的致命錯誤不會影響短信或郵寄信件。

進(jìn)一步：現(xiàn)在這里可能會出現(xiàn)一個問題，因?yàn)殡娮余]件是唯一與頻繁崩潰有關(guān)的問題，為什么不將短信和郵寄信件功能合并?這是一個合理的問題。如果記得，當(dāng)我們討論代碼波動的情景時，我們將郵寄信件與電子郵件分開，然后將短信和郵寄信件合并成一個——電子通知。如果我們在那里能夠做到這一點(diǎn)，為什么在這里不行呢?因?yàn)殡娮余]件和短信是相關(guān)的，它們都是電子通知的一部分。但在這里，短信和郵寄通知沒有任何共同之處，無法合并。

注意：記住，如果一個服務(wù)因?yàn)樗鼒?zhí)行多個無關(guān)的任務(wù)而難以命名，那么考慮拆分該服務(wù)。其次，無論出于哪種驅(qū)動因素拆分服務(wù)，都要始終檢查是否可以通過“剩余”功能形成強(qiáng)內(nèi)聚性。因此，將通知服務(wù)分解為三個獨(dú)立服務(wù)在這里是有道理的。最后但并非最不重要的驅(qū)動因素是：

5.可擴(kuò)展性

服務(wù)是否始終在擴(kuò)展以添加新功能?在服務(wù)擴(kuò)展時添加附加功能的能力。 場景：假設(shè)我們要向通知服務(wù)添加新功能，例如移動推送通知、桌面通知、社交媒體通知等。這些新功能當(dāng)然可以添加到單個合并的通知服務(wù)中。然而，每次添加新的通知時，整個通知服務(wù)都需要進(jìn)行測試，并且所有通知的功能都需要不必要地部署到生產(chǎn)環(huán)境。

注意：僅在事先知道計(jì)劃并希望將額外的合并功能作為領(lǐng)域的一部分時才應(yīng)用此場景。

推薦做法

• 如果一個服務(wù)因?yàn)閳?zhí)行多個無關(guān)的任務(wù)而難以命名，那么考慮拆分該服務(wù)。
• 無論出于哪種驅(qū)動因素拆分服務(wù)，都要始終檢查是否可以通過“剩余”功能形成強(qiáng)內(nèi)聚性。
• 拆分服務(wù)時，根據(jù)業(yè)務(wù)能力而不是技術(shù)能力進(jìn)行檢查。
• 在設(shè)計(jì)微服務(wù)時使用單一職責(zé)原則(SRP)，但要牢記強(qiáng)內(nèi)聚性的全局圖景。
• 最后，使用分解器驅(qū)動因素分析拆分服務(wù)的權(quán)衡。