一、軟件架構(gòu)的定義
1、軟件架構(gòu)的概念
軟件架構(gòu)（software architecture）是一個(gè)系統(tǒng)的草圖,是一系列相關(guān)的抽象模式，用于指導(dǎo)大型軟件系統(tǒng)各個(gè)方面的設(shè)計(jì)。軟件架構(gòu)描述的對(duì)象是直接構(gòu)成系統(tǒng)的抽象組件。在實(shí)現(xiàn)階段，這些抽象組件被細(xì)化為實(shí)際的組件，比如具體某個(gè)類或者對(duì)象。
軟件構(gòu)架是一個(gè)容易理解的概念，多數(shù)工程師（尤其是經(jīng)驗(yàn)不多的工程師）會(huì)從直覺上來認(rèn)識(shí)它，但要給出精確的定義很困難。特別是，很難明確地區(qū)分設(shè)計(jì)和構(gòu)架：構(gòu)架屬于設(shè)計(jì)的一方面，它集中于某些具體的特征。
在“軟件構(gòu)架簡(jiǎn)介”一書中，David GArlan 和 Mary Shaw 認(rèn)為軟件構(gòu)架是有關(guān)如下問題的設(shè)計(jì)層次：“在計(jì)算的算法和數(shù)據(jù)結(jié)構(gòu)之外，設(shè)計(jì)并確定系統(tǒng)整體結(jié)構(gòu)成為了新的問題。結(jié)構(gòu)問題包括總體組織結(jié)構(gòu)和全局控制結(jié)構(gòu)；通信、同步和數(shù)據(jù)訪問的協(xié)議；設(shè)計(jì)元素的功能分配；物理分布；設(shè)計(jì)元素的組成；定標(biāo)與性能；備選設(shè)計(jì)的選擇?！?/p>
2、與軟件體系結(jié)構(gòu)概念的細(xì)微區(qū)別
目前，沒有文獻(xiàn)表明軟件體系結(jié)構(gòu)與軟件架構(gòu)的差別。如果你強(qiáng)調(diào)方法論，應(yīng)使用軟件體系結(jié)構(gòu)。強(qiáng)調(diào)軟件開發(fā)實(shí)踐，應(yīng)使用軟件架構(gòu)。構(gòu)架不僅是結(jié)構(gòu)，IEEE Working Group on Architecture 把其定義為“系統(tǒng)在其環(huán)境中的最高層概念”。構(gòu)架還包括“符合”系統(tǒng)完整性、經(jīng)濟(jì)約束條件、審美需求和樣式。它并不僅注重對(duì)內(nèi)部的考慮，而且還在系統(tǒng)的用戶環(huán)境和開發(fā)環(huán)境中對(duì)系統(tǒng)進(jìn)行整體考慮，即同時(shí)注重對(duì)外部的考慮。在 Rational Unified ProcESs 中，軟件系統(tǒng)的構(gòu)架（在某一給定點(diǎn)）是指系統(tǒng)重要構(gòu)件的組織或結(jié)構(gòu)，這些重要構(gòu)件通過接口與不斷減小的構(gòu)件與接口所組成的構(gòu)件進(jìn)行交互。
軟件系統(tǒng)的架構(gòu)是一個(gè)軟件系統(tǒng)從整體到部分的最高層次的劃分。其有兩個(gè)要素：元件劃分和設(shè)計(jì)決定。詳細(xì)地說，就是要包括架構(gòu)元件（Architecture Component）、聯(lián)結(jié)器（Connector）、任務(wù)流（TASk-flow）。所謂架構(gòu)元素，也就是組成系統(tǒng)的核心"磚瓦"，而聯(lián)結(jié)器則描述這些元件之間通訊的路徑、通訊的機(jī)制、通訊的預(yù)期結(jié)果，任務(wù)流則描述系統(tǒng)如何使用這些元件和聯(lián)結(jié)器完成某一項(xiàng)需求。
3、研究的背景
在經(jīng)歷60年代的軟件危機(jī)之后,使人們開始重視軟件工程的研究。來自不同應(yīng)用領(lǐng)域的軟件專家總結(jié)了大量的有價(jià)值的知識(shí). 當(dāng)初,人們把軟件設(shè)計(jì)的重點(diǎn)放在數(shù)據(jù)結(jié)構(gòu)和算法的選擇上，如Knuth提出了數(shù)據(jù)結(jié)構(gòu)+算法=程序. 但是隨著軟件系統(tǒng)規(guī)模越來越大、越來越復(fù)雜，使軟件系統(tǒng)的架構(gòu)越來越重要。軟件危機(jī)的程度日益加劇，現(xiàn)有的軟件工程方法對(duì)此顯得力不從心。對(duì)于大規(guī)模的復(fù)雜軟件系統(tǒng)來說，軟件體系架構(gòu)比起對(duì)程序的算法和數(shù)據(jù)結(jié)構(gòu)的選擇已經(jīng)變得明顯重要得多。在此種背景下，人們認(rèn)識(shí)到軟件體系架構(gòu)的重要性，并認(rèn)為對(duì)軟件體系架構(gòu)系統(tǒng)、深入的研究將會(huì)成為提高軟件生產(chǎn)效率和解決軟件危機(jī)的最有希望的途徑
二、架構(gòu)的目標(biāo)
正如同軟件本身有其要達(dá)到的目標(biāo)一樣，架構(gòu)設(shè)計(jì)要達(dá)到的目標(biāo)是什么呢？一般而言，軟件架構(gòu)設(shè)計(jì)要達(dá)到如下的目標(biāo)：
·可靠性（Reliable）。軟件系統(tǒng)對(duì)于用戶的商業(yè)經(jīng)營(yíng)和管理來說極為重要，因此軟件系統(tǒng)必須非常可靠。
·安全行（Secure）。軟件系統(tǒng)所承擔(dān)的交易的商業(yè)價(jià)值極高，系統(tǒng)的安全性非常重要。
·可擴(kuò)展性（SCAlable）。軟件必須能夠在用戶的使用率、用戶的數(shù)目增加很快的情況下，保持合理的性能。只有這樣，才能適應(yīng)用戶的市場(chǎng)擴(kuò)展得可能性。
·可定制化（CuSTomizable）。同樣的一套軟件，可以根據(jù)客戶群的不同和市場(chǎng)需求的變化進(jìn)行調(diào)整。
·可擴(kuò)展性（Extensible）。在新技術(shù)出現(xiàn)的時(shí)候，一個(gè)軟件系統(tǒng)應(yīng)當(dāng)允許導(dǎo)入新技術(shù)，從而對(duì)現(xiàn)有系統(tǒng)進(jìn)行功能和性能的擴(kuò)展
·可維護(hù)性（MAIntainable）。軟件系統(tǒng)的維護(hù)包括兩方面，一是排除現(xiàn)有的錯(cuò)誤，二是將新的軟件需求反映到現(xiàn)有系統(tǒng)中去。一個(gè)易于維護(hù)的系統(tǒng)可以有效地降低技術(shù)支持的花費(fèi)
·客戶體驗(yàn)（Customer Experience）。軟件系統(tǒng)必須易于使用。
·市場(chǎng)時(shí)機(jī)（Time to Market）。軟件用戶要面臨同業(yè)競(jìng)爭(zhēng)，軟件提供商也要面臨同業(yè)競(jìng)爭(zhēng)。以最快的速度爭(zhēng)奪市場(chǎng)先機(jī)非常重要。
三、架構(gòu)的種類
根據(jù)我們關(guān)注的角度不同，可以將架構(gòu)分成三種：
·邏輯架構(gòu)：軟件系統(tǒng)中元件之間的關(guān)系，比如用戶界面，數(shù)據(jù)庫，外部系統(tǒng)接口，商業(yè)邏輯元件，等等。
·物理架構(gòu)：軟件元件是怎樣放到硬件上的。
·系統(tǒng)架構(gòu)：系統(tǒng)的非功能性特征，如可擴(kuò)展性、可靠性、強(qiáng)壯性、靈活性、性能等。
四、架構(gòu)的風(fēng)格
軟件體系結(jié)構(gòu)風(fēng)格（有時(shí)候也叫架構(gòu)模式）是描述某一特定應(yīng)用領(lǐng)域中系統(tǒng)組織方式的慣用模式，是為一個(gè)系統(tǒng)提供的一系列抽象框架。它反映了領(lǐng)域中眾多系統(tǒng)所共有的結(jié)構(gòu)和語義特性，并指導(dǎo)如何將各個(gè)模塊和子系統(tǒng)有效地組織成一個(gè)完整的系統(tǒng)。架構(gòu)風(fēng)格通過為經(jīng)常發(fā)生的問題提供解決方案，來提高設(shè)計(jì)重用和改善程序結(jié)構(gòu)。按這種方式理解，軟件體系結(jié)構(gòu)風(fēng)格定義了用于描述系統(tǒng)的術(shù)語表和一組指導(dǎo)構(gòu)件系統(tǒng)的規(guī)則。
通用軟件體系結(jié)構(gòu)風(fēng)格總結(jié)為以下幾類：
1.數(shù)據(jù)流風(fēng)格：批處理序列；管道過濾器。
2.調(diào)用返回風(fēng)格：主程序子程序；面向?qū)ο箫L(fēng)格；層次結(jié)構(gòu)。
3.獨(dú)立構(gòu)件風(fēng)格：進(jìn)程通訊；事件系統(tǒng)。
4.虛擬機(jī)風(fēng)格：解釋器；基于規(guī)則的系統(tǒng)。
5.倉庫風(fēng)格：數(shù)據(jù)庫系統(tǒng)；超文本系統(tǒng)；黑板系統(tǒng)。
幾種主要的和經(jīng)典的體系結(jié)構(gòu)風(fēng)格：
1.C2風(fēng)格。C2風(fēng)格是最常用的一種軟件體系結(jié)構(gòu)風(fēng)格，該體系結(jié)構(gòu)風(fēng)格可以概括為：通過連接件綁定在一起的按照一組規(guī)則運(yùn)作的并行構(gòu)件網(wǎng)絡(luò)。
2.數(shù)據(jù)抽象和面向?qū)ο箫L(fēng)格。目前軟件界已普遍轉(zhuǎn)向使用面向?qū)ο笙到y(tǒng)，抽象數(shù)據(jù)類型概念對(duì)軟件系統(tǒng)有著重要作用。這種風(fēng)格的構(gòu)件是對(duì)象，或者說是抽象數(shù)據(jù)類型的實(shí)例。對(duì)象是一種被稱作管理者的構(gòu)件，因?yàn)樗?fù)責(zé)保持資源的完整性。對(duì)象是通過函數(shù)和過程的調(diào)用來交互的。
3.基于事件的隱式調(diào)用風(fēng)格?；谑录碾[式調(diào)用風(fēng)格的思想是構(gòu)件不直接調(diào)用一個(gè)過程，而是觸發(fā)或廣播一個(gè)或多個(gè)事件。系統(tǒng)中的其他構(gòu)件中的過程在一個(gè)或多個(gè)事件中注冊(cè)，當(dāng)一個(gè)事件被觸發(fā)，系統(tǒng)自動(dòng)調(diào)用在這個(gè)事件中注冊(cè)的所有過程，這樣，一個(gè)事件的觸發(fā)就導(dǎo)致了另一模塊中的過程的調(diào)用。
4.管道/過濾器風(fēng)格。在管道/過濾器風(fēng)格的軟件體系結(jié)構(gòu)中，每個(gè)構(gòu)件都有一組輸入和輸出，構(gòu)件讀輸入的數(shù)據(jù)流，經(jīng)過內(nèi)部處理，然后產(chǎn)生輸出數(shù)據(jù)流。這個(gè)過程通常通過對(duì)輸入流的變換及增量計(jì)算來完成，所以在輸入被完全消費(fèi)之前，輸出便產(chǎn)生了。因此，這里的構(gòu)件被稱為過濾器，這種風(fēng)格的連接件就象是數(shù)據(jù)流傳輸?shù)墓艿?，將一個(gè)過濾器的輸出傳到另一過濾器的輸入。
5.批處理風(fēng)格。批處理風(fēng)格的每一步處理都是獨(dú)立的，并且每一步是順序執(zhí)行的，只有當(dāng)前一步處理完后，后一步處理才能開始，數(shù)據(jù)傳送在步與步之間作為一個(gè)整體。批處理的典型應(yīng)用是經(jīng)典數(shù)據(jù)處理和程序開發(fā)。
6.倉庫風(fēng)格。在倉庫風(fēng)格中，有兩種不同的構(gòu)件：中央數(shù)據(jù)結(jié)構(gòu)說明當(dāng)前狀態(tài)，獨(dú)立構(gòu)件在中央數(shù)據(jù)存貯上執(zhí)行，倉庫與外構(gòu)件間的相互作用在系統(tǒng)中會(huì)有大的變化。
五、常用的軟件架構(gòu)
一、C/S 架構(gòu)
優(yōu)點(diǎn)：C/S 體系結(jié)構(gòu)的優(yōu)點(diǎn)主要在于系統(tǒng)的客戶應(yīng)用程序和服務(wù)器構(gòu)件分別運(yùn)行在不同的 計(jì)算機(jī)上，
系統(tǒng)中每臺(tái)服務(wù)器都可以適合各構(gòu)件的要求，這對(duì)于硬件和軟件的變化顯示 出極大的適應(yīng)性和靈活性，而 且易于對(duì)系統(tǒng)進(jìn)行擴(kuò)充和縮小。在 C/S 體系結(jié)構(gòu)中，系統(tǒng) 中的功能構(gòu)件充分隔離，客戶應(yīng)用程序的開發(fā)集中于數(shù)據(jù)的顯示和分析，而數(shù)據(jù)庫服務(wù) 器的開發(fā)則集中于數(shù)據(jù)的管理，不必在每一個(gè)新的應(yīng)用程序中都要 對(duì)一個(gè) DBMS 進(jìn)行編 碼。將大應(yīng)用處理任務(wù)分布到許多通過網(wǎng)絡(luò)連接的低成本計(jì)算機(jī)上，以節(jié)約大量費(fèi)用。
缺點(diǎn)：
①開發(fā)成本較高。C/S 體系結(jié)構(gòu)對(duì)客戶端軟硬件配置要求較高，尤其是軟件的不斷升級(jí)，對(duì)硬件要求不斷提高，增加了整個(gè)系統(tǒng)的成本，且客戶端變得越來越臃腫。
②客戶端程序設(shè)計(jì)復(fù)雜。釆用 C/S 體系結(jié)構(gòu)進(jìn)行軟件開發(fā)，大部分工作量放在客戶端的程序設(shè)計(jì)上，客戶端顯得十分龐大。
③信息內(nèi)容和形式單一，因?yàn)閭鹘y(tǒng)應(yīng)用一般為事務(wù)處理，界面基本遒循數(shù)據(jù)庫字段解釋，開發(fā)之初就已確定， 而且不能隨時(shí)截取辦公信息和檔案等外部信息，用戶獲得的只是單純的字符和數(shù)字，既枯燥又死板。
④用戶界面風(fēng)格不一，使用繁雜，不利于推廣使用。
⑤軟件移植困難。采用不同開發(fā)工具或平臺(tái)開發(fā)的軟件一般互不兼容，不能或很 難移植到其他平臺(tái)上運(yùn)行。
⑥軟件維護(hù)和升級(jí)困難。采用 C/S 體系結(jié)構(gòu)的軟件要升級(jí)，開發(fā)人員必須到現(xiàn)場(chǎng) 為客戶機(jī)升級(jí)，每個(gè)客戶機(jī)上的軟件都需維護(hù)。對(duì)軟件的一個(gè)小小改動(dòng)（例如只改動(dòng)一 個(gè)變量)，每一個(gè)客戶端都必須更新。
二、三層 C/S 架構(gòu)
這種客戶機(jī)稱為瘦客戶機(jī)（thin client）。三層 C/S 架構(gòu)將應(yīng)用系統(tǒng)分成表示層、功能層和數(shù)據(jù)層三個(gè)部分。
①表示層。表示層是系統(tǒng)的用戶接口部分，擔(dān)負(fù)著用戶與系統(tǒng)之間的對(duì)話功能。它用于檢查用戶從鍵盤等輸入的數(shù)據(jù)，顯示輸出的數(shù)據(jù)。
②功能層。功能層也稱為業(yè)務(wù)邏輯層，是將具體的業(yè)務(wù)處理邏輯編入程序中。例如，在制作訂購合同時(shí)要計(jì)算合同金額、按照預(yù)定的格式配置數(shù)據(jù)、打印訂購合同，而處理所需的數(shù)據(jù)則要從表示層或數(shù)據(jù)層取得。
③數(shù)據(jù)層。數(shù)據(jù)層相當(dāng)于二層 C/S 架構(gòu)中的服務(wù)器，負(fù)責(zé)對(duì) DBMS 的管理和控制。
三、B/S 架構(gòu)
基于 B/S 體系結(jié)構(gòu)的軟件，系統(tǒng)安裝、修改和維護(hù)全在服務(wù)器端解決。用戶在使用系統(tǒng)時(shí)，僅僅需要一個(gè)瀏覽器就可運(yùn)行全部的模塊。真正達(dá)到了“零客戶端”的功能，很容易在運(yùn)行時(shí)自動(dòng)升級(jí)。B/S 體系結(jié)構(gòu)還提供了異種機(jī)、異種網(wǎng)、異種應(yīng)用服務(wù)的聯(lián)機(jī)、聯(lián)網(wǎng)等。
與 C/S 體系結(jié)構(gòu)相比，B/S 體系結(jié)構(gòu)也有許多不足之處，例如：
①B/S 體系結(jié)構(gòu)缺乏對(duì)動(dòng)態(tài)頁面的支持能力，沒有集成有效的數(shù)據(jù)庫處理功能。
②B/S 體系結(jié)構(gòu)的系統(tǒng)擴(kuò)展能力差，安全性較難以控制。
③采用 B/S 體系結(jié)構(gòu)的應(yīng)用系統(tǒng)，在數(shù)據(jù)査詢等響應(yīng)速度上，要遠(yuǎn)遠(yuǎn)地低于 C/S 體系結(jié)構(gòu)。
④B/S 體系結(jié)構(gòu)的數(shù)據(jù)提交一般以頁面為單位，數(shù)據(jù)的動(dòng)態(tài)交互性不強(qiáng)，不利于在線事務(wù)處理 OLTP 應(yīng)用。
多層架構(gòu)的優(yōu)點(diǎn)：
開發(fā)人員可以只關(guān)注整個(gè)結(jié)構(gòu)中的其中某一層；
可以很容易的用新的實(shí)現(xiàn)來替換原有層次的實(shí)現(xiàn)；
可以降低層與層之間的依賴；
有利于標(biāo)準(zhǔn)化；
利于各層邏輯的復(fù)用；
擴(kuò)展性強(qiáng)。不同層負(fù)責(zé)不同的層面；
安全性高。用戶端只能通過邏輯層來訪問數(shù)據(jù)層，減少了入口點(diǎn)，把很多危險(xiǎn)的系統(tǒng)功能都屏蔽了。
項(xiàng)目結(jié)構(gòu)更清楚，分工更明確，有利于后期的維護(hù)和升級(jí)。
多層架構(gòu)的缺點(diǎn)：
嚴(yán)格的分層可能導(dǎo)致性能問題，具體取決于層數(shù)。
建立清晰的分層架構(gòu)并不總是很容易。
四、面向服務(wù)的架構(gòu) SOA
SOA 架構(gòu)中所有的功能都定義成了獨(dú)立的服務(wù)。服務(wù)之間通過交互和協(xié)調(diào)完成業(yè)務(wù)的整體邏輯。所有的服務(wù)
通過服務(wù)總線或流程管理器來連接。這種松散耦合的架構(gòu)使得各服務(wù)在交互過程中無需考慮雙方的內(nèi)部實(shí)現(xiàn)細(xì)節(jié)，以及部署在什么平臺(tái)上。
SOA 架構(gòu)將應(yīng)用程序的不同功能單元按照服務(wù)模塊拆分成多個(gè)子系統(tǒng)，這樣做的優(yōu)勢(shì)：
（1）把系統(tǒng)按服務(wù)模塊拆分，各個(gè)模塊獨(dú)立開發(fā)，獨(dú)立部署，互不影響，大幅降低了模塊之間的耦合度，各個(gè)服務(wù)模塊后面可以使用不同的技術(shù)；
（2）把項(xiàng)目拆分成若干個(gè)子項(xiàng)目，不同的團(tuán)隊(duì)負(fù)責(zé)不同的子項(xiàng)目，大幅度提高團(tuán)隊(duì)的開發(fā)和生產(chǎn)效率；
（3）增加業(yè)務(wù)子系統(tǒng)時(shí)只需要增加一個(gè)子應(yīng)用項(xiàng)目，調(diào)用服務(wù)就可以快速組裝子應(yīng)用，提高了程序的復(fù)用性，可以更快速的進(jìn)行業(yè)務(wù)創(chuàng)新；
（4）可以靈活的進(jìn)行分布式部署，更好的支持在線業(yè)務(wù)。
在 SOA 架構(gòu)中，繼承了來自對(duì)象和構(gòu)件設(shè)計(jì)的各種原則，例如，封裝和自我包含等。那些保證服務(wù)的靈活性、松散耦合和復(fù)用能力的設(shè)計(jì)原則，對(duì) SOA 架構(gòu)來說同樣是非常重要的。關(guān)于服務(wù)，一些常見的設(shè)計(jì)原則如下：
（1）明確定義的接口。服務(wù)請(qǐng)求者依賴于服務(wù)規(guī)約來調(diào)用服務(wù)，因此，服務(wù)定義必須長(zhǎng)時(shí)間穩(wěn)定，一旦公布，不能隨意更改；服務(wù)的定義應(yīng)盡可能明確，減少請(qǐng)求者的不適當(dāng)使用；不要讓請(qǐng)求者看到服務(wù)內(nèi)部的私有數(shù)據(jù)。
（2）自包含和模塊化。服務(wù)封裝了那些在業(yè)務(wù)上穩(wěn)定、重復(fù)出現(xiàn)的活動(dòng)和構(gòu)件，實(shí)現(xiàn)服務(wù)的功能實(shí)體是完全獨(dú)立自主的，獨(dú)立進(jìn)行部署、版本控制、自我管理和恢復(fù)。
SOA 架構(gòu)中的關(guān)鍵技術(shù)：
（1）SOAP：簡(jiǎn)單對(duì)象訪問協(xié)議，Simple Object Access Protocol
（2）WSDL：Web 服務(wù)描述語言，Web Services Description Language
（3）UDDI：統(tǒng)一描述、發(fā)現(xiàn)和集成，Universal Description Discovery and Integration
WSDL 用來描述服務(wù)，UDDI 用來注冊(cè)和查找服務(wù)，而 SOAP 作為傳輸層，用來在消費(fèi)這和服務(wù)者之間傳送消息，一個(gè)消費(fèi)者可以在 UDDI 注冊(cè)表查找服務(wù)，取得服務(wù)的 WSDL 描述，然后通過 SOAP 來調(diào)用該服務(wù)。
（4）REST
REST 提出了如下一些設(shè)計(jì)概念和準(zhǔn)則：
①網(wǎng)絡(luò)上的所有事物都被抽象為資源。
②每個(gè)資源對(duì)應(yīng)一個(gè)唯一的資源標(biāo)識(shí)。
③通過通用的連接件接口對(duì)資源進(jìn)行操作。
④對(duì)資源的各種操作不會(huì)改變資源標(biāo)識(shí)。
⑤所有的操作都是無狀態(tài)的。
目前，實(shí)現(xiàn) SOA 的方法也比較多，其中主流方式有 Web Service、企業(yè)服務(wù)總線和服務(wù)注冊(cè)表。
（1）Web Service
在 Web Service（Web 服務(wù)）的解決方案中，一共有三種工作角色，其中服務(wù)提供者和服務(wù)請(qǐng)求者是必須的，服務(wù)注冊(cè)中心是一個(gè)可選的角色。它們之間的交互和操作構(gòu)成了 SOA 的一種實(shí)現(xiàn)架構(gòu)。
（2）服務(wù)注冊(cè)表
服務(wù)注冊(cè)表（service registry）雖然也具有運(yùn)行時(shí)的功能，但主要在 SOA 設(shè)計(jì)時(shí)使用。它提供個(gè)
策略執(zhí)行點(diǎn)（Policy Enforcement Point，PEP），在這個(gè)點(diǎn)上，服務(wù)可以在 SOA 中注冊(cè)，從而可以被發(fā)現(xiàn) 和使用。服務(wù)注冊(cè)表可以包括有關(guān)服務(wù)和相關(guān)構(gòu)件的配置、依從性和約束文件。從理論上來說，任何幫助 服務(wù)注冊(cè)、發(fā)現(xiàn)和查找服務(wù)合約、元數(shù)據(jù)和策略的信息庫、數(shù)據(jù)庫、目錄或其他節(jié)點(diǎn)都可以被認(rèn)為是一個(gè) 注冊(cè)表。大多數(shù)商用服務(wù)注冊(cè)產(chǎn)品支持服務(wù)注冊(cè)、服務(wù)位置和服務(wù)綁定功能。
（3）企業(yè)服務(wù)總線 ESB
是 SOA 的一種實(shí)現(xiàn)方式, ESB 在面向服務(wù)的架構(gòu)中起到的是總線作用,將各種服務(wù)進(jìn)行連接與整合，主要作 用：
描述服務(wù)的元數(shù)據(jù)和服務(wù)注冊(cè)管理；
在服務(wù)請(qǐng)求者和提供者之間傳遞數(shù)據(jù),以及對(duì)這些數(shù)據(jù)進(jìn)行轉(zhuǎn)換的能力,并支持由實(shí)踐中總結(jié)出來的一 些模式如同步模式、異步模式等；
發(fā)現(xiàn)、路由、匹配和選擇的能力,以支持服務(wù)之間的動(dòng)態(tài)交互,解耦服務(wù)請(qǐng)求者和服務(wù)提供者。高級(jí)一 些的能力,包括對(duì)安全的支持、服務(wù)質(zhì)量保證、可管理性和負(fù)載平衡等。
五、微服務(wù)架構(gòu)
微服務(wù)優(yōu)點(diǎn)：
（1）每個(gè)微服務(wù)都很小，這樣能聚焦一個(gè)指定的業(yè)務(wù)功能或業(yè)務(wù)需求。
（2）微服務(wù)能夠被小團(tuán)隊(duì)單獨(dú)開發(fā)，這個(gè)小團(tuán)隊(duì)是 2 到 5 人的開發(fā)人員組成。
（3）微服務(wù)是松耦合的，是有功能意義的服務(wù)，無論是在開發(fā)階段或部署階段都是獨(dú)立的。
（4）微服務(wù)能使用不同的語言開發(fā)。
（5）去中心化。每個(gè)微服務(wù)都有自己的存儲(chǔ)能力，可以有自己的數(shù)據(jù)庫。也可以有統(tǒng)一數(shù)據(jù)庫。
微服務(wù)缺點(diǎn)：
（1）很難在不采用分布式事務(wù)的情況下跨服務(wù)實(shí)現(xiàn)功能
（2）測(cè)試工作更加困難
（3）跨服務(wù)實(shí)現(xiàn)要求功能要求團(tuán)隊(duì)之間的緊密協(xié)作
（4）部署復(fù)雜
在微服務(wù)中，應(yīng)用網(wǎng)關(guān) API 的作用:
（1）提供統(tǒng)一入口
（2）可以進(jìn)行權(quán)限身份認(rèn)證等安全管理
（3）可以根據(jù)流量進(jìn)行限流
（4）數(shù)據(jù)緩存
（5）性能監(jiān)控等
（6）異常重試
（7）服務(wù)降級(jí)
六、輕量級(jí)架構(gòu)
（1）SSH：指的是 Struts2(做前端控制器)，Spring(管理各層的組件)，Hibernate(負(fù)責(zé)持久化層)
（2）SSM：指的是 SpringMVC(做前端控制器)，Spring(管理各層的組件)，Mybatis(負(fù)責(zé)持久化層)
Hibernate 與 Mybatis 區(qū)別：
①開發(fā)方面：在項(xiàng)目開發(fā)過程當(dāng)中，就速度而言，hibernate 開發(fā)中，sql 語句已經(jīng)被封裝，直接可以使用，加快系統(tǒng)開發(fā)；Mybatis 屬于半自動(dòng)化，sql 需要手工完成，稍微繁瑣。
②sql 優(yōu)化方面：Hibernate 自動(dòng)生成 sql,有些語句較為繁瑣，會(huì)多消耗一些性能；Mybatis 手動(dòng)編寫 sql，可以避免不需要的查詢，提高系統(tǒng)性能；
③對(duì)象管理方面：Hibernate 是完整的對(duì)象-關(guān)系映射的框架，開發(fā)工程中，無需過多關(guān)注底層實(shí)現(xiàn)，只要去管理對(duì)象即可；Mybatis 需要自行管理映射關(guān)系；
④ 緩存方面：Hibernate 在使用二級(jí)緩存時(shí)如果出現(xiàn)臟數(shù)據(jù)，系統(tǒng)會(huì)報(bào)出錯(cuò)誤并提示。Mybatis 臟讀不報(bào)錯(cuò)。
六、關(guān)于架構(gòu)
1、EAI與SOA之比較
EAI是將基于異構(gòu)平臺(tái)下的業(yè)務(wù)應(yīng)用系統(tǒng)集成在一起的一種技術(shù)。EAI通過中間件作為粘合劑來連接企業(yè)內(nèi)外各種業(yè)務(wù)相關(guān)的異構(gòu)系統(tǒng)、應(yīng)用以及數(shù)據(jù)源，從而滿足企業(yè)內(nèi)部應(yīng)用系統(tǒng)之間信息共享的需要。
SOA(面向服務(wù)的體系結(jié)構(gòu))將企業(yè)中各個(gè)系統(tǒng)應(yīng)用程序的不同功能單元抽象為服務(wù)，通過這些服務(wù)之間定義良好的接口和契約聯(lián)系起來。接口是采用中立的方式進(jìn)行定義的，它獨(dú)立于實(shí)現(xiàn)服務(wù)的硬件平臺(tái)、操作系統(tǒng)和編程語言。這使得構(gòu)建在各種各樣的系統(tǒng)中的服務(wù)能夠通過統(tǒng)一和通用的方式進(jìn)行交互。SOA架構(gòu)由服務(wù)總線、服務(wù)目錄、門戶、流程管理等幾個(gè)核心組件構(gòu)成的。這些核心組件協(xié)同工作共同支撐服務(wù)的部署、運(yùn)行與管理監(jiān)控。
從以下的幾個(gè)方面對(duì)EAI與SOA進(jìn)行比較：
1. 集成的本質(zhì)
EAI的集成方式從本質(zhì)而言是基于消息的集成，因此EAI的各組成部件，如適配器與hub，都帶有消息轉(zhuǎn)換與消息路由的功能，在EAI的運(yùn)作過程中，單個(gè)應(yīng)用系統(tǒng)只關(guān)心其與EAI連接部分消息的輸入與輸出，不關(guān)心具體的業(yè)務(wù)處理，業(yè)務(wù)處理都是在應(yīng)用系統(tǒng)內(nèi)部完成的。
SOA的集成方式，其本質(zhì)是對(duì)業(yè)務(wù)功能服務(wù)化后根據(jù)業(yè)務(wù)流程進(jìn)行編排，是真正意義上的基于功能服務(wù)的集成。當(dāng)然在基于SOA的集成中同樣包含了基于消息集成的功能。
因此基于SOA的集成方式比EAI的集成方式適用范圍更廣。
2. 集成對(duì)象的顆粒度
SOA和EAI從不同的視角切入去看待企業(yè)已有的信息資源，并基于此對(duì)企業(yè)已有的資源進(jìn)行梳理、分類和集成。
EAI從應(yīng)用系統(tǒng)的層面去看待企業(yè)已有信息資源，企業(yè)的每一個(gè)應(yīng)用系統(tǒng)被看作一個(gè)集成單元，EAI工作的目標(biāo)就是，通過為這些已有的應(yīng)用系統(tǒng)提供一種中間溝通方式，讓這些應(yīng)用軟件之間可以進(jìn)行數(shù)據(jù)的共享與交換，從而盤活這一個(gè)個(gè)獨(dú)立的“信息孤島”。
SOA從提供服務(wù)、使用服務(wù)的角度去看待企業(yè)已有的信息資源。在這種方式下，同樣的一種資源既可能是服務(wù)提供者，也同樣可以是服務(wù)使用者； 在這種方式下，一個(gè)應(yīng)用模塊可能只提供一種服務(wù)，因此被封裝成一個(gè)服務(wù)，也可能由于提供了多種服務(wù)，而需要進(jìn)一步劃分。
顯然，SOA方式集成處理的顆粒度比EAI要小，因此SOA方式比EAI方式更具有靈活性。
3. 標(biāo)準(zhǔn)化
SOA在實(shí)現(xiàn)企業(yè)信息化集成的同時(shí)，也將實(shí)現(xiàn)企業(yè)級(jí)服務(wù)的高度可重用作為目標(biāo)，因此，在SOA架構(gòu)中任何一種接口、通訊、協(xié)議都是遵循相應(yīng)的國(guó)際標(biāo)準(zhǔn)，如：標(biāo)準(zhǔn)描述語言（WSDL）、發(fā)現(xiàn)協(xié)議（UDDI)和消息協(xié)議(SOAP)等。
EAI則大多使用基于具體實(shí)施EAI企業(yè)中制定的私有標(biāo)準(zhǔn)。基于私有標(biāo)準(zhǔn)的優(yōu)點(diǎn)是可以在一定程度上減輕EAI中間層對(duì)應(yīng)用系統(tǒng)消息翻譯轉(zhuǎn)換的壓力，在應(yīng)用系統(tǒng)較少的情況下可以提高EAI的整體性能，但私有標(biāo)準(zhǔn)同時(shí)也對(duì)企業(yè)整合的靈活可擴(kuò)展性上帶來損失，當(dāng)企業(yè)引入新的應(yīng)用系統(tǒng)，或當(dāng)某個(gè)應(yīng)用系統(tǒng)需要做比較大的改動(dòng)時(shí)，整個(gè)EAI總線的適應(yīng)性將變得十分脆弱。
在系統(tǒng)較少的情況下或是系統(tǒng)集成的早期階段，采用私有標(biāo)準(zhǔn)的EAI會(huì)體現(xiàn)出性能高，實(shí)現(xiàn)難度低等優(yōu)點(diǎn)，但在企業(yè)規(guī)模不斷增長(zhǎng)的過程中，新引入系統(tǒng)的整合難度將因?yàn)闃?biāo)準(zhǔn)的不統(tǒng)一而呈指數(shù)級(jí)上升。
4. 靈活可擴(kuò)展性
由于對(duì)標(biāo)準(zhǔn)的良好支持，使得SOA具有可靈活擴(kuò)展的特性，而EAI要達(dá)到同樣的擴(kuò)展效果，其代價(jià)將遠(yuǎn)遠(yuǎn)高于SOA。例如，現(xiàn)在有甲、乙兩個(gè)系統(tǒng)需要集成。假設(shè)它們通過SOA完成集成形成A方案，使用EAI完成集成形成B方案。當(dāng)集成需求發(fā)生變化后，甲乙兩個(gè)系統(tǒng)需要以另外一種業(yè)務(wù)邏輯進(jìn)行集成。對(duì)于A方案而言，所需要做的工作比較簡(jiǎn)單，只需將之前的業(yè)務(wù)邏輯打開，重新組合一下業(yè)務(wù)邏輯就可以實(shí)現(xiàn)。而對(duì)于B方案而言，過程就會(huì)麻煩的多，需要根據(jù)新的業(yè)務(wù)邏輯，重新設(shè)計(jì)開發(fā)滿足新業(yè)務(wù)邏輯需要的適配器和中間層的消息處理邏輯。
5. 重用性
企業(yè)信息化建設(shè)的投資可以分為兩個(gè)部分：現(xiàn)有應(yīng)用系統(tǒng)的維護(hù)與新系統(tǒng)的開發(fā)費(fèi)用。在SOA架構(gòu)下，各個(gè)服務(wù)是以完全獨(dú)立的方式通過服務(wù)目錄暴露在SOA集成平臺(tái)上的，當(dāng)新集成進(jìn)來的應(yīng)用系統(tǒng)需要使用現(xiàn)有的某個(gè)服務(wù)時(shí)，可以直接使用，無需再次開發(fā)，即服務(wù)是可重用的，只需用開發(fā)目前還沒有的業(yè)務(wù)功能服務(wù)，這樣可以充分利用現(xiàn)有的資源，降低成本。
通過EAI方式實(shí)現(xiàn)企業(yè)應(yīng)用集成，其開發(fā)的適配器、中間層消息轉(zhuǎn)換規(guī)則和消息路由都是緊耦合的，當(dāng)新系統(tǒng)要在EAI中進(jìn)行集成，便需要對(duì)現(xiàn)有的部分適配器、中間層消息轉(zhuǎn)換規(guī)則與消息路由進(jìn)行改造，無法重用。
因此，使用SOA比使用EAI更經(jīng)濟(jì)，尤其在多個(gè)應(yīng)用系統(tǒng)相互集成的復(fù)雜場(chǎng)景下，SOA的優(yōu)點(diǎn)將更加突出。
6. SOA企業(yè)服務(wù)總線與EAI總線的比較
ESB(Enterprise Service Bus企業(yè)服務(wù)總線）是一種用于推動(dòng)SOA的基礎(chǔ)設(shè)施，從技術(shù)上而言，企業(yè)服務(wù)總線是一種消息傳遞的主干線，它用于提供協(xié)議轉(zhuǎn)換，消息格式的轉(zhuǎn)換，地址路由，接收并分發(fā)從各個(gè)連接到ESB的服務(wù)請(qǐng)求與系統(tǒng)傳遞來的消息。
在EAI的總線架構(gòu)中，EAI為消息傳播提供了一個(gè)中央消息主干線---Bus。應(yīng)用程序使用適配器將消息發(fā)布到總線，消息通過總線流動(dòng)到預(yù)訂的應(yīng)用程序中?？偩€是消息流動(dòng)的通道，捆綁在應(yīng)用軟件端的適配器負(fù)責(zé)將消息在應(yīng)用程序端的格式與符合總線標(biāo)準(zhǔn)的格式之間轉(zhuǎn)換。因此，對(duì)于每一個(gè)應(yīng)用程序，都需要單獨(dú)為其開發(fā)符合應(yīng)用程序自身要求的適配器，而由于沒有遵循統(tǒng)一的標(biāo)準(zhǔn)，這些適配器是無法通用的。當(dāng)某個(gè)應(yīng)用系統(tǒng)進(jìn)行比較大的改動(dòng)時(shí)，則有可能存在對(duì)適配器的改造已經(jīng)不能滿足系統(tǒng)變更需求的情況，此時(shí)甚至有可能會(huì)牽涉到對(duì)BUS總線的修改，給企業(yè)信息架構(gòu)帶來很大的風(fēng)險(xiǎn)。
從ESB和EAI的總線工作過程上的區(qū)別可以看出ESB承擔(dān)了更多的責(zé)任，做了更多的事情，為集成后的系統(tǒng)提供了完善、堅(jiān)固的底層支持。而EAI的總線，只是一個(gè)消息的分發(fā)器。功能上的差別導(dǎo)致了系統(tǒng)集成到總線上的代價(jià)的巨大差異。
7. 系統(tǒng)集成的代價(jià)
SOA架構(gòu)中的企業(yè)服務(wù)總線與EAI中私有形式BUS盡管結(jié)構(gòu)較為相似，但是在系統(tǒng)集成中卻導(dǎo)致集成的成本代價(jià)卻有很大的差別。這種在代價(jià)上的差異主要由兩個(gè)方面的因素造成的，一是私有形式的總線提供很多產(chǎn)品套件式的內(nèi)建函數(shù)功能，這些函數(shù)功能需要根據(jù)業(yè)務(wù)需求進(jìn)行開發(fā)；二是很多的私有形式的總線采用專有的消息格式來提高性能，但卻增加了系統(tǒng)開發(fā)代價(jià)。企業(yè)服務(wù)總線都是基于標(biāo)準(zhǔn)的。企業(yè)服務(wù)總線主要的優(yōu)點(diǎn)就是相比集線器架構(gòu)和基于產(chǎn)品套件的總線架構(gòu)的支出要低，而且它是完全基于業(yè)界標(biāo)準(zhǔn)化。
另一個(gè)關(guān)鍵的不同是：ESB具有分散的和分布式體系結(jié)構(gòu)，更加輕型的安裝，而EAI遵從HUB-SPOKE體系結(jié)構(gòu)，因而企業(yè)中進(jìn)行多個(gè)大型應(yīng)用系統(tǒng)之間的集成時(shí)，硬件成本高，擴(kuò)展性也會(huì)相對(duì)比較薄弱。.
2、編制和編排的差別
編制(Orchestration)指為業(yè)務(wù)流程而進(jìn)行Web服務(wù)合成，用于定義合成服務(wù)以及重用已有服務(wù)的內(nèi)部流程。面向可執(zhí)行流程:流程編制使用個(gè)可執(zhí)行中心流程來協(xié)同內(nèi)部及外部Web Service交互通過中心流程來控制總體目標(biāo)涉及操作服務(wù)順序這種集中化管理使Web服務(wù)能夠在不了解彼此影響情況下進(jìn)行添加和刪除還允許在出現(xiàn)和異常情況下進(jìn)行補(bǔ)償其結(jié)果可以看作個(gè)新Web Service可以執(zhí)行只是執(zhí)行過程需要?jiǎng)eWeb服務(wù)。編制雖然是采用統(tǒng)控制方式但是編制狀態(tài)為由里向外方式來反映視角集中在具體參和者活動(dòng)。
編排(Choreography)指為業(yè)務(wù)協(xié)作而進(jìn)行Web服務(wù)合成，用于定義多方如何在一個(gè)更大的業(yè)務(wù)事務(wù)中，通過交易伙伴及外部機(jī)構(gòu)交換信息，進(jìn)行對(duì)等的協(xié)作。面向合作:更多強(qiáng)調(diào)協(xié)同工作和業(yè)務(wù)合作能力通過消息交互序列來控制各個(gè)部分資源交互參和交互資源都是對(duì)等沒有集中控制。例如在供應(yīng)鏈方面實(shí)施產(chǎn)品采購可能涉及到多家公司定單、發(fā)貨通知單和資金交互編排不描述每個(gè)公司如何處理操作只描述區(qū)別公司如何彼此交互實(shí)際上我們?cè)诰唧w分析個(gè)流程時(shí)候經(jīng)常從Choreography思路方法開始每個(gè)參和人部門或公司會(huì)告訴我們:“如果我得到了個(gè)文檔下面我應(yīng)該做什么……然后傳遞給XYZ”當(dāng)他們將流程控制權(quán)傳遞給操作下步驟人部門或公司時(shí)候他們對(duì)流程控制就結(jié)束了當(dāng)然我們可以使用這種方式來設(shè)計(jì)流程這種方式流程避免了集中控制可以更好被度量缺點(diǎn)是對(duì)整個(gè)流程狀態(tài)控制及分析流程原因是比較困難在個(gè)大公司或組織中是沒有人了解誰在負(fù)責(zé)這具體流程。
編制雖然沒有采用集中控制但是編制視角是從面向整個(gè)系統(tǒng)。
SOAP (Simple Object Access Protocol) 顧名思義，是一個(gè)嚴(yán)格定義的信息交換協(xié)議，用于在Web Service中把遠(yuǎn)程調(diào)用和返回封裝成機(jī)器可讀的格式化數(shù)據(jù)。事實(shí)上SOAP數(shù)據(jù)使用XML數(shù)據(jù)格式，定義了一整套復(fù)雜的標(biāo)簽，以描述調(diào)用的遠(yuǎn)程過程、參數(shù)、返回值和出錯(cuò)信息等等。而且隨著需要的增長(zhǎng)，又不得增加協(xié)議以支持安全性，這使SOAP變得異常龐大，背離了簡(jiǎn)單的初衷。另一方面，各個(gè)服務(wù)器都可以基于這個(gè)協(xié)議推出自己的API，即使它們提供的服務(wù)及其相似，定義的API也不盡相同，這又導(dǎo)致了WSDL的誕生。WSDL (Web Service Description Language) 也遵循XML格式，用來描述哪個(gè)服務(wù)器提供什么服務(wù)，怎樣找到它，以及該服務(wù)使用怎樣的接口規(guī)范，簡(jiǎn)言之，服務(wù)發(fā)現(xiàn)?，F(xiàn)在，使用Web Service的過程變成，獲得該服務(wù)的WSDL描述，根據(jù)WSDL構(gòu)造一條格式化的SOAP請(qǐng)求發(fā)送給服務(wù)器，然后接收一條同樣SOAP格式的應(yīng)答，最后根據(jù)先前的WSDL解碼數(shù)據(jù)。絕大多數(shù)情況下，請(qǐng)求和應(yīng)答使用HTTP協(xié)議傳輸，那么發(fā)送請(qǐng)求就使用HTTP的POST方法。
什么是REST？
REST (REpresentational State Transfort) 形式上應(yīng)該表述為客戶端通過申請(qǐng)資源來實(shí)現(xiàn)狀態(tài)的轉(zhuǎn)換，在這個(gè)角度系統(tǒng)可以看成一臺(tái)虛擬的狀態(tài)機(jī)。拋開R. T. Fielding博士論文里晦澀的理論不說，REST應(yīng)該滿足這樣的特點(diǎn)：1)客戶端和服務(wù)器結(jié)構(gòu)；2)連接協(xié)議具有無狀態(tài)性；3)能夠利用Cache機(jī)制增進(jìn)性能；4)層次化的系統(tǒng)；5)按需代碼。說到底，REST只是一種架構(gòu)風(fēng)格，而不是協(xié)議或標(biāo)準(zhǔn)。但這種新的風(fēng)格（也許已經(jīng)歷史悠久？）對(duì)現(xiàn)有的以SOAP為代表的Web Service造成的沖擊也是革命性的，因?yàn)樗嫦蛸Y源，甚至連服務(wù)也抽象成資源，因?yàn)樗虷TTP緊密結(jié)合，因?yàn)樗?wù)器無狀態(tài)。
REST與SOAP的區(qū)別：因?yàn)镾OAP并不假定傳輸數(shù)據(jù)的下層協(xié)議，因此必須設(shè)計(jì)為能在各種協(xié)議上運(yùn)行。即使絕大多數(shù)SOAP是運(yùn)行在HTTP上，使用URI標(biāo)識(shí)服務(wù)，SOAP也僅僅使用POST方法發(fā)送請(qǐng)求，用一個(gè)唯一的URI標(biāo)識(shí)服務(wù)的入口。舉一個(gè)圖書館在線查詢管理系統(tǒng)為例，服務(wù)提供者必須為每一本書提供一個(gè)內(nèi)部標(biāo)識(shí)，然后可能定義一個(gè)listBooks操作來返回一系列圖書，一個(gè)getBook操作來返回指定的圖書，一個(gè)createBook操作來向數(shù)據(jù)庫加入新增的圖書，一個(gè)deleteBook操作來刪除作廢的圖書，每個(gè)操作都有各自的參數(shù)，尤其是用內(nèi)部標(biāo)識(shí)來標(biāo)識(shí)操作的圖書。這種設(shè)計(jì)被詬病之處，在于deleteBook操作也要用POST方法來發(fā)送，而其實(shí)HTTP協(xié)議有更和邏輯的DELETE方法可用。REST正是這樣設(shè)計(jì)的，REST為每一個(gè)資源（此處是圖書）指定一個(gè)唯一的URI，而用HTTP的4種方法GET、POST、PUT、DELETE直觀地表示獲取、創(chuàng)建、更新和刪除圖書。同時(shí)圖書集合也是和單本的圖書不同的資源，如果用/books來代表圖書列表，/books/ID來代表標(biāo)識(shí)為ID的圖書，那么對(duì)/books的GET操作就代表返回整個(gè)圖書列表，對(duì)/books/ID的DELETE操作代表刪除指定的圖書，等等。
REST的優(yōu)點(diǎn)：REST簡(jiǎn)單而直觀，把HTTP協(xié)議利用到了極限，在這種思想指導(dǎo)下，它甚至用HTTP請(qǐng)求的頭信息來指明資源的表示形式（如果一個(gè)資源有多種形式的話，例如人類友善的頁面還是機(jī)器可讀的數(shù)據(jù)？），用HTTP的錯(cuò)誤機(jī)制來返回訪問資源的錯(cuò)誤。由此帶來的直接好處是構(gòu)建的成本減少了，例如用URI定位每一個(gè)資源可以利用通用成熟的技術(shù)，而不用再在服務(wù)器端開發(fā)一套資源訪問機(jī)制。又如只需簡(jiǎn)單配置服務(wù)器就能規(guī)定資源的訪問權(quán)限，例如通過禁止非GET訪問把資源設(shè)成只讀。服務(wù)器無狀態(tài)帶來了更多額外好處，因?yàn)槊看握?qǐng)求都包含響應(yīng)需要的所有信息，所有狀態(tài)信息都存儲(chǔ)在客戶端，服務(wù)器的內(nèi)存從龐大的狀態(tài)信息中解放出來。而且現(xiàn)在即使一臺(tái)服務(wù)器突然死機(jī)對(duì)客戶的影響也微乎其微，因?yàn)榱硪慌_(tái)服務(wù)器可以馬上代替它的位置，而不需要考慮恢復(fù)狀態(tài)信息。更多的緩存也變成可能，而之前由于服務(wù)器有狀態(tài)，對(duì)同一個(gè)URI的請(qǐng)求可能導(dǎo)致完全不同的響應(yīng)?？傮w結(jié)果是，網(wǎng)絡(luò)的容錯(cuò)性和延展性都增強(qiáng)了。
什么是微服務(wù)？
微服務(wù)是一種軟件開發(fā)技術(shù)，是面向服務(wù)的體系結(jié)構(gòu)（SOA）架構(gòu)風(fēng)格的一種變體。微服務(wù)將應(yīng)用程序構(gòu)造為一組松散耦合的服務(wù)，微服務(wù)中單個(gè)應(yīng)用程序由許多松散耦合且可獨(dú)立部署的較小組件或服務(wù)組成。
微服務(wù)架構(gòu)關(guān)鍵原則：
1. 每一個(gè) URI 代表 1 種資源
2. 客戶端使用 HTTP Verb 表示操作方式的動(dòng)詞對(duì)服務(wù)端資源進(jìn)行操作
3. 通過操作資源的表現(xiàn)形式來操作資源
4. 資源的表現(xiàn)形式是 XML 或者 HTML
5. 客戶端與服務(wù)端之間的交互是無狀態(tài)的，客戶端每個(gè)請(qǐng)求必須包含理解請(qǐng)求所必需的所有信息
微服務(wù)的特點(diǎn)是：小細(xì)專輕松獨(dú)。小是相對(duì)于服務(wù)的粒度而言；細(xì)：粒度細(xì)微；專：專注于一件事；輕：輕量級(jí)的通信機(jī)制。松：松耦合的。獨(dú)：獨(dú)立性強(qiáng)、獨(dú)立部署。
微服務(wù)的優(yōu)勢(shì)：
（1）技術(shù)異構(gòu)性
（2）有彈性
（3）擴(kuò)展性
（4）自動(dòng)部署
（5）與組織相匹配
（6）服務(wù)之間可組合性
（7）對(duì)可替代的優(yōu)化
微服務(wù)的缺點(diǎn)：
（1）分布式系統(tǒng)的復(fù)雜度高
（2）開發(fā)運(yùn)維成本高
（3）可能需要過多的操作
（4）需要提高DevOps應(yīng)用技巧
（5）對(duì)于故障診斷比較難，分布式部署跟蹤比單體架構(gòu)復(fù)雜
聯(lián)系客服
