?微服務，是一種新型的應用架構術語，而最準確的定義來自于兩位大神（James Lewis和Martin Fowler）。

原文翻譯后，簡單來說就是：將軟件應用程序設計為可獨立部署運行的一種方式。這些服務主要圍繞業務能力進行構建，可以采用不同的編程語言和不同的數據存儲技術，并且在組織架構上存在一些共同的特征。

當下，越來越多的組織在應用架構上逐步從單體架構再向微服務架構進行演進，殊不知，盲目的跟風，只會讓軟件開發及運維成本日益劇增，我們應該始終堅持以“拆是手段，合是目的”為原則，從而提升應用交付效能，實現可持續演進的架構體系。

今天就跟大家來講一講，我在日常工作中常用的一些微服務設計參考，但我想說，它并不是萬能的，也不是絕對的，所以不要指望它，能解決你所有的微服務設計問題，而且，有時候還需要考慮一些客觀因素的存在，特別是歷史遺留系統。

指南一：服務無狀態

微服務內部應確保為無狀態，即：將有狀態信息從微服務中進行剝離，從而單純的成為一個無狀態的計算節點，以便可快速實現動態伸縮的橫向擴展能力，同時對應用系統不產生額外的成本投入或代碼侵入。例如：將會話信息剝離出來，放入分布式緩存中托管。

指南二：前后端分離

傳統的應用通常會將前端代碼與后端代碼融合在一起，導致前后端代碼強耦合，不便于后續的管理維護，建議進行前后端分離，前端更強調的是交互體驗和靈活性，而后端更強調的是能力抽象和穩定性，而微服務僅承接后端服務或者接口，不承接前端展現或渲染。

指南三：業務抽象化

通常設計人員會站在技術視角，采用數據驅動這種自下而上的設計模式，強調的是數據結構，即：優先確定數據結構，然后再根據數據結構的關系進行微服務拆分，但微服務一般適用于解決業務復雜度較高的場景，建議從業務視角，采用領域驅動這種自上而下的設計模式，更強調的是業務能力，即：優先明確業務場景，然后再根據業務場景建立統一語言，并對業務概念進行邊界定義。

指南四：用例收斂性

根據業務場景流程需要識別微服務間的調用關系，并對其進一步進行合理性的驗證，在通常情況下我們建議用例跨越的服務越少越好，一方面能夠降低系統的響應延遲，另一方面能夠減少服務之間的依賴程度，若依賴鏈路過長，那么依賴鏈條上的任何一個微服務發生變更，其鏈條后的任何微服務均可能需要改變。

指南五：實體收斂性

在某些業務場景下，需要兩個或多個微服務間針對某個實體信息進行單向或雙向同步，即：某個實體由多個微服務來管理，從而降低微服務間的依賴程度，但可能會引發數據一致性的問題，建議相同的實體所跨越的微服務不能太多，實體參與同步的微服務越多，其數據一致性問題就越容易暴露。

指南六：高內聚特性

微服務的內聚性越高，設計模型的可理解性就越強，根據業務流程和場景識別所有實體后，需對實體間進行關系分析，優先識別出生命周期一致的實體進行歸類，然后根據實體與聚合根的區別，明確每個聚合根的邊界，微服務的最小單元通常是一個聚合根，可根據技術成本來評估并確定一個微服務中包括幾個聚合根，但不建議對一個聚合根進行割裂。

指南七：低耦合特性

微服務的耦合性越低，設計模型就能更快適應系統需求的變化，若微服務間聯系越緊密，其獨立性就會變得越差，微服務的管控治理也會變得十分困難，例如：某個微服務契約發生變化后，那么依賴的微服務將都會受到影響，因此需要深度分析微服務間的調用關系強弱，并根據依賴的強弱梳理上下游關系，從而將此影響減少到最低。

指南八：先垂直劃分

以業務領域視角對服務進行垂直拆分，在屏蔽任何技術實現細節的情況下，先對業務能力進行服務分類，然后再根據服務間的關聯程度將其劃分到一個微服務中，其滿足每個微服務僅承擔一類業務能力，且后續僅因這類業務發生變化而變化，以及這些變化盡可能在一個微服務中閉環完成，不需要影響其他服務，最后再根據拆分后所引入的技術債務進行權衡決定是否合并。

指南九：后水平劃分

以非功能性視角對微服務進行水平拆分，通常會從服務的隔離性、可靠性、擴展性等幾個方面進行綜合評估考慮。可根據迭代的變化速率進行拆分，避免敏態服務的改動升級影響穩態服務，根據業務的服務水平進行拆分，在出現故障時優先確保關鍵核心服務的正常運作，根據服務的性能要求進行拆分，避免因性能隔離性問題導致服務整體癱瘓，最后再根據拆分后所引入的技術債務進行權衡決定是否合并。

指南十：自組織能力

自組織能力是實施微服務的關鍵所在，每一個團隊需要對微服務的整個生命周期負責，所有團隊成員的工作能夠在獨立的微服務上下文中，即：微服務應用架構需要盡可能的適配團隊間的組織架構，從而能夠獨立決策獨立治理，而團隊和團隊之間也是以一種松耦合性的方式進行交互連接。

綜上所列，是我常用的一些招數，希望它能夠對你有所幫助，但請永遠記住，「拆」永遠不是目的，它是一種手段，通過「拆」，是讓微服務間能夠更好的協同工作，最終達到「合」的效果。?