建站
咨詢
售后
建站咨詢
新聞中心
?微服務，是一種新型的應用架構(gòu)術(shù)語，而最準確的定義來自于兩位大神（James Lewis和Martin Fowler）。
臨滄ssl適用于網(wǎng)站、小程序/APP、API接口等需要進行數(shù)據(jù)傳輸應用場景，ssl證書未來市場廣闊！成為成都創(chuàng)新互聯(lián)公司的ssl證書銷售渠道，可以享受市場價格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：18980820575（備注：SSL證書合作）期待與您的合作！
原文翻譯后，簡單來說就是：將軟件應用程序設(shè)計為可獨立部署運行的一種方式。這些服務主要圍繞業(yè)務能力進行構(gòu)建，可以采用不同的編程語言和不同的數(shù)據(jù)存儲技術(shù)，并且在組織架構(gòu)上存在一些共同的特征。
當下，越來越多的組織在應用架構(gòu)上逐步從單體架構(gòu)再向微服務架構(gòu)進行演進，殊不知，盲目的跟風，只會讓軟件開發(fā)及運維成本日益劇增，我們應該始終堅持以“拆是手段，合是目的”為原則，從而提升應用交付效能，實現(xiàn)可持續(xù)演進的架構(gòu)體系。
今天就跟大家來講一講，我在日常工作中常用的一些微服務設(shè)計參考，但我想說，它并不是萬能的，也不是絕對的，所以不要指望它，能解決你所有的微服務設(shè)計問題，而且，有時候還需要考慮一些客觀因素的存在，特別是歷史遺留系統(tǒng)。
指南一：服務無狀態(tài)
微服務內(nèi)部應確保為無狀態(tài)，即：將有狀態(tài)信息從微服務中進行剝離，從而單純的成為一個無狀態(tài)的計算節(jié)點，以便可快速實現(xiàn)動態(tài)伸縮的橫向擴展能力，同時對應用系統(tǒng)不產(chǎn)生額外的成本投入或代碼侵入。例如：將會話信息剝離出來，放入分布式緩存中托管。
指南二：前后端分離
傳統(tǒng)的應用通常會將前端代碼與后端代碼融合在一起，導致前后端代碼強耦合，不便于后續(xù)的管理維護，建議進行前后端分離，前端更強調(diào)的是交互體驗和靈活性，而后端更強調(diào)的是能力抽象和穩(wěn)定性，而微服務僅承接后端服務或者接口，不承接前端展現(xiàn)或渲染。
指南三：業(yè)務抽象化
通常設(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)系進行微服務拆分，但微服務一般適用于解決業(yè)務復雜度較高的場景，建議從業(yè)務視角，采用領(lǐng)域驅(qū)動這種自上而下的設(shè)計模式，更強調(diào)的是業(yè)務能力，即：優(yōu)先明確業(yè)務場景，然后再根據(jù)業(yè)務場景建立統(tǒng)一語言，并對業(yè)務概念進行邊界定義。
指南四：用例收斂性
根據(jù)業(yè)務場景流程需要識別微服務間的調(diào)用關(guān)系，并對其進一步進行合理性的驗證，在通常情況下我們建議用例跨越的服務越少越好，一方面能夠降低系統(tǒng)的響應延遲，另一方面能夠減少服務之間的依賴程度，若依賴鏈路過長，那么依賴鏈條上的任何一個微服務發(fā)生變更，其鏈條后的任何微服務均可能需要改變。
指南五：實體收斂性
在某些業(yè)務場景下，需要兩個或多個微服務間針對某個實體信息進行單向或雙向同步，即：某個實體由多個微服務來管理，從而降低微服務間的依賴程度，但可能會引發(fā)數(shù)據(jù)一致性的問題，建議相同的實體所跨越的微服務不能太多，實體參與同步的微服務越多，其數(shù)據(jù)一致性問題就越容易暴露。
指南六：高內(nèi)聚特性
微服務的內(nèi)聚性越高，設(shè)計模型的可理解性就越強，根據(jù)業(yè)務流程和場景識別所有實體后，需對實體間進行關(guān)系分析，優(yōu)先識別出生命周期一致的實體進行歸類，然后根據(jù)實體與聚合根的區(qū)別，明確每個聚合根的邊界，微服務的最小單元通常是一個聚合根，可根據(jù)技術(shù)成本來評估并確定一個微服務中包括幾個聚合根，但不建議對一個聚合根進行割裂。
|
類型 |
唯一標識 |
生命周期 |
是否只讀 |
判斷相等 |
|
聚合根 |
全局唯一 |
獨立生命周期 |
否 |
標識 |
|
實體 |
聚合內(nèi)唯一 |
從屬對應的聚合根 |
否 |
標識 |
|
值對象 |
無唯一標識 |
無生命周期 |
是 |
屬性 |
指南七：低耦合特性
微服務的耦合性越低，設(shè)計模型就能更快適應系統(tǒng)需求的變化，若微服務間聯(lián)系越緊密，其獨立性就會變得越差，微服務的管控治理也會變得十分困難，例如：某個微服務契約發(fā)生變化后，那么依賴的微服務將都會受到影響，因此需要深度分析微服務間的調(diào)用關(guān)系強弱，并根據(jù)依賴的強弱梳理上下游關(guān)系，從而將此影響減少到最低。
指南八：先垂直劃分
以業(yè)務領(lǐng)域視角對服務進行垂直拆分，在屏蔽任何技術(shù)實現(xiàn)細節(jié)的情況下，先對業(yè)務能力進行服務分類，然后再根據(jù)服務間的關(guān)聯(lián)程度將其劃分到一個微服務中，其滿足每個微服務僅承擔一類業(yè)務能力，且后續(xù)僅因這類業(yè)務發(fā)生變化而變化，以及這些變化盡可能在一個微服務中閉環(huán)完成，不需要影響其他服務，最后再根據(jù)拆分后所引入的技術(shù)債務進行權(quán)衡決定是否合并。
指南九：后水平劃分
以非功能性視角對微服務進行水平拆分，通常會從服務的隔離性、可靠性、擴展性等幾個方面進行綜合評估考慮?？筛鶕?jù)迭代的變化速率進行拆分，避免敏態(tài)服務的改動升級影響穩(wěn)態(tài)服務，根據(jù)業(yè)務的服務水平進行拆分，在出現(xiàn)故障時優(yōu)先確保關(guān)鍵核心服務的正常運作，根據(jù)服務的性能要求進行拆分，避免因性能隔離性問題導致服務整體癱瘓，最后再根據(jù)拆分后所引入的技術(shù)債務進行權(quán)衡決定是否合并。
指南十：自組織能力
自組織能力是實施微服務的關(guān)鍵所在，每一個團隊需要對微服務的整個生命周期負責，所有團隊成員的工作能夠在獨立的微服務上下文中，即：微服務應用架構(gòu)需要盡可能的適配團隊間的組織架構(gòu)，從而能夠獨立決策獨立治理，而團隊和團隊之間也是以一種松耦合性的方式進行交互連接。
綜上所列，是我常用的一些招數(shù)，希望它能夠?qū)δ阌兴鶐椭?，但請永遠記住，「拆」永遠不是目的，它是一種手段，通過「拆」，是讓微服務間能夠更好的協(xié)同工作，最終達到「合」的效果。?
網(wǎng)頁標題：微服務設(shè)計的十條參考指南
分享URL：http://www.5511xx.com/article/cdjcisj.html
