免费观看又色又爽又黄的小说免费_美女福利视频国产片_亚洲欧美精品_美国一级大黄大色毛片

JD架構(gòu)師分享:微服務(wù)架構(gòu)到底是什么東西

2021-01-29    分類(lèi): 網(wǎng)站建設(shè)

軟件的架構(gòu)是一種抽象的結(jié)構(gòu),它由軟件的各個(gè)組成部分和這些部分之間的依賴(lài)關(guān)系構(gòu)成。正如你將在本文中看到的,軟件的架構(gòu)是多維的,因此有多種方法可以對(duì)其進(jìn)行描述。架構(gòu)很重要的原因是它決定了應(yīng)用程序的質(zhì)量屬性或能力。傳統(tǒng)上,架構(gòu)的目標(biāo)是可擴(kuò)展性、可靠性和安全性。但是今天,該架構(gòu)能夠快速安全地交付軟件,這一點(diǎn)非常重要。你將了解微服務(wù)架構(gòu)是一種架構(gòu)風(fēng)格,可為應(yīng)用程序提供更高的可維護(hù)性、可測(cè)試性和可部署性。


我將通過(guò)描述軟件架構(gòu)的概念及其重要性來(lái)開(kāi)始本文。接下來(lái),我將討論架構(gòu)風(fēng)格的概念。然后我將微服務(wù)架構(gòu)定義為特定的架構(gòu)風(fēng)格。讓我們從理解軟件架構(gòu)的概念開(kāi)始。

1軟件架構(gòu)是什么,為什么它如此重要

架構(gòu)顯然很重要。至少有兩個(gè)專(zhuān)門(mén)討論該主題的會(huì)議:O’Reilly的軟件架構(gòu)會(huì)議和SATURN會(huì)議。許多開(kāi)發(fā)人員的目標(biāo)是成為一名架構(gòu)師。但什么是架構(gòu),為什么它如此重要?

為了回答這個(gè)問(wèn)題,我首先定義術(shù)語(yǔ)軟件架構(gòu)的含義。之后,我將討論應(yīng)用程序的架構(gòu)是多維的,并使用一組視圖或藍(lán)圖進(jìn)行描述。然后我將強(qiáng)調(diào)軟件架構(gòu)的重要性,因?yàn)樗鼘?duì)應(yīng)用程序的質(zhì)量屬性有顯著的影響。


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

軟件架構(gòu)有很多定義。例如,維基百科上列舉了大量的定義。我最喜歡的定義來(lái)自卡耐基梅隆大學(xué)軟件工程研究所的Len Bass及其同事,他們?cè)谑管浖軜?gòu)成為一門(mén)學(xué)科方面發(fā)揮了關(guān)鍵作用。他們定義的軟件架構(gòu)如下:

計(jì)算機(jī)系統(tǒng)的軟件架構(gòu)是構(gòu)建這個(gè)系統(tǒng)所需要的一組結(jié)構(gòu),包括軟件元素、它們之間的關(guān)系以及兩者的屬性。

這顯然是一個(gè)非常抽象的定義。但其實(shí)質(zhì)是應(yīng)用程序的架構(gòu)是將軟件分解為元素(element)和這些元素之間的關(guān)系(relation)。由于以下兩個(gè)原因,分解很重要:

它促進(jìn)了勞動(dòng)和知識(shí)的分工。它使具有特定專(zhuān)業(yè)知識(shí)的人們(或多個(gè)團(tuán)隊(duì))能夠就應(yīng)用程序高效地協(xié)同工作。

它定義了軟件元素的交互方式。

將軟件分解成元素以及定義這些元素之間的關(guān)系,決定了軟件的能力。

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

從更具體的角度而言,應(yīng)用程序的架構(gòu)可以從多個(gè)視角來(lái)看,就像建筑架構(gòu),一般有結(jié)構(gòu)、管線(xiàn)、電氣等多個(gè)架構(gòu)視角。 Phillip Krutchen 在他經(jīng)典的論文《 Architectural Blueprints — The 4+1 View Model of Software Architecture 》中提出了軟件架構(gòu)的4+1視圖。圖1展示的這套視圖定義了四個(gè)不同的軟件架構(gòu)視圖,每一個(gè)視圖都只描述架構(gòu)的一個(gè)特定方面。每個(gè)視圖包括一些特定的軟件元素和它們相互之間的關(guān)系。



圖14+1視圖模型使用四個(gè)視圖描述應(yīng)用程序的架構(gòu),并顯示每個(gè)視圖中的元素如何協(xié)作處理請(qǐng)求的場(chǎng)景

每個(gè)視圖的目的如下:

  • 邏輯視圖:開(kāi)發(fā)人員創(chuàng)建的軟件元素。在面向?qū)ο蟮恼Z(yǔ)言中,這些元素是類(lèi)和包。它們之間的關(guān)系是類(lèi)和包之間的關(guān)系,包括繼承、關(guān)聯(lián)和依賴(lài)。
  • 實(shí)現(xiàn)視圖:構(gòu)建編譯系統(tǒng)的輸出。此視圖由表示打包代碼的模塊和組件組成,組件是由一個(gè)或多個(gè)模塊組成的可執(zhí)行或可部署單元。在Java中,模塊是JAR文件,組件通常是WAR文件或可執(zhí)行JAR文件。它們之間的關(guān)系包括模塊之間的依賴(lài)關(guān)系以及組件和模塊之間的組合關(guān)系。
  • 進(jìn)程視圖:運(yùn)行時(shí)的組件。每個(gè)元素都是一個(gè)進(jìn)程,進(jìn)程之間的關(guān)系代表進(jìn)程間通信。
  • 部署視圖:進(jìn)程如何映射到機(jī)器。此視圖中的元素由(物理或虛擬)計(jì)算機(jī)和進(jìn)程組成。機(jī)器之間的關(guān)系代表網(wǎng)絡(luò)。該視圖還描述了進(jìn)程和機(jī)器之間的關(guān)系。

除了這四個(gè)視圖以外,4+1中的+1是指場(chǎng)景,它負(fù)責(zé)把視圖串聯(lián)在一起。每個(gè)場(chǎng)景負(fù)責(zé)描述在一個(gè)視圖中的多個(gè)架構(gòu)元素如何協(xié)作,以完成一個(gè)請(qǐng)求。例如,在邏輯視圖中的場(chǎng)景,展現(xiàn)了類(lèi)是如何協(xié)作的。同樣,在進(jìn)程視圖中的場(chǎng)景,展現(xiàn)了進(jìn)程是如何協(xié)作的。

4+1視圖是描述應(yīng)用程序架構(gòu)的好方式。每一個(gè)視圖都描述了架構(gòu)的一個(gè)重要側(cè)面。場(chǎng)景把視圖中的元素如何協(xié)作串聯(lián)在一起?,F(xiàn)在我們來(lái)看看為什么架構(gòu)是如此重要。

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

應(yīng)用程序有兩個(gè)層面的需求。第一類(lèi)是功能性需求,這些需求決定一個(gè)應(yīng)用程序做什么。這些通常都包含在用例(use case)或者用戶(hù)故事(user story)中。應(yīng)用的架構(gòu)其實(shí)跟這些功能性需求沒(méi)什么關(guān)系。功能性需求可以通過(guò)任意的架構(gòu)來(lái)實(shí)現(xiàn),甚至是非常糟糕的大泥球架構(gòu)。


架構(gòu)的重要性在于,它幫助應(yīng)用程序滿(mǎn)足了第二類(lèi)需求:非功能性需求。我們把這類(lèi)需求也稱(chēng)之為質(zhì)量屬性需求,或者簡(jiǎn)稱(chēng)為“能力”。這些非功能性需求決定一個(gè)應(yīng)用程序在運(yùn)行時(shí)的質(zhì)量,比如可擴(kuò)展性和可靠性。它們也決定了開(kāi)發(fā)階段的質(zhì)量,包括可維護(hù)性、可測(cè)試性、可擴(kuò)展性和可部署性。為應(yīng)用程序所選擇的架構(gòu)將決定這些質(zhì)量屬性。

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

在物理世界中,建筑物的建筑通常遵循特定的風(fēng)格,例如維多利亞式、美國(guó)工匠式或裝飾藝術(shù)式。每種風(fēng)格都是一系列設(shè)計(jì)決策,限制了建筑的特征和建筑材料。建筑風(fēng)格的概念也適用于軟件。David Garlan和Mary Shaw這兩位軟件架構(gòu)學(xué)科的先驅(qū)定義了如下架構(gòu)風(fēng)格:

因此,架構(gòu)風(fēng)格根據(jù)結(jié)構(gòu)組織模式定義了一系列此類(lèi)系統(tǒng)。更具體地說(shuō),架構(gòu)風(fēng)格確定可以在該風(fēng)格的實(shí)例中使用的組件和連接器的詞匯表,以及關(guān)于如何組合它們的一組約束。

特定的架構(gòu)風(fēng)格提供了有限的元素(組件)和關(guān)系(連接器),你可以從中定義應(yīng)用程序架構(gòu)的視圖。應(yīng)用程序通常使用多種架構(gòu)風(fēng)格的組合。例如,在本節(jié)的后面,我將描述單體架構(gòu)是如何將實(shí)現(xiàn)視圖構(gòu)造為單個(gè)(可執(zhí)行與可部署)組件的架構(gòu)樣式。微服務(wù)架構(gòu)將應(yīng)用程序構(gòu)造為一組松散耦合的服務(wù)。

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

架構(gòu)的典型例子是分層架構(gòu)。分層架構(gòu)將軟件元素按“層”的方式組織。每個(gè)層都有明確定義的職責(zé)。分層架構(gòu)還限制了層之間的依賴(lài)關(guān)系。每一層只能依賴(lài)于緊鄰其下方的層(如果嚴(yán)格分層)或其下面的任何層。

可以將分層架構(gòu)應(yīng)用于前面討論的四個(gè)視圖中的任何一個(gè)。流行的三層架構(gòu)是應(yīng)用于邏輯視圖的分層架構(gòu)。它將應(yīng)用程序的類(lèi)組織到以下層中:

  • 表現(xiàn)層:包含實(shí)現(xiàn)用戶(hù)界面或外部API的代碼。
  • 業(yè)務(wù)邏輯層:包含業(yè)務(wù)邏輯。
  • 數(shù)據(jù)持久化層:實(shí)現(xiàn)與數(shù)據(jù)庫(kù)交互的邏輯。

分層架構(gòu)是架構(gòu)風(fēng)格的一個(gè)很好的例子,但它確實(shí)有一些明顯的弊端:

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

此外,分層架構(gòu)錯(cuò)誤地表示了精心設(shè)計(jì)的應(yīng)用程序中的依賴(lài)關(guān)系。業(yè)務(wù)邏輯通常定義數(shù)據(jù)訪(fǎng)問(wèn)方法的接口或接口庫(kù)。數(shù)據(jù)持久化層則定義了實(shí)現(xiàn)存儲(chǔ)庫(kù)接口的DAO類(lèi)。換句話(huà)說(shuō),依賴(lài)關(guān)系與分層架構(gòu)所描述的相反。

讓我們看一下克服這些弊端的替代架構(gòu):六邊形架構(gòu)。

關(guān)于架構(gòu)風(fēng)格的六邊形

六邊形架構(gòu)是分層架構(gòu)風(fēng)格的替代品。如圖2-2所示,六邊形架構(gòu)風(fēng)格選擇以業(yè)務(wù)邏輯為中心的方式組織邏輯視圖。應(yīng)用程序具有一個(gè)或多個(gè)入站適配器,而不是表示層,它通過(guò)調(diào)用業(yè)務(wù)邏輯來(lái)處理來(lái)自外部的請(qǐng)求。同樣,應(yīng)用程序具有一個(gè)或多個(gè)出站適配器,而不是數(shù)據(jù)持久化層,這些出站適配器由業(yè)務(wù)邏輯調(diào)用并調(diào)用外部應(yīng)用程序。此架構(gòu)的一個(gè)關(guān)鍵特性和優(yōu)點(diǎn)是業(yè)務(wù)邏輯不依賴(lài)于適配器。相反,各種適配器都依賴(lài)業(yè)務(wù)邏輯。



圖2六邊形架構(gòu)的一個(gè)示例,它由業(yè)務(wù)邏輯和一個(gè)或多個(gè)與外部系統(tǒng)通信的適配器組成。業(yè)務(wù)邏輯具有一個(gè)或多個(gè)端口。處理來(lái)自外部系統(tǒng)請(qǐng)求的入站適配器調(diào)用入站端口。出站適配器實(shí)現(xiàn)出站端口,并調(diào)用外部系統(tǒng)

業(yè)務(wù)邏輯具有一個(gè)或多個(gè)端口( port )。端口定義了一組操作,關(guān)于業(yè)務(wù)邏輯如何與外部交互。例如,在 Java 中,端口通常是 Java 接口。有兩種端口:入站和出站端口。入站端口是業(yè)務(wù)邏輯公開(kāi)的API,它使外部應(yīng)用程序可以調(diào)用它。入站端口的一個(gè)實(shí)例是服務(wù)接口,它定義服務(wù)的公共方法。出站端口是業(yè)務(wù)邏輯調(diào)用外部系統(tǒng)的方式。出站端口的一個(gè)實(shí)例是存儲(chǔ)庫(kù)接口,它定義數(shù)據(jù)訪(fǎng)問(wèn)操作的集合。

業(yè)務(wù)邏輯的周?chē)沁m配器。與端口一樣,有兩種類(lèi)型的適配器:入站和出站。入站適配器通過(guò)調(diào)用入站端口來(lái)處理來(lái)自外部世界的請(qǐng)求。入站適配器的一個(gè)實(shí)例是 Spring MVC Controller ,它實(shí)現(xiàn)一組 REST 接口( endpoint )或一組 Web 頁(yè)面。另一個(gè)實(shí)例是訂閱消息的消息代理客戶(hù)端。多個(gè)入站適配器可以調(diào)用相同的入站端口。

出站適配器實(shí)現(xiàn)出站端口,并通過(guò)調(diào)用外部應(yīng)用程序或服務(wù)處理來(lái)自業(yè)務(wù)邏輯的請(qǐng)求。出站適配器的一個(gè)實(shí)例是實(shí)現(xiàn)訪(fǎng)問(wèn)數(shù)據(jù)庫(kù)的操作的數(shù)據(jù)訪(fǎng)問(wèn)對(duì)象( DAO )類(lèi)。另一個(gè)實(shí)例是調(diào)用遠(yuǎn)程服務(wù)的代理類(lèi)。出站適配器也可以發(fā)布事件。

六邊形架構(gòu)風(fēng)格的一個(gè)重要好處是它將業(yè)務(wù)邏輯與適配器中包含的表示層和數(shù)據(jù)訪(fǎng)問(wèn)層的邏輯分離開(kāi)來(lái)。業(yè)務(wù)邏輯不依賴(lài)于表示層邏輯或數(shù)據(jù)訪(fǎng)問(wèn)層邏輯。

由于這種分離,單獨(dú)測(cè)試業(yè)務(wù)邏輯要容易得多。另一個(gè)好處是它更準(zhǔn)確地反映了現(xiàn)代應(yīng)用程序的架構(gòu)??梢酝ㄟ^(guò)多個(gè)適配器調(diào)用業(yè)務(wù)邏輯,每個(gè)適配器實(shí)現(xiàn)特定的API或用戶(hù)界面。業(yè)務(wù)邏輯還可以調(diào)用多個(gè)適配器,每個(gè)適配器調(diào)用不同的外部系統(tǒng)。六邊形架構(gòu)是描述微服務(wù)架構(gòu)中每個(gè)服務(wù)的架構(gòu)的好方法。

分層架構(gòu)和六邊形架構(gòu)都是架構(gòu)風(fēng)格的實(shí)例。每個(gè)都定義了架構(gòu)的構(gòu)建塊(元素),并對(duì)它們之間的關(guān)系施加了約束。六邊形架構(gòu)和分層架構(gòu)(三層架構(gòu))構(gòu)成了軟件的邏輯視圖。現(xiàn)在讓我們將微服務(wù)架構(gòu)定義為構(gòu)成軟件的實(shí)現(xiàn)視圖的架構(gòu)風(fēng)格。

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

前面已經(jīng)討論過(guò)4+1視圖模型和架構(gòu)風(fēng)格,所以現(xiàn)在可以開(kāi)始定義單體架構(gòu)和微服務(wù)架構(gòu)。它們都是架構(gòu)風(fēng)格。單體架構(gòu)是一種架構(gòu)風(fēng)格,它的實(shí)現(xiàn)視圖是單個(gè)組件:?jiǎn)蝹€(gè)可執(zhí)行文件或WAR文件。這個(gè)定義并沒(méi)有說(shuō)明其他的視圖。例如,單體應(yīng)用程序可以具有六邊形架構(gòu)風(fēng)格的邏輯視圖。

模式:?jiǎn)误w架構(gòu)

將應(yīng)用程序構(gòu)建為單個(gè)可執(zhí)行和可部署組件。請(qǐng)參閱: http://microservices.io/patterns/monolithic.html。

微服務(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)。圖2-3顯示了FTGO應(yīng)用程序可能的微服務(wù)架構(gòu)。此架構(gòu)中的服務(wù)對(duì)應(yīng)于業(yè)務(wù)功能,例如訂單管理和餐館管理。

模式:微服務(wù)架構(gòu)

將應(yīng)用程序構(gòu)建為松耦合、可獨(dú)立部署的一組服務(wù)。請(qǐng)參閱: http://microservices.io/patterns/microservices.html。



圖3FTGO應(yīng)用程序可能的微服務(wù)架構(gòu)。它由眾多服務(wù)組成

微服務(wù)架構(gòu)強(qiáng)加的一個(gè)關(guān)鍵約束是服務(wù)松耦合。因此,服務(wù)之間的協(xié)作方式存在一定限制。為了解釋這些限制,我將嘗試定義什么是服務(wù),解釋松耦合意味著什么,并告訴你為什么這很重要。

什么是服務(wù)

服務(wù)是一個(gè)單一的、可獨(dú)立部署的軟件組件,它實(shí)現(xiàn)了一些有用的功能。圖2-4顯示了服務(wù)的外部視圖,在此示例中是Order Service。服務(wù)具有API,為其客戶(hù)端提供對(duì)功能的訪(fǎng)問(wèn)。有兩種類(lèi)型的操作:命令和查詢(xún)。API由命令、查詢(xún)和事件組成。命令如createOrder()執(zhí)行操作并更新數(shù)據(jù)。查詢(xún),如findOrderById()檢索數(shù)據(jù)。服務(wù)還發(fā)布由其客戶(hù)端使用的事件,例如OrderCreated。

服務(wù)的API封裝了其內(nèi)部實(shí)現(xiàn)。與單體架構(gòu)不同,開(kāi)發(fā)人員無(wú)法繞過(guò)服務(wù)的API直接訪(fǎng)問(wèn)服務(wù)內(nèi)部的方法或數(shù)據(jù)。因此,微服務(wù)架構(gòu)強(qiáng)制實(shí)現(xiàn)了應(yīng)用程序的模塊化。

微服務(wù)架構(gòu)中的每項(xiàng)服務(wù)都有自己的架構(gòu),可能還有獨(dú)特的技術(shù)棧。但是典型的服務(wù)往往都具有六邊形架構(gòu)。其API由與服務(wù)的業(yè)務(wù)邏輯交互的適配器實(shí)現(xiàn)。操作適配器調(diào)用業(yè)務(wù)邏輯,事件適配器對(duì)外發(fā)布業(yè)務(wù)邏輯產(chǎn)生的事件。



圖4服務(wù)具有封裝實(shí)現(xiàn)的API。API定義了由客戶(hù)端調(diào)用的操作。有兩種類(lèi)型的操作:命令用來(lái)更新數(shù)據(jù),查詢(xún)用來(lái)檢索數(shù)據(jù)。當(dāng)服務(wù)的數(shù)據(jù)發(fā)生更改時(shí),服務(wù)會(huì)發(fā)布可供客戶(hù)端訂閱的事件

在本書(shū)第12章討論部署技術(shù)時(shí),你將看到服務(wù)的實(shí)現(xiàn)視圖可以采用多種形式。該組件可以是獨(dú)立進(jìn)程,在容器中運(yùn)行的Web應(yīng)用程序或OSGI包、云主機(jī)或Serverless技術(shù),等等。但是,一個(gè)基本要求是服務(wù)具有API并且可以獨(dú)立部署。

什么是松耦合

微服務(wù)架構(gòu)的最核心特性是服務(wù)之間的松耦合性。服務(wù)之間的交互采用API完成,這樣做就封裝了服務(wù)的實(shí)現(xiàn)細(xì)節(jié)。這允許服務(wù)在不影響客戶(hù)端的情況下,對(duì)實(shí)現(xiàn)方式做出修改。松耦合服務(wù)是改善開(kāi)發(fā)效率、提升可維護(hù)性和可測(cè)試性的關(guān)鍵。小的、松耦合的服務(wù)更容易被理解、修改和測(cè)試。

我們通過(guò)API來(lái)實(shí)現(xiàn)松耦合服務(wù)之間的協(xié)調(diào)調(diào)用,這樣就避免了外界對(duì)服務(wù)的數(shù)據(jù)庫(kù)的直接訪(fǎng)問(wèn)和調(diào)用。服務(wù)自身的持久化數(shù)據(jù)就如同類(lèi)的私有屬性一樣,是不對(duì)外的。保證數(shù)據(jù)的私有屬性是實(shí)現(xiàn)松耦合的前提之一。這樣做,就允許開(kāi)發(fā)者修改服務(wù)的數(shù)據(jù)結(jié)構(gòu),而不用提前與其他服務(wù)的開(kāi)發(fā)者互相協(xié)商。這樣做在運(yùn)行時(shí)也實(shí)現(xiàn)了更好的隔離。例如,一個(gè)服務(wù)的數(shù)據(jù)庫(kù)加鎖不會(huì)影響另外的服務(wù)。但是你稍后就會(huì)看到在服務(wù)間不共享數(shù)據(jù)庫(kù)的弊端,特別是處理數(shù)據(jù)一致性和跨服務(wù)查詢(xún)都變得更為復(fù)雜。

共享類(lèi)庫(kù)的角色

開(kāi)發(fā)人員經(jīng)常把一些通用的功能打包到庫(kù)或模塊中,以便多個(gè)應(yīng)用程序可以重用它而無(wú)須復(fù)制代碼。畢竟,如果沒(méi)有Maven或npm庫(kù),我們今天的開(kāi)發(fā)工作都會(huì)變得更困難。你可能也想在微服務(wù)架構(gòu)中使用共享庫(kù)。從表面上看,它似乎是減少服務(wù)中代碼重復(fù)的好方法。但是你需要確保不會(huì)意外地在服務(wù)之間引入耦合。

例如,想象一下多個(gè)服務(wù)需要更新Order業(yè)務(wù)對(duì)象的場(chǎng)景。一種選擇是將該功能打包為可供多個(gè)服務(wù)使用的庫(kù)。一方面,使用庫(kù)可以消除代碼重復(fù)。另一方面,如果業(yè)務(wù)需求的變更影響了Order業(yè)務(wù)對(duì)象,開(kāi)發(fā)者需要同時(shí)重建和重新部署所有使用了共享庫(kù)的服務(wù)。更好的選擇是把這些可能會(huì)更改的通用功能(例如Order管理)作為服務(wù)來(lái)實(shí)現(xiàn),而不是共享庫(kù)。


你應(yīng)該努力使用共享庫(kù)來(lái)實(shí)現(xiàn)不太可能改變的功能。例如,在典型的應(yīng)用程序中,在每個(gè)服務(wù)中都實(shí)現(xiàn)一個(gè)通用的Money類(lèi)(例如用來(lái)實(shí)現(xiàn)幣種轉(zhuǎn)換等固定功能)沒(méi)有任何意義。相反,你應(yīng)該創(chuàng)建一個(gè)供所有服務(wù)使用的共享庫(kù)。

服務(wù)的大小并不重要

微服務(wù)這個(gè)術(shù)語(yǔ)的一個(gè)問(wèn)題是會(huì)將你的關(guān)注點(diǎn)錯(cuò)誤地聚焦在微上。它暗示服務(wù)應(yīng)該非常小。其他基于大小的術(shù)語(yǔ) (如miniservice或nanoservice) 也是如此。實(shí)際上,大小不是一個(gè)重要的考慮因素。

更好的目標(biāo)是將精心設(shè)計(jì)的服務(wù)定義為能夠由小團(tuán)隊(duì)開(kāi)發(fā)的服務(wù),并且交付時(shí)間最短,與其他團(tuán)隊(duì)協(xié)作最少。理論上,團(tuán)隊(duì)可能只負(fù)責(zé)單一服務(wù),因此服務(wù)絕不是微小的。相反,如果服務(wù)需要大型團(tuán)隊(duì)或需要很長(zhǎng)時(shí)間進(jìn)行測(cè)試,那么拆分團(tuán)隊(duì)或服務(wù)可能是有意義的。另外,如果你因?yàn)槠渌?wù)的變更而不斷需要同步更新自己負(fù)責(zé)的服務(wù),或者你所負(fù)責(zé)的服務(wù)正在觸發(fā)其他服務(wù)的同步更新,那么這表明服務(wù)沒(méi)有實(shí)現(xiàn)松耦合。你構(gòu)建的甚至可能是一個(gè)分布式的單體。

微服務(wù)架構(gòu)把應(yīng)用程序通過(guò)一些小的、松耦合的服務(wù)組織在一起。結(jié)果,這樣的架構(gòu)提升了開(kāi)發(fā)階段的效率,特別是可維護(hù)性、可測(cè)試性和可部署性,這也就讓組織的軟件開(kāi)發(fā)速度更快。微服務(wù)架構(gòu)也同時(shí)提升了應(yīng)用程序的可擴(kuò)展性,盡管這不是微服務(wù)的主要目標(biāo)。為了使用微服務(wù)架構(gòu)開(kāi)發(fā)軟件,你首先需要識(shí)別服務(wù),并確定它們之間如何協(xié)作?,F(xiàn)在我們來(lái)看看如何定義一個(gè)應(yīng)用程序的微服務(wù)架構(gòu)。

4 總結(jié)

  • 架構(gòu)決定了軟件的各種非功能性因素,比如可維護(hù)性、可測(cè)試性、可部署性和可擴(kuò)展性,它們會(huì)直接影響開(kāi)發(fā)速度。
  • 微服務(wù)架構(gòu)是一種架構(gòu)風(fēng)格,它給應(yīng)用程序帶來(lái)了更高的可維護(hù)性、可測(cè)試性、可部署性和可擴(kuò)展性。

新聞名稱(chēng):JD架構(gòu)師分享:微服務(wù)架構(gòu)到底是什么東西
地址分享:http://m.newbst.com/news31/98081.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供網(wǎng)站排名、關(guān)鍵詞優(yōu)化企業(yè)建站、網(wǎng)站營(yíng)銷(xiāo)、網(wǎng)站設(shè)計(jì)公司、網(wǎng)站收錄

廣告

聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶(hù)投稿、用戶(hù)轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀(guān)點(diǎn)不代表本網(wǎng)站立場(chǎng),如需處理請(qǐng)聯(lián)系客服。電話(huà):028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來(lái)源: 創(chuàng)新互聯(lián)

h5響應(yīng)式網(wǎng)站建設(shè)