?微服務(wù)，是一種新型的應(yīng)用架構(gòu)術(shù)語，而最準確的定義來自于兩位大神（James Lewis和Martin Fowler）。

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

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

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

指南一：服務(wù)無狀態(tài)

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

指南二：前后端分離

傳統(tǒng)的應(yīng)用通常會將前端代碼與后端代碼融合在一起，導(dǎo)致前后端代碼強耦合，不便于后續(xù)的管理維護，建議進行前后端分離，前端更強調(diào)的是交互體驗和靈活性，而后端更強調(diào)的是能力抽象和穩(wěn)定性，而微服務(wù)僅承接后端服務(wù)或者接口，不承接前端展現(xiàn)或渲染。

指南三：業(yè)務(wù)抽象化

通常設(shè)計人員會站在技術(shù)視角，采用數(shù)據(jù)驅(qū)動這種自下而上的設(shè)計模式，強調(diào)的是數(shù)據(jù)結(jié)構(gòu)，即：優(yōu)先確定數(shù)據(jù)結(jié)構(gòu)，然后再根據(jù)數(shù)據(jù)結(jié)構(gòu)的關(guān)系進行微服務(wù)拆分，但微服務(wù)一般適用于解決業(yè)務(wù)復(fù)雜度較高的場景，建議從業(yè)務(wù)視角，采用領(lǐng)域驅(qū)動這種自上而下的設(shè)計模式，更強調(diào)的是業(yè)務(wù)能力，即：優(yōu)先明確業(yè)務(wù)場景，然后再根據(jù)業(yè)務(wù)場景建立統(tǒng)一語言，并對業(yè)務(wù)概念進行邊界定義。

指南四：用例收斂性

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

指南五：實體收斂性

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

指南六：高內(nèi)聚特性

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

指南七：低耦合特性

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

指南八：先垂直劃分

以業(yè)務(wù)領(lǐng)域視角對服務(wù)進行垂直拆分，在屏蔽任何技術(shù)實現(xiàn)細節(jié)的情況下，先對業(yè)務(wù)能力進行服務(wù)分類，然后再根據(jù)服務(wù)間的關(guān)聯(lián)程度將其劃分到一個微服務(wù)中，其滿足每個微服務(wù)僅承擔(dān)一類業(yè)務(wù)能力，且后續(xù)僅因這類業(yè)務(wù)發(fā)生變化而變化，以及這些變化盡可能在一個微服務(wù)中閉環(huán)完成，不需要影響其他服務(wù)，最后再根據(jù)拆分后所引入的技術(shù)債務(wù)進行權(quán)衡決定是否合并。

指南九：后水平劃分

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

指南十：自組織能力

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

綜上所列，是我常用的一些招數(shù)，希望它能夠?qū)δ阌兴鶐椭?，但請永遠記住，「拆」永遠不是目的，它是一種手段，通過「拆」，是讓微服務(wù)間能夠更好的協(xié)同工作，最終達到「合」的效果。?