微服務(wù)化之后普遍的垂直電商系統(tǒng)的架構(gòu)將會(huì)變成下面這樣：

圖片

在這一架構(gòu)中，我們的目標(biāo)是將與用戶、訂單和商品相關(guān)的邏輯拆分成獨(dú)立的服務(wù)，以取代原有的直接依賴緩存和數(shù)據(jù)庫(kù)的Web工程和隊(duì)列處理程序。為了迅速實(shí)現(xiàn)服務(wù)化拆分，我們決定召集主力研發(fā)同事來一同制定拆分計(jì)劃。然而，在深入討論后，我們發(fā)現(xiàn)仍有許多未解之謎，例如：

1. 服務(wù)拆分原則：我們需要確定拆分服務(wù)時(shí)應(yīng)遵循哪些原則，以確保每個(gè)微服務(wù)的獨(dú)立性和可維護(hù)性。
2. 服務(wù)邊界的確定：如何明確定義每個(gè)微服務(wù)的邊界，以避免微服務(wù)之間的不必要耦合？
3. 服務(wù)粒度：我們需要明確微服務(wù)的粒度應(yīng)該是多大，以便更好地管理和維護(hù)它們。
4. 潛在問題：在實(shí)施服務(wù)化之后，我們可能會(huì)面臨性能、安全性、版本管理和通信等方面的問題，需要提前考慮并準(zhǔn)備相應(yīng)的解決方案。

這些問題將直接影響我們的服務(wù)化拆分計(jì)劃的效果。因此，我們需要認(rèn)真思考并找到答案，以確保成功實(shí)施這一重要的架構(gòu)變革。

微服務(wù)拆分的原則

以前我們維護(hù)的一體化架構(gòu)就像一個(gè)錯(cuò)綜復(fù)雜的大蜘蛛網(wǎng)，各種不同功能模塊緊密相連，方法之間的調(diào)用關(guān)系錯(cuò)綜復(fù)雜，因此修復(fù)一個(gè)Bug可能會(huì)觸發(fā)多個(gè)新Bug。這種維護(hù)復(fù)雜度極高，同時(shí)數(shù)據(jù)庫(kù)的擴(kuò)展性也受到限制，制約了系統(tǒng)的擴(kuò)展能力。出于以上原因，我們決定對(duì)架構(gòu)進(jìn)行拆分。

然而，拆分并不是一項(xiàng)輕松的任務(wù)，實(shí)際上，它相當(dāng)于對(duì)整個(gè)工程進(jìn)行了重構(gòu)，甚至需要重寫部分代碼。我們需要將現(xiàn)有的代碼拆分成若干個(gè)子工程，然后通過某種通信方式將這些子工程組裝在一起。這是一項(xiàng)復(fù)雜的架構(gòu)調(diào)整工作，需要多個(gè)團(tuán)隊(duì)之間的緊密協(xié)作和協(xié)同努力來完成。

所以在開始拆分之前你需要明確幾個(gè)拆分的原則，否則就會(huì)事倍功半甚至對(duì)整體項(xiàng)目產(chǎn)生不利的影響。

首要原則是確保每個(gè)單一服務(wù)內(nèi)部擁有高內(nèi)聚性和低耦合性。這意味著每個(gè)服務(wù)應(yīng)只承擔(dān)其職責(zé)內(nèi)的任務(wù)，不應(yīng)處理不屬于自身職責(zé)范圍的功能。雖然這聽起來可能理所當(dāng)然，但在實(shí)際開發(fā)中，很多人往往會(huì)犯這方面的錯(cuò)誤。

舉例來說，在我的之前的項(xiàng)目中，我們有用戶服務(wù)和內(nèi)容服務(wù)。用戶信息中包含一個(gè)“是否認(rèn)證用戶”的字段。有一位同事在內(nèi)容服務(wù)中添加了如下邏輯：如果用戶認(rèn)證字段等于1，表示是認(rèn)證用戶，則提升內(nèi)容的權(quán)重。問題在于，判斷用戶是否認(rèn)證用戶的邏輯應(yīng)當(dāng)內(nèi)聚在用戶服務(wù)內(nèi)部，而不應(yīng)該由內(nèi)容服務(wù)進(jìn)行判斷。否則，一旦認(rèn)證邏輯發(fā)生變化，內(nèi)容服務(wù)也必須相應(yīng)變更，這違反了高內(nèi)聚和低耦合的原則。

幸運(yùn)的是，在我們進(jìn)行代碼審查時(shí)及時(shí)發(fā)現(xiàn)了這個(gè)問題，因此我們?cè)诜?wù)上線之前對(duì)其進(jìn)行了修復(fù)。這個(gè)例子強(qiáng)調(diào)了確保高內(nèi)聚和低耦合的重要性，以防止服務(wù)之間的過度依賴和不必要的復(fù)雜性。

第二個(gè)原則是關(guān)注服務(wù)拆分的粒度，最初應(yīng)該進(jìn)行粗略拆分，然后逐漸細(xì)化。在服務(wù)拆分的早期階段，很難確定服務(wù)應(yīng)該拆分成什么樣子。盡管“微服務(wù)”這個(gè)術(shù)語(yǔ)暗示服務(wù)的粒度應(yīng)該非常小，甚至有“一方法一服務(wù)”的說法，但服務(wù)數(shù)量的增加也會(huì)引發(fā)一些問題，如增加了運(yùn)維成本。

此外，如果原本的請(qǐng)求需要調(diào)用進(jìn)程內(nèi)的多個(gè)方法，而現(xiàn)在需要跨網(wǎng)絡(luò)調(diào)用多個(gè)RPC服務(wù)，性能可能會(huì)受到影響。因此，我建議的做法是，在拆分初期，可以將服務(wù)的粒度保持較粗，隨著團(tuán)隊(duì)對(duì)業(yè)務(wù)和微服務(wù)理念的逐漸深入理解，再考慮逐步細(xì)化服務(wù)的粒度。例如，對(duì)于社區(qū)系統(tǒng)，您可以先將與用戶關(guān)系相關(guān)的業(yè)務(wù)邏輯粗略拆分到用戶關(guān)系服務(wù)中，然后再將例如黑名單邏輯獨(dú)立拆分為黑名單服務(wù)。這樣的方法有助于平衡微服務(wù)的數(shù)量和復(fù)雜性。

原則三，拆分的過程，要盡量避免影響產(chǎn)品的日常功能迭代。也就是說，要一邊做產(chǎn)品功能迭代，一邊完成服務(wù)化拆分。

第四個(gè)原則是要確保服務(wù)接口的定義具有可擴(kuò)展性。在進(jìn)行服務(wù)拆分后，由于服務(wù)獨(dú)立部署在不同的進(jìn)程中，服務(wù)之間的通信不再是進(jìn)程內(nèi)部的方法調(diào)用，而是跨進(jìn)程的網(wǎng)絡(luò)通信。在這種通信模型下，服務(wù)接口的定義必須具有可擴(kuò)展性，以防止在服務(wù)發(fā)生變化時(shí)引發(fā)意外錯(cuò)誤。

微服務(wù)化帶來的問題和解決思路

微服務(wù)化只是一種架構(gòu)手段，有效拆分后可以幫助實(shí)現(xiàn)服務(wù)的敏捷開發(fā)和部署。但是由于將原本一體化架構(gòu)的應(yīng)用拆分成了多個(gè)通過網(wǎng)絡(luò)通信的分布式服務(wù)，為了在分布式環(huán)境下協(xié)調(diào)多個(gè)服務(wù)正常運(yùn)行，就必然引入一定的復(fù)雜度，這些復(fù)雜度主要體現(xiàn)在以下幾個(gè)方面：

在微服務(wù)架構(gòu)中，服務(wù)接口的調(diào)用不再是同一進(jìn)程內(nèi)的方法調(diào)用，而是跨進(jìn)程的網(wǎng)絡(luò)調(diào)用，這可能導(dǎo)致接口響應(yīng)時(shí)間的增加。為了解決這個(gè)問題，我們需要選擇高效的服務(wù)調(diào)用框架。此外，接口調(diào)用方還需要知道目標(biāo)服務(wù)部署在哪些機(jī)器上以及哪個(gè)端口上。這些信息需要存儲(chǔ)在一個(gè)分布式一致性的存儲(chǔ)中，這就是服務(wù)注冊(cè)中心的作用。

在微服務(wù)架構(gòu)中，多個(gè)服務(wù)之間存在復(fù)雜的相互依賴關(guān)系。一個(gè)服務(wù)可能會(huì)被多個(gè)其他服務(wù)所依賴，同時(shí)也會(huì)依賴于多個(gè)服務(wù)。當(dāng)被依賴的服務(wù)出現(xiàn)性能問題，導(dǎo)致產(chǎn)生大量的慢請(qǐng)求時(shí)，這會(huì)占用依賴服務(wù)的工作線程池中的線程，進(jìn)而導(dǎo)致依賴服務(wù)也出現(xiàn)性能問題。

在微服務(wù)架構(gòu)中，一個(gè)請(qǐng)求的調(diào)用鏈涉及多個(gè)服務(wù)，因此如果該請(qǐng)求的響應(yīng)時(shí)間增長(zhǎng)或出現(xiàn)錯(cuò)誤，很難迅速確定是哪個(gè)服務(wù)引發(fā)了問題。此外，當(dāng)整個(gè)系統(tǒng)出現(xiàn)故障時(shí)，所有服務(wù)可能都在同一時(shí)間內(nèi)受到影響，這使得難以確認(rèn)問題的根本原因。

總的來說，微服務(wù)架構(gòu)是一個(gè)廣泛而深刻的話題。雖然你可以相對(duì)迅速地將服務(wù)進(jìn)行拆分，但構(gòu)建和維護(hù)一個(gè)健全的服務(wù)治理體系可能需要較長(zhǎng)時(shí)間。在接下來的內(nèi)容中，我們將探討一些常用的微服務(wù)中間件的原理和使用方法。

為更好理解這些內(nèi)容，建議采取以下步驟：

1. 快速部署和運(yùn)行中間件：首先迅速部署并運(yùn)行這些中間件，以建立對(duì)它們的感性認(rèn)識(shí)。這將幫助你熟悉它們的基本用法。
2. 閱讀文檔：深入閱讀中間件的文檔，特別是關(guān)于基本原理和架構(gòu)設(shè)計(jì)的部分。這將為你提供更深入的理解。
3. 閱讀源碼：如有必要，嘗試閱讀中間件的源代碼。這可以幫助你更深入地理解它們的工作原理，有助于排查中間件可能引發(fā)的故障和解決性能問題。

微服務(wù)化拆分的原則

康威定律"強(qiáng)調(diào)了組織結(jié)構(gòu)和系統(tǒng)架構(gòu)之間的密切關(guān)系。簡(jiǎn)而言之，你的團(tuán)隊(duì)組織結(jié)構(gòu)會(huì)直接影響你的系統(tǒng)架構(gòu)。如果你的團(tuán)隊(duì)劃分為服務(wù)端開發(fā)團(tuán)隊(duì)、DBA 團(tuán)隊(duì)、運(yùn)維團(tuán)隊(duì)和測(cè)試團(tuán)隊(duì)等，那么你的架構(gòu)可能會(huì)更趨向一體化，所有團(tuán)隊(duì)成員共同管理一個(gè)大型系統(tǒng)，這會(huì)增加內(nèi)部團(tuán)隊(duì)間的溝通成本。

然而，如果你的目標(biāo)是實(shí)現(xiàn)微服務(wù)架構(gòu)，那么你需要將團(tuán)隊(duì)按照業(yè)務(wù)邊界進(jìn)行劃分，每個(gè)小團(tuán)隊(duì)負(fù)責(zé)一個(gè)自治的模塊。每個(gè)小團(tuán)隊(duì)內(nèi)部包括開發(fā)、測(cè)試、運(yùn)維和DBA成員，這樣溝通主要發(fā)生在小團(tuán)隊(duì)內(nèi)部，極大降低了溝通成本。

微服務(wù)架構(gòu)的一個(gè)目標(biāo)是降低開發(fā)成本，包括溝通成本。因此，小團(tuán)隊(duì)內(nèi)的成員不宜過多。根據(jù)亞馬遜CEO貝佐斯的“兩個(gè)披薩”的理論，一個(gè)小團(tuán)隊(duì)最佳的成員數(shù)量是6到8人。

如果你的團(tuán)隊(duì)規(guī)模不大，尚未準(zhǔn)備好實(shí)施微服務(wù)架構(gòu)，但感受到研發(fā)和部署成本較高，可以采用一個(gè)中間的策略，先著重拆分工程結(jié)構(gòu)，以降低溝通成本和提高靈活性。這有助于逐步邁向微服務(wù)架構(gòu)，同時(shí)減少短期內(nèi)的復(fù)雜性。

舉例來說，如果你使用Java語(yǔ)言，可以考慮根據(jù)業(yè)務(wù)邊界將代碼拆分到不同的子工程中。這些子工程可以作為獨(dú)立的模塊，通過jar包的方式相互依賴。這種做法有以下好處：

1. 減少打包時(shí)間：每個(gè)子工程的代碼量減少，編譯和打包時(shí)間相對(duì)較短，從而提高開發(fā)效率。
2. 高內(nèi)聚低耦合：子工程內(nèi)部可以更好地實(shí)現(xiàn)高內(nèi)聚和低耦合，使代碼更易于維護(hù)和擴(kuò)展。
3. 逐步拆分：這是一個(gè)保守的策略，允許你逐步將代碼拆分為更小的模塊，而不需要一次性完全改變架構(gòu)。這可以降低風(fēng)險(xiǎn)，逐漸邁向微服務(wù)架構(gòu)。