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

圖片

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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