微服務化之后普遍的垂直電商系統的架構將會變成下面這樣：

圖片

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

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

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

微服務拆分的原則

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

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

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

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

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

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

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

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

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

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

微服務化帶來的問題和解決思路

微服務化只是一種架構手段，有效拆分后可以幫助實現服務的敏捷開發和部署。但是由于將原本一體化架構的應用拆分成了多個通過網絡通信的分布式服務，為了在分布式環境下協調多個服務正常運行，就必然引入一定的復雜度，這些復雜度主要體現在以下幾個方面：

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

在微服務架構中，多個服務之間存在復雜的相互依賴關系。一個服務可能會被多個其他服務所依賴，同時也會依賴于多個服務。當被依賴的服務出現性能問題，導致產生大量的慢請求時，這會占用依賴服務的工作線程池中的線程，進而導致依賴服務也出現性能問題。

在微服務架構中，一個請求的調用鏈涉及多個服務，因此如果該請求的響應時間增長或出現錯誤，很難迅速確定是哪個服務引發了問題。此外，當整個系統出現故障時，所有服務可能都在同一時間內受到影響，這使得難以確認問題的根本原因。

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

為更好理解這些內容，建議采取以下步驟：

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

微服務化拆分的原則

康威定律"強調了組織結構和系統架構之間的密切關系。簡而言之，你的團隊組織結構會直接影響你的系統架構。如果你的團隊劃分為服務端開發團隊、DBA 團隊、運維團隊和測試團隊等，那么你的架構可能會更趨向一體化，所有團隊成員共同管理一個大型系統，這會增加內部團隊間的溝通成本。

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

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

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

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

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