新聞中心
如果您在設計大型并發(fā)應用程序或者準備拆解之前的老系統(tǒng)時,我想你第一考慮的是微服務架構方式。

我們提供的服務有:網(wǎng)站設計、網(wǎng)站建設、微信公眾號開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認證、樺甸ssl等。為近千家企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務,是有科學管理、有技術的樺甸網(wǎng)站制作公司
前面我們了解到微服務架構將應用程序構建為一系列松散耦合的服務,是為了通過實現(xiàn)持續(xù)交付和靈活部署來加速軟件開發(fā)。
出于很原因,分解很重要
- 有利于分工和知識共享。使用它,具有特殊知識的多個人(或團隊)可以在一個應用程序上高效地合作。
- 它描述了多個元素如何交互。
在微服務下,有兩種類型的項目
- 待重新開發(fā)項目—國外譯名:Brownfield projects,是指在現(xiàn)有或遺留系統(tǒng)的背景下開發(fā)和部署新的軟件系統(tǒng)。因此,將單體應用程序轉換為微服務是屬于這種類型項目。
- 新建項目——是指從頭開始為一個全新的系統(tǒng),而無需使用任何遺留代碼。當您從頭開始時,沒有任何限制或依賴性。
一、按業(yè)務能力模式分解
為了創(chuàng)建微服務架構,一種策略是基于業(yè)務能力進行分解。作為一家企業(yè),項目是為了創(chuàng)造價值。例如,在電子商務業(yè)務中,訂單管理、庫存管理、支付、運輸?shù)榷忌婕啊?/p>
這種模式有以下好處
- 業(yè)務能力比較穩(wěn)定,架構依賴的業(yè)務邏輯比較穩(wěn)定。
- 開發(fā)團隊是跨職能的、自主的,并且圍繞交付業(yè)務價值而非技術特性進行組織。
- 服務是松散耦合和內(nèi)聚的。
二、按子域模式分解
領域驅動設計 (DDD) 方法是一種構建復雜軟件應用程序的方法,它基于面向對象領域模型的開發(fā)。DDD 為每個子域定義了單獨地域模型。每個子域都屬于一個域。識別子領域與識別業(yè)務能力的過程比較相似,即分析業(yè)務和識別專業(yè)領域。最有可能的是,大多數(shù)是業(yè)務熟悉的子域。領域模型的范圍在 DDD 中稱為有界上下文。有界上下文包括實現(xiàn)模型的代碼組件。
子域可以分類如下
- 核心—業(yè)務的最大差異化因素和應用程序最有價值的部分,在一些公司經(jīng)常有核心系統(tǒng)項目,有核心報價子系統(tǒng),核心定價子系統(tǒng)等
- 支持—不是差異化因素,而是與業(yè)務提供的內(nèi)容相關。通常在內(nèi)部或外包實施。
- 通用—不特定于業(yè)務,最好使用現(xiàn)成的軟件實施。
這種模式有以下好處
- 子域職能比較穩(wěn)定,架構相對也比較穩(wěn)定。
- 開發(fā)團隊(通常會設計到組建虛擬團隊)是跨職能的、自主的,并且專注于交付業(yè)務價值而不是技術特性。
- 服務是松散耦合和內(nèi)聚的。
三、將單體應用程序分解為微服務時的挑戰(zhàn)
在分解單體應用程序時,可能會出現(xiàn)挑戰(zhàn)。
- 網(wǎng)絡延遲—在分布式系統(tǒng)中,網(wǎng)絡延遲是一個持續(xù)關注的問題。您可能會發(fā)現(xiàn)對服務的特定分解會導致兩個服務之間的大量往返。
- 數(shù)據(jù)一致性—每個服務都有自己的數(shù)據(jù)庫,因此維護跨服務的數(shù)據(jù)一致性會非常困難。
- 神類(捂臉哭一下)—神類是控制系統(tǒng)中太多其他對象的對象,它超越了邏輯,成為了無所不能的類。由于其規(guī)模和復雜性,它是一個集中系統(tǒng)智能的類,并使用來自其他類的信息。
四、扼殺者模式
將遺留的單體應用程序遷移到微服務架構時,會使用 Strangler 模式。通過用新服務替換特定功能,可以使用這種模式逐步轉換單體應用程序。新服務一旦準備好,舊組件就被扼殺,新服務投入使用,而舊組件退役。
單體應用最終會縮小功能,而微服務將接管整體功能。
分享標題:微服務分解設計四種法則
新聞來源:http://www.5511xx.com/article/dpoooep.html


咨詢
建站咨詢
