序言

在微服務(wù)架構(gòu)風(fēng)格中，微服務(wù)通常設(shè)計遵循SRP（單一職責(zé)原則），作為一個獨立部署的軟件單元，專注于做一件事，并且做到極致。作為開發(fā)人員，我們常常傾向于在沒有考慮為什么的情況下盡可能地將服務(wù)做得小。這種關(guān)于什么是和不是什么是單一職責(zé)的主觀性是我們開發(fā)人員在服務(wù)粒度方面容易犯錯誤的地方。為了克服開發(fā)團(tuán)隊在微服務(wù)尺寸上面臨的這種困境，理解粒度驅(qū)動因素至關(guān)重要。

粒度

在微服務(wù)中，我們有兩個概念——模塊化，涉及將系統(tǒng)分解成獨立部分，另一個是粒度，處理這些獨立部分的大小。

確定正確的粒度水平——服務(wù)的大小——是微服務(wù)架構(gòu)中我們開發(fā)人員苦苦掙扎的眾多難點之一。粒度不是由服務(wù)中的類的數(shù)量或代碼行數(shù)來定義的，而是由服務(wù)的職責(zé)來定義的——因此，找到服務(wù)粒度的正確之道存在困惑。

服務(wù)的粒度分為兩種對立的力量——粒度解耦器和粒度整合器。

粒度解耦器

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

粒度整合器

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

粒度解耦器

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

粒度解耦驅(qū)動因素提供了何時將服務(wù)拆分成更小部分的指導(dǎo)和依據(jù)。讓我們看看這些驅(qū)動因素如何影響微服務(wù)的尺寸，以一個例子為例。

示例：考慮一個典型的通知服務(wù)，它執(zhí)行三項操作：通過短信、電子郵件或郵寄信件通知客戶。

讓我們在解耦驅(qū)動因素上分析這個場景，并找到合適的尺寸。我們從：

服務(wù)范圍和功能

服務(wù)是否在做太多不相關(guān)的事情？ 范圍和功能主要取決于兩個屬性——第一個是內(nèi)聚性，指的是特定服務(wù)操作之間的相互關(guān)系的程度和方式。第二個是組件的總體大小，通常以職責(zé)數(shù)量、服務(wù)的入口點數(shù)量或兩者的綜合來衡量。 場景：觀察通知服務(wù)，有人可能會說將這個服務(wù)拆分成三個單獨的單一職責(zé)服務(wù)。但這是正確的做法嗎？答案是否定的！因為這個服務(wù)具有相對較強(qiáng)的內(nèi)聚性，即所有這些功能都與一件事有關(guān)，即通知，并且具有一個單一的目的。所以，不需要拆分這個服務(wù)，它應(yīng)該是一個服務(wù)執(zhí)行三項操作。 接下來是：

代碼波動性

更改是否僅限于服務(wù)的一部分？ 代碼波動性是源代碼更改的頻率。我們必須衡量服務(wù)中代碼更改的頻率，以合理解釋為什么要拆分服務(wù)。 場景：假設(shè)我們有以下服務(wù)功能的指標(biāo)：

現(xiàn)在，如果我們依據(jù)更改的指標(biāo)來看，郵寄信件通知部分的頻繁更改也需要測試短信和電子郵件部分，從而作為單一服務(wù)，這增加了測試范圍和部署風(fēng)險。那么我們?nèi)绾谓鉀Q這個問題呢？

如果我們將這個服務(wù)拆分成兩個單獨的服務(wù)，電子通知和郵寄信件通知，那么頻繁的更改現(xiàn)在被隔離在自己的服務(wù)中，從而減少了測試范圍并降低了部署風(fēng)險。

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

服務(wù)的部分是否需要不同的擴(kuò)展能力？ 不同服務(wù)功能的可擴(kuò)展性需求可以客觀地測量，以量化服務(wù)是否應(yīng)拆分。 場景：再次考慮通知服務(wù)示例，測量單個服務(wù)的可擴(kuò)展性需求如下：

在這種情況下，作為一個單一服務(wù)，電子郵件和郵寄信件功能必須不必要地擴(kuò)展以滿足短信通知的需求，從而影響成本和彈性（如MTTS，即平均啟動時間）。這完全合理地解釋了將通知服務(wù)拆分成獨立的服務(wù)——短信、電子郵件和信件，因為這樣可以讓每個服務(wù)獨立擴(kuò)展以滿足它們不同的吞吐量需求。

容錯性

是否存在導(dǎo)致服務(wù)關(guān)鍵功能失敗的錯誤？ 應(yīng)用程序在特定領(lǐng)域內(nèi)繼續(xù)運(yùn)行的能力，即使發(fā)生了致命崩潰（如OOM）。 場景：考慮我們的通知服務(wù)場景，假設(shè)電子郵件功能繼續(xù)出現(xiàn)OOM錯誤并致命崩潰，整個整合服務(wù)將會癱瘓，包括短信和郵寄信件處理。 將這個單一的整合通知服務(wù)拆分成三個獨立的服務(wù)，為客戶通知領(lǐng)域提供了一定的容錯性。因此，電子郵件功能中的致命錯誤不會影響短信或郵寄信件。 進(jìn)一步說明：現(xiàn)在，這里可能會出現(xiàn)一個問題，因為電子郵件功能頻繁崩潰，為什么不將短信和郵寄信件功能合并？這是一個有效的問題。如果我們記得，當(dāng)我們討論代碼波動性場景時，我們將郵寄信件與電子郵件和短信分開，并將它們合并成一個——電子通知。如果我們在那里能這樣做，我們也可以在這里這樣做。那么，為什么不呢？ 因為電子郵件和短信是相關(guān)的，它們都是電子通知方式。但在這里，短信和郵寄通知沒有任何共同之處可以將它們合并。換句話說，這里沒有內(nèi)聚性。

注意：記住，如果一個服務(wù)難以命名，因為它在做多個不相關(guān)的事情，那么考慮拆分服務(wù)。第二，每當(dāng)拆分服務(wù)時，無論驅(qū)動因素是什么，總是檢查是否可以與“剩余”功能形成強(qiáng)烈的內(nèi)聚性。 所以，在這里將通知服務(wù)拆分成三個獨立的服務(wù)是有意義的。 最后一個驅(qū)動因素是：

可擴(kuò)展性

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

注意：僅當(dāng)事先知道計劃和希望作為域的一部分的額外整合功能時，才應(yīng)用此場景。

推薦實踐

1.如果一個服務(wù)難以命名，因為它在做多個不相關(guān)的事情，那么考慮拆分服務(wù)。2.每當(dāng)拆分服務(wù)時，無論驅(qū)動因素是什么，總是檢查是否可以與“剩余”功能形成強(qiáng)烈的內(nèi)聚性。3.根據(jù)業(yè)務(wù)能力而不是技術(shù)能力拆分服務(wù)。4.在設(shè)計微服務(wù)時使用單一職責(zé)原則（SRP），但要牢記強(qiáng)內(nèi)聚性的全景。5.使用解耦驅(qū)動因素分析拆分服務(wù)的權(quán)衡。