微服務(wù)架構(gòu)是什么

軟件架構(gòu)是什么

軟件架構(gòu)的定義

看一下大佬是怎么說的：
　　計(jì)算機(jī)系統(tǒng)的軟件架構(gòu)是構(gòu)建這個(gè)系統(tǒng)所需要的一組結(jié)構(gòu)，包括軟件元素、它們之間的關(guān)系以及兩者的屬性。
　　　　　　　　　　　　　　　　　　　　　--Bass等著《Documenting Software Architectures:Views and Beyond》

這個(gè)定義將軟件分解為元素和元素之間的關(guān)系兩個(gè)部分，就像一輛汽車可以分為發(fā)動(dòng)機(jī)、底盤、輪胎等元素，同時(shí)各個(gè)元素之間還存在關(guān)系，他們需要互相交互，汽車才能正常使用。這樣分解有以下兩個(gè)原因：

1. 它促進(jìn)了勞動(dòng)和知識(shí)的分工。不同的團(tuán)隊(duì)可以高效系統(tǒng)工作。
2. 它定義了軟件之間的交互方式

軟件架構(gòu)的4+1視圖模型

從4個(gè)不同的視角來看一個(gè)軟件的價(jià)架構(gòu)：

1. 邏輯視圖：由開發(fā)人員創(chuàng)建的軟件元素，在面向?qū)ο蟮恼Z言中，這些元素就是類和包，他們之間關(guān)系就是繼承、關(guān)聯(lián)、依賴等。
2. 實(shí)現(xiàn)視圖：由構(gòu)建編譯系統(tǒng)創(chuàng)建，元素就是模塊和可執(zhí)行文件。在Java中，模塊就是JAR文件，組件通常是WAR文件或者可執(zhí)行的JAR文件。他們之間的關(guān)系就是模塊之間的依賴關(guān)系以及組件和模塊之間的組合關(guān)系。
3. 進(jìn)程視圖：運(yùn)行時(shí)的組件。每個(gè)元素都是一個(gè)進(jìn)程，進(jìn)程之間的關(guān)系進(jìn)程間的通信。
4. 部署視圖：運(yùn)行在機(jī)器上的進(jìn)程。進(jìn)程如何映射到機(jī)器。元素是機(jī)器（或虛擬機(jī)　如docker），機(jī)器之間的關(guān)系代表網(wǎng)絡(luò)。

除了這四個(gè)視圖以外，4+1中的+1是指場景，它負(fù)責(zé)把視圖串聯(lián)在一起。每個(gè)場景負(fù)責(zé)描述在一個(gè)視圖中的多個(gè)架構(gòu)元素如何協(xié)作，以完成一個(gè)請(qǐng)求。例如，在邏輯視圖中的場景，展現(xiàn)了類是如何協(xié)作的。同樣，在進(jìn)程視圖中的場景，展現(xiàn)了進(jìn)程是如何協(xié)作的。4+1視圖是描述應(yīng)用程序的絕佳方式。每一個(gè)視圖都描述了架構(gòu)的一個(gè)重要側(cè)面，場景把視圖中的元素和協(xié)作串聯(lián)在一起。

為什么架構(gòu)如此重要

應(yīng)用程序有兩個(gè)層面的需求：

1. 功能性需求：這些需求決定了程序可以提供哪些功能。這些功能和應(yīng)用的架構(gòu)沒有任何關(guān)系，只要能實(shí)現(xiàn)功能就行，用哪種架構(gòu)都可以。
2. 非功能性需求：可以稱之為質(zhì)量屬性需求，它決定了程序運(yùn)行時(shí)的質(zhì)量，可擴(kuò)展性、可靠性。也決定了開發(fā)階段的質(zhì)量，包含可維護(hù)性、可測試性、可擴(kuò)展性、可部署性。為應(yīng)用程序選擇的架構(gòu)決定了這些質(zhì)量屬性。

個(gè)人理解這段說的就是我們?cè)谕瓿衫习寤蛘弋a(chǎn)品給的一個(gè)需求的時(shí)候，除了實(shí)現(xiàn)功能以外，還要自己考慮實(shí)現(xiàn)的方式是不是能可擴(kuò)展，高可用等等。實(shí)現(xiàn)架構(gòu)如果不合適，項(xiàng)目隨時(shí)間會(huì)變得復(fù)雜，不易維護(hù)和擴(kuò)展，這時(shí)候還得需要治理。

什么是架構(gòu)風(fēng)格

像不同時(shí)代不同國家的建筑有著不同的建筑風(fēng)格一樣，軟件架構(gòu)也有幾種不同的風(fēng)格。什么是架構(gòu)風(fēng)格？David Garlan 和 Mary Shaw (An Introduction to Software Architecture,January 1994)這兩位軟件架構(gòu)學(xué)科的先驅(qū)是這樣定義的：

因此，架構(gòu)風(fēng)格根據(jù)結(jié)構(gòu)組織模式定義了一系列此類系統(tǒng)。更具體地說，架構(gòu)風(fēng)格確定可以在該風(fēng)格的實(shí)例中使用的組件和連接器的詞匯表，以及關(guān)于如何組合它們的一組約束。詳情鏈接：https://wwwcs.cmu.edu/afs/cs/project/able/ftp/intro softarch/intro softarch.pdf

太抽象了。不深究，先來看看具體的幾種架構(gòu)風(fēng)格：

分層式架構(gòu)風(fēng)格

• 表現(xiàn)層：包含對(duì)外提供的API接口
• 業(yè)務(wù)邏輯層：包含業(yè)務(wù)邏輯
• 數(shù)據(jù)持久層：實(shí)現(xiàn)與數(shù)據(jù)庫交互邏輯

弊端：

• 單一表現(xiàn)層：無法展現(xiàn)應(yīng)用程序可能不僅由單個(gè)系統(tǒng)調(diào)用的事實(shí)。
• 單一數(shù)據(jù)持久化層:它無法展現(xiàn)應(yīng)用程序可能與多個(gè)數(shù)據(jù)庫進(jìn)行交互的事實(shí)。
• 將業(yè)務(wù)邏輯層定義為依賴于數(shù)據(jù)持久化層:理論上，這樣的依賴性會(huì)妨礙你在沒有數(shù)據(jù)庫的情況下測試業(yè)務(wù)邏輯。

個(gè)人感覺說的是沒錯(cuò)，但這幾個(gè)弊端貌似都影響不大呢？工作中也是分層架構(gòu)也是一種很常用的架構(gòu)

六邊形架構(gòu)風(fēng)格

https://alistair.cockburn.us/hexagonal-architecture/

微服務(wù)架構(gòu)風(fēng)格

微服務(wù)架構(gòu)也是一種架構(gòu)風(fēng)格。它的實(shí)現(xiàn)視圖由多個(gè)組件構(gòu)成:一組可執(zhí)行文件或 WAR文件。
它的組件是服務(wù)，連接器是使這些服務(wù)能夠協(xié)作的通信協(xié)議。每個(gè)服務(wù)都有自己的邏輯視圖架構(gòu)，通常也是六邊形架構(gòu).(感覺三層架構(gòu)更多些)
微服務(wù)架構(gòu)將應(yīng)用程序構(gòu)建為松耦合、可獨(dú)立部署的一組服務(wù)。請(qǐng)參閱:http://microservices.iolpatterns/microserviceshtml，F(xiàn)TGO可能微服務(wù)架構(gòu)如下：

什么是服務(wù)

什么是松耦合

微服務(wù)架構(gòu)的最核心特性是服務(wù)之間的松耦合性(https://enwikipediaorg/wiki/Loosecoupling)。服務(wù)之間的交互通過API完成，這樣做有以下幾個(gè)好處：

• 封裝了服務(wù)的實(shí)現(xiàn)細(xì)節(jié)。允許服務(wù)在不影響客戶端的情況下，對(duì)實(shí)現(xiàn)方式做出修改。
• 避免了外界對(duì)服務(wù)的數(shù)據(jù)庫的直接訪問和調(diào)用。服務(wù)自身的持久化數(shù)據(jù)就如同類的私有屬性一樣，是不對(duì)外的。保證數(shù)據(jù)的私有屬性是實(shí)現(xiàn)松耦合的前提之一。
• 允許開發(fā)者修改服務(wù)的數(shù)據(jù)結(jié)構(gòu)，而不用提前與其他服務(wù)的開發(fā)者互相協(xié)商。這樣做在運(yùn)行時(shí)也實(shí)現(xiàn)了更好的隔離。例如，一個(gè)服務(wù)的數(shù)據(jù)庫加鎖不會(huì)影響另外的服務(wù)。但在服務(wù)間不共享數(shù)據(jù)庫的弊端，特別是處理數(shù)據(jù)一致性和跨服務(wù)查詢都變得更為復(fù)雜。
  松耦合服務(wù)是改善開發(fā)效率、提升可維護(hù)性和可測試性的關(guān)鍵。小的、松耦合的服務(wù)更容易被理解、修改和測試。

共享類庫的角色

開發(fā)中我們經(jīng)常把一些通用的功能打包到庫或模塊中，目的就是為了多個(gè)應(yīng)用程序用到他的時(shí)候可以重用它而無需復(fù)制代碼。
如果沒有 Maven或npm庫，我們今天的開發(fā)工作都會(huì)變得更困難。那么我們可能就會(huì)想在微服務(wù)架構(gòu)中使用是否能使用共享庫好呢?表面上看，它似乎是減少服務(wù)中代碼重復(fù)的好方法。但是我們這樣做的時(shí)候，需要確保不會(huì)意外地在服務(wù)之間引入耦合。舉個(gè)栗子：
假如多個(gè)服務(wù)需要更新 order 業(yè)務(wù)對(duì)象的場景，一種選擇是將該功能打包為可供多個(gè)服務(wù)使用的庫。這樣做的優(yōu)點(diǎn)是可以消除代碼重復(fù)。缺點(diǎn)是如果業(yè)務(wù)需求的變更影響了 order業(yè)務(wù)對(duì)象，開發(fā)者需要同時(shí)重建和重新部署所有使用了共享庫的服務(wù)。這就非常麻煩了。相比之下，更好的選擇是把這些可能會(huì)更改的通用功能(例如order 管理)作為服務(wù)來實(shí)現(xiàn)，而不是共享庫。

所以我們應(yīng)該盡量把不太可能改變的功能放入共享庫中。例如，在典型的應(yīng)用程序中，如果在每個(gè)服務(wù)中都實(shí)現(xiàn)一個(gè)通用的 Money類(例如用來實(shí)現(xiàn)幣種轉(zhuǎn)換等固定功能)，沒有任何意義，它不會(huì)經(jīng)常改變，而且也很通用，這樣就可以把它放到共享類庫中。

為應(yīng)用程序定義微服務(wù)架構(gòu)

如何定義一個(gè)微服務(wù)架構(gòu)呢？文章中介紹了一個(gè)三部式流，世界上沒有一個(gè)完美的機(jī)械化方法可以遵循，這個(gè)也只是大概方法， 現(xiàn)實(shí)中還需要具體分析I，不斷的迭代。三部式流程如下：
1. 定義系統(tǒng)操作
根據(jù)功能性需求文檔，定義系統(tǒng)可以提供的操作。如FTGO中，顧客需要下單，那么系統(tǒng)就需要提供需要提供讓顧客下單的操作；而商家需要接單，那么商家還需要提供給可以讓接單的操作。
2. 定義服務(wù)
這里說的就是如何分解服務(wù)。有幾種策略可供選擇。一種源于業(yè)務(wù)架構(gòu)學(xué)派的策略是定義與業(yè)務(wù)能力相對(duì)應(yīng)的服務(wù)。另一種策略是圍繞領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的子域來分解和設(shè)計(jì)服務(wù)。但這些策略的最終結(jié)果都是圍繞業(yè)務(wù)概念而非技術(shù)概念分解和設(shè)計(jì)的服務(wù)。什么是子域？簡單來說，一個(gè)子域是的領(lǐng)域Domain的子部分。無論公司的規(guī)模如何，每個(gè)領(lǐng)域都可以劃分為子域，通過這樣做，我們將公司領(lǐng)域的整個(gè)復(fù)雜性劃分為更小的部分，我們將擁有能夠很好地理解業(yè)務(wù)方面的領(lǐng)域?qū)＜?，因?yàn)樗且粋€(gè)特定的子域。
3. 定義服務(wù)API和協(xié)作方式
定義應(yīng)用程序架構(gòu)的第三步是確定每個(gè)服務(wù)的API。為此，你將第一步中標(biāo)識(shí)的每個(gè)系統(tǒng)操作分配給服務(wù)。服務(wù)可以完全獨(dú)立地實(shí)現(xiàn)操作?；蛘?，它可能需要與其他服務(wù)協(xié)作。在這種情況下，你可以確定服務(wù)的協(xié)作方式，這通常需要服務(wù)來支持其他操作。你還需要確定選用第3章中描述的哪種進(jìn)程間通信機(jī)制來實(shí)現(xiàn)每個(gè)服務(wù)的API。

識(shí)別操作系統(tǒng)

待補(bǔ)充

根據(jù)業(yè)務(wù)能力進(jìn)行拆分

業(yè)務(wù)能力是一個(gè)來自于業(yè)務(wù)架構(gòu)建模的術(shù)語。業(yè)務(wù)能力是指一些能夠?yàn)楣?或組織)產(chǎn)生價(jià)值的商業(yè)活動(dòng)。特定業(yè)務(wù)的業(yè)務(wù)能力取決于這個(gè)業(yè)務(wù)的類型。例如，保險(xiǎn)公司業(yè)務(wù)能力通常包括承保、理賠管理賬務(wù)和合規(guī)等。在線商店的業(yè)務(wù)能力包括:訂單管理、庫存管理和發(fā)貨，等等
模式:根據(jù)業(yè)務(wù)能力進(jìn)行服務(wù)拆分
定義與業(yè)務(wù)能力相對(duì)應(yīng)的服務(wù)。請(qǐng)參閱:http://microservicesio/patterns/decomposition/%20decompose-by-business-capability.html

業(yè)務(wù)能力定義了一個(gè)組織的工作

組織的業(yè)務(wù)能力通常是指這個(gè)組織的業(yè)務(wù)是做什么，它們通常都是穩(wěn)定的。與之相反組織采用何種方式來實(shí)現(xiàn)它的業(yè)務(wù)能力，是隨著時(shí)間不斷變化的。這個(gè)準(zhǔn)則在今天尤其明顯，很多新技術(shù)在被快速采用，商業(yè)流程的自動(dòng)化程度越來越高。例如，不久之前你還通過把支票交給銀行柜員的方式來兌現(xiàn)支票，現(xiàn)在很多ATM 機(jī)都支持直接兌現(xiàn)支票，而今，人們甚至可以使用智能手機(jī)拍照的方式來兌現(xiàn)支票。正如你所見，“兌現(xiàn)支票”這個(gè)業(yè)務(wù)能力是穩(wěn)定不變的，但是這個(gè)能力的實(shí)現(xiàn)方式正在發(fā)生戲劇性的變化。

這段作者講的挺好，業(yè)務(wù)能力是穩(wěn)定的，也就定義了一個(gè)組織的工作，但實(shí)現(xiàn)業(yè)務(wù)能力方式確實(shí)隨著時(shí)間不斷變化的，事實(shí)也確實(shí)如此。

識(shí)別業(yè)務(wù)能力

一個(gè)組織有哪些業(yè)務(wù)能力，是通過對(duì)組織的目標(biāo)、結(jié)構(gòu)和商業(yè)流程的分析得來的。每一個(gè)業(yè)務(wù)能力都可以被認(rèn)為是一個(gè)服務(wù)，除非它是面向業(yè)務(wù)的而非面向技術(shù)的。業(yè)務(wù)能力規(guī)范包含多項(xiàng)元素，比如輸入和輸出、服務(wù)等級(jí)協(xié)議(SLA)。例如，保險(xiǎn)承保能力的輸人來自客戶的應(yīng)用程序，這個(gè)業(yè)務(wù)能力的輸出是完成核保并報(bào)價(jià)。
業(yè)務(wù)能力通常集中在特定的業(yè)務(wù)對(duì)象上。例如，理賠業(yè)務(wù)對(duì)象是理賠管理功能的重點(diǎn)能力通?？梢苑纸鉃樽幽芰?。例如，理賠管理能力具有多個(gè)子能力，包括理賠信息管理、理賠審核和理賠付款管理。
把FTGO的業(yè)務(wù)能力逐一列出如下所示。

供應(yīng)商管理：
Courier management:送餐員相關(guān)信息管理
Restaurant information management:餐館菜單和其他信息管理，例如營業(yè)地址和時(shí)間

消費(fèi)者管理:消費(fèi)者有關(guān)信息的管理訂單獲取和履行。
Order management:讓消費(fèi)者可以創(chuàng)建和管理訂單
Restaurant order management:讓餐館可以管理訂單的生產(chǎn)過程

送餐
Courier availabilitymanagement:管理送餐員的實(shí)時(shí)狀態(tài)
Deliverymanagement:把訂單送到用戶手中。

會(huì)計(jì)記賬。
consumeraccounting:管理跟消費(fèi)者相關(guān)的會(huì)計(jì)記賬
Restaurant accounting:管理跟餐館相關(guān)的會(huì)計(jì)記賬
Courieraccounting:管理跟送餐員相關(guān)的會(huì)計(jì)記賬。
其他

這個(gè)能力層次的有趣方面是有三個(gè)餐館相關(guān)的能力:餐館信息管理、餐館訂單管理和餐館會(huì)計(jì)記賬。那是因?yàn)樗鼈兇砹瞬宛^運(yùn)營的三個(gè)截然不同的方面。

從業(yè)務(wù)能力到服務(wù)

業(yè)務(wù)能力定義清楚了，就可以將業(yè)務(wù)能力映射到對(duì)應(yīng)的服務(wù)了。將FTGO業(yè)務(wù)能力映射到服務(wù)，如下：

映射理由如下：

• 供應(yīng)商管理的子能力映射到兩種服務(wù)，是因?yàn)椴宛^和送餐員是非常不同類型多的供應(yīng)商。
• 我將訂單獲取和履行能力映射到三個(gè)服務(wù)，每個(gè)服務(wù)負(fù)責(zé)流程的不同階段。我將送餐員可用性管理(Courier availability management)和交付管理( Delivery management)能力結(jié)合起來，并將它們映射到單個(gè)服務(wù)，因?yàn)樗鼈兘豢椩谝黄稹?/li>
• 我將三個(gè)不同的會(huì)計(jì)記賬能力映射到同一個(gè)服務(wù)，因?yàn)檫@幾個(gè)不同類型的會(huì)計(jì)記賬看起來很相似。

圍繞能力組織服務(wù)的一個(gè)關(guān)鍵好處是，因?yàn)樗鼈兪欠€(wěn)定的，所以最終的架構(gòu)也將相對(duì)穩(wěn)架構(gòu)的各個(gè)組件可能會(huì)隨著業(yè)務(wù)的具體實(shí)現(xiàn)方式的變化而發(fā)展，但架構(gòu)仍保持不變

根據(jù)子域進(jìn)行拆分

待補(bǔ)充

拆分指導(dǎo)原則

單一職責(zé)原則（SRP）

改變一個(gè)類應(yīng)該只有一個(gè)理由。-Robert C.Martin

如果一個(gè)類承載了多個(gè)職責(zé)，并且互相之間的修改是獨(dú)立的，那么這個(gè)類就會(huì)變得非常不穩(wěn)定。所以定義的每一個(gè)類都應(yīng)該只有一個(gè)職責(zé)，因此也就只有一個(gè)理由對(duì)它進(jìn)行修改。我們?cè)谠O(shè)計(jì)微服務(wù)架構(gòu)時(shí)也應(yīng)該遵循SRP 原則，設(shè)計(jì)小的、內(nèi)聚的、僅僅含有單一職責(zé)的服務(wù)。這會(huì)縮小服務(wù)的大小并提升它的穩(wěn)定性。新的FTGO架構(gòu)是應(yīng)用SRP的一個(gè)例子為客戶獲取餐食的每一個(gè)方面(訂單獲取、訂單準(zhǔn)備、送餐等) 都由一個(gè)單一的服務(wù)承載。其實(shí)這個(gè)原則在實(shí)現(xiàn)類的每個(gè)方法時(shí)，每個(gè)類時(shí)，也都會(huì)用到。

閉包原則（CCP）

在包中包含的所有類應(yīng)該是對(duì)同類的變化的一個(gè)集合，也就是說，如果對(duì)包做出修改，需要調(diào)整的類應(yīng)該都在這個(gè)包之內(nèi)。-Robert C.Martin
閉包原則就是如果一個(gè)類的修改另一個(gè)類也必須修改，那么就要把他們兩個(gè)放到一個(gè)包里，這里做目的是當(dāng)業(yè)務(wù)規(guī)則發(fā)生變化時(shí)，開發(fā)者只需要對(duì)一個(gè)包做出修改，可以極大改成程序的可維護(hù)性。同樣我們可以把它應(yīng)用到拆分服務(wù)中，如果一個(gè)服務(wù)變化會(huì)影響到另一個(gè)服務(wù)，我們就把這兩個(gè)服務(wù)放在一個(gè)組件中，這樣做可以控制服務(wù)數(shù)量（防止拆分出的服務(wù)數(shù)量過多），變更和部署也更容易。理想情況下，一個(gè)變更只會(huì)影響一個(gè)團(tuán)隊(duì)和一個(gè)服務(wù)。CCP有效解決分布式單體的反模式法寶。

拆分單體服務(wù)的痛點(diǎn)

1. 網(wǎng)絡(luò)延遲
   分布式系統(tǒng)網(wǎng)絡(luò)延遲是分布式系統(tǒng)中一直存在的問題。、服務(wù)的特定分解會(huì)導(dǎo)致兩個(gè)服務(wù)之間的大量往返調(diào)用。有時(shí)我們可以通過實(shí)施批處理 API在一次往返中獲取多個(gè)對(duì)象，從而將延遲減少到可接受的數(shù)量。但在其他情況下，解決方案是把多個(gè)相關(guān)的服務(wù)組合在一起，用編程語言的函數(shù)調(diào)用替換昂貴的進(jìn)程間通信。就是把多個(gè)相關(guān)的服務(wù)寫成一個(gè)，本地調(diào)用肯定要比進(jìn)程間通信要快。
2. 同步進(jìn)程間通信導(dǎo)致可用性降低
   A服務(wù)要調(diào)用B服務(wù)，如果二者是同步調(diào)用，B服務(wù)不可用了或者是掛了，那么A服務(wù)部分功能可能就不能用了。但是在第3章中學(xué)習(xí)異步消息之后，你就會(huì)發(fā)現(xiàn)其實(shí)有更好的辦法來消除這類同步調(diào)用產(chǎn)生的緊耦合并提升可用性。
3. 在服務(wù)之間維持?jǐn)?shù)據(jù)一致性
   對(duì)于一些系統(tǒng)操作，可能需要同時(shí)更新多個(gè)模塊的數(shù)據(jù)。如電商系統(tǒng)中，用戶下單操作需要調(diào)用訂單管理模塊的方法，新增一條訂單到數(shù)據(jù)庫，同時(shí)需要調(diào)用庫存模塊的方法，鎖定一個(gè)商品庫存，更新庫存數(shù)量。還需要調(diào)用支付模塊的方法，新增一條支付記錄，狀態(tài)為待支付。如果用戶在規(guī)定時(shí)間內(nèi)支付了，需要更新庫存-1，訂單狀態(tài)改為已支付等。如果用戶未在規(guī)定時(shí)間內(nèi)支付，鎖定的庫存需要釋放，訂單狀態(tài)改為已取消，支付狀態(tài)改為支付超時(shí)等 。這個(gè)系統(tǒng)操作所涉及到的訂單、支付、庫存等操作，需要保證原子性。要么全部成功，要么全部失敗。假如支付成功了，庫存扣減失敗了，那是不行的。如果是在單體系統(tǒng)中，可以操作屬于一個(gè)本地事務(wù)，我們可以通過數(shù)據(jù)庫的事務(wù)來保證。但是在微服務(wù)架構(gòu)中，訂單、庫存、支付分屬于三個(gè)服務(wù)，每個(gè)服務(wù)有有對(duì)應(yīng)的數(shù)據(jù)庫，要保證一致性，就需要分布式事務(wù)。傳統(tǒng)的解決方案是使用基于兩階段提交(two phase commit)的分布式事務(wù)管理機(jī)制。
   書中作者沒有對(duì)兩階段提交詳細(xì)介紹，想了解可以參考這篇文章：鏈接
   但是作者提到了使用一種非常不同的方法來處理事務(wù)管理，這就是Saga。Saga 是一系列使用消息協(xié)作的本地事務(wù)。Saga 比傳統(tǒng)的ACID 事更復(fù)雜，但它們?cè)谠S多情況下都能工作得很好。Saga 的一個(gè)限制是它們最終是一致的。如果你需要以原子方式更新某些數(shù)據(jù)，那么它必須位于單個(gè)服務(wù)中，這可能是分解的障礙。后邊章節(jié)會(huì)詳細(xì)講。
4. 獲取一致的數(shù)據(jù)視圖
   分解的另一個(gè)障礙是無法跨多個(gè)數(shù)據(jù)庫獲得真正一致的數(shù)據(jù)視圖。在單體應(yīng)用程序中,ACID 事務(wù)的屬性保證查詢將返回?cái)?shù)據(jù)庫的一致視圖。相反，在微服務(wù)架構(gòu)中，即使每個(gè)服務(wù)的數(shù)據(jù)庫是一致的，你也無法獲得全局一致的數(shù)據(jù)視圖。如果你需要一些數(shù)據(jù)的一致視圖，那么它必須駐留在單個(gè)服務(wù)中，這也是服務(wù)分解所面臨的問題。幸運(yùn)的是，在實(shí)踐中這很少帶來真正的問題。
5. 上帝類阻礙了拆分

定義服務(wù)API

把系統(tǒng)操作分配給服務(wù)

第一步是確定哪個(gè)服務(wù)是請(qǐng)求的初始入口點(diǎn)。許多系統(tǒng)操作可以清晰地映射到服務(wù)（如創(chuàng)建訂單很明顯是訂單服務(wù)），但有時(shí)映射會(huì)不太明顯。例如，考慮使用noteUpdatedLocation()操作來更新送餐員的位置。一方面，因?yàn)樗c送餐員有關(guān)，所以應(yīng)該將此操作分配給 Courier Service。另一方面，它是需要送餐地點(diǎn)的 Delivery Service。在這種情況下，將操作分配給需要操作所提供信息的服務(wù)是更好的選擇（說的很繞?。?？）。在其他情況下，將操作分配給具有處理它所需信息的服務(wù)可能是有意義的。如處理findAvailableRestaurants()這個(gè)操作，需要從RestaurantService服務(wù)查信息，所以就把這個(gè)操作分配到這個(gè)服務(wù)。

確定支持服務(wù)協(xié)作所需要的API

把操作分配給服務(wù)后，下一步是確定在處理每一個(gè)系統(tǒng)操作時(shí)，服務(wù)之間如何交互。
某些系統(tǒng)操作完全由單個(gè)服務(wù)處理。例如，在FTGO應(yīng)用程序中，ConsumerService完全獨(dú)立地處理 createconsumer()操作。但是，某些系統(tǒng)操作跨越多個(gè)服務(wù)，處理這些請(qǐng)求之一所需的數(shù)據(jù)可能分散在多個(gè)服務(wù)周圍。例如createOrder()操作，orderService必須調(diào)用以下服務(wù)以驗(yàn)證其前置條件并使后置條件成立:
Consumer Service:驗(yàn)證消費(fèi)者是否可以下訂單并獲取其付款信息。
Restaurant Service:驗(yàn)證訂單行項(xiàng)目，驗(yàn)證送貨地址和時(shí)間是否在餐廳的服區(qū)域內(nèi)，驗(yàn)證訂單最低要求，并獲得訂單行項(xiàng)目的價(jià)格
Kitchen Service:創(chuàng)建Ticket(后廚工單)
AccountingService:授權(quán)消費(fèi)者的信用卡
為了完整定義服務(wù)API，你需要分析每個(gè)系統(tǒng)操作并確定所需的協(xié)作。其實(shí)到這一步，就是具體問題，具體分析了。

小結(jié)

1.架構(gòu)決定了軟件的各種非功能性因素，比如可維護(hù)性、可測試性、可部署性和可擴(kuò)展性，它們會(huì)直接影響開發(fā)速度。這也是軟件架構(gòu)重要的原因
2. 微服務(wù)架構(gòu)是一種架構(gòu)風(fēng)格，它給應(yīng)用程序帶來了更高的可維護(hù)性、可測試性、可部署性和可擴(kuò)展性。
3. 微服務(wù)中的服務(wù)是根據(jù)業(yè)務(wù)需求進(jìn)行組織的，按照業(yè)務(wù)能力或者子域，而不是技術(shù)上的考量。
4. 有兩種分解模式
按業(yè)務(wù)能力分解，其起源于業(yè)務(wù)架構(gòu)
基于領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的概念，通過子域進(jìn)行分解?？梢酝ㄟ^應(yīng)用DDD并為每個(gè)服務(wù)定義單獨(dú)的領(lǐng)域模型
5. 可以通過應(yīng)用DDD并為每個(gè)服務(wù)定義單獨(dú)的領(lǐng)域模型來消除上帝類，正是上帝類引起了阻礙分解的交織依賴項(xiàng)。文章來源地址http://www.zghlxwxcb.cn/news/detail-709018.html

到了這里，關(guān)于《微服務(wù)架構(gòu)設(shè)計(jì)模式》第二章的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！