前言

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

顆粒度

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

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

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

顆粒度分解器

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

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

顆粒度分解器

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

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

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

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

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

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

2.代碼波動(dòng)

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

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

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

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

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

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

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

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

4.容錯(cuò)性

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

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

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

5.可擴(kuò)展性

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

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

推薦做法

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