微服務(wù)是什么

過去幾年來，“微服務(wù)架構(gòu)”這個術(shù)語出現(xiàn)了，它描述了一種將軟件應(yīng)用程序設(shè)計為可獨(dú)立部署的服務(wù)套件的特定方式。盡管這種架構(gòu)風(fēng)格沒有確切的定義，但圍繞業(yè)務(wù)能力，自動化部署，端點(diǎn)智能以及語言和數(shù)據(jù)的分散控制等方面存在著某些共同特征。

“微服務(wù)” - 在軟件架構(gòu)擁擠的街道上又一個新名詞。盡管我們的自然傾向是以輕蔑的眼光來傳遞這樣的東西，但這些術(shù)語描述了一種我們發(fā)現(xiàn)越來越吸引人的軟件系統(tǒng)風(fēng)格。我們已經(jīng)看到許多項(xiàng)目在過去幾年中都采用了這種風(fēng)格，迄今為止的結(jié)果是積極的，因此對于我們的許多同事來說，這正成為構(gòu)建企業(yè)應(yīng)用程序的默認(rèn)風(fēng)格。可悲的是，沒有太多的信息概述了微服務(wù)的風(fēng)格以及如何去做。

簡而言之，微服務(wù)架構(gòu)是一種將單應(yīng)用程序作為一套小型服務(wù)開發(fā)的方法，每種應(yīng)用程序都在其自己的進(jìn)程中運(yùn)行，并與輕量級機(jī)制（通常是HTTP資源的API）進(jìn)行通信。這些服務(wù)是圍繞業(yè)務(wù)功能構(gòu)建的，可以通過全自動部署機(jī)制進(jìn)行獨(dú)立部署。這些服務(wù)的集中化管理已經(jīng)是最少的，它們可以用不同的編程語言編寫，并使用不同的數(shù)據(jù)存儲技術(shù)。

在開始介紹微服務(wù)風(fēng)格（microservice style）前，比較一下整體風(fēng)格（monolithic style）是很有幫助的：一個完整應(yīng)用程序（monolithic application）構(gòu)建成一個單獨(dú)的單元。企業(yè)應(yīng)用程序通常建立在三個主要部分中：一個客戶端用戶界面（由用戶計算機(jī)上的瀏覽器中運(yùn)行的HTML頁面和JavaScript組成）數(shù)據(jù)庫（包括插入常見的通常是關(guān)系數(shù)據(jù)庫管理的多個表系統(tǒng)）和一個服務(wù)器端應(yīng)用程序。服務(wù)器端應(yīng)用程序?qū)⑻幚鞨TTP請求，執(zhí)行特定領(lǐng)域邏輯，通過數(shù)據(jù)庫進(jìn)行檢索和更新數(shù)據(jù)，選擇并填充要發(fā)送到瀏覽器的HTML視圖。這個服務(wù)器端應(yīng)用程序是一個龐然大物 - 一個邏輯可執(zhí)行文件。系統(tǒng)的任何更改都涉及構(gòu)建和部署新版本的服務(wù)器端應(yīng)用程序。

這樣的整體服務(wù)（monolithic server）是一種構(gòu)建系統(tǒng)很自然的方式。處理請求的所有邏輯都在一個進(jìn)程中運(yùn)行，允許您使用語言的基本功能將應(yīng)用程序劃分為類，函數(shù)和名稱空間。謹(jǐn)慎操作時，您可以在開發(fā)人員的筆記本電腦上運(yùn)行和測試應(yīng)用程序，并使用部署通道來確保更改經(jīng)過適當(dāng)測試并部署到生產(chǎn)環(huán)境中。您可以通過在負(fù)載平衡器后面運(yùn)行多個實(shí)例來橫向縮放整體。

單體式應(yīng)用程序可以取得成功，但越來越多的人會感到失望 - 尤其是隨著更多應(yīng)用程序被部署到云中。變更周期是連在一起的 - 對應(yīng)用程序的一小部分進(jìn)行更改，需要重建和部署整個程序。隨著時間的推移，它通常很難保持良好的模塊化結(jié)構(gòu)，使得難以保持應(yīng)該：模塊內(nèi)的一個改動僅影響該模塊本身中。自適應(yīng)需要自適應(yīng)整個應(yīng)用程序，而不是它的一部分，這樣做需要更多資源。

這些挫折引出了微服務(wù)架構(gòu)風(fēng)格：將應(yīng)用程序構(gòu)建為服務(wù)套件。除了服務(wù)是可獨(dú)立部署和可伸縮的事實(shí)之外，每個服務(wù)還提供了一個嚴(yán)格的模塊邊界，甚至允許用不同的編程語言編寫不同的服務(wù)。它們也可以由不同的團(tuán)隊(duì)來管理。

我們并不是說微服務(wù)風(fēng)格是新穎的或創(chuàng)新的，它的根源至少可以追溯到Unix的設(shè)計原則。但我們確實(shí)認(rèn)為，沒有足夠多的人考慮使用微服務(wù)架構(gòu)，如果他們使用了，那么許多軟件開發(fā)將會更好。

微服務(wù)體系結(jié)構(gòu)的特征

通過服務(wù)（Sevice）實(shí)現(xiàn)組件化

只要我們參與過軟件行業(yè)，這就存在一種期盼：通過將組件整合在一起來構(gòu)建系統(tǒng)，這與我們在現(xiàn)實(shí)世界中看待事物的方式非常相似。在過去的幾十年中，我們已經(jīng)見證了大部分語言平臺中常見庫的大量摘要所取得的巨大進(jìn)步。在談及組件時，我們遇到了對組件構(gòu)成定義的難題。我們的定義是，組件是可獨(dú)立更換和升級的軟件單元。

微服務(wù)架構(gòu)一樣會用到各種庫，但這種架構(gòu)會把軟件給拆分成各種不同的服務(wù)來實(shí)現(xiàn)組件化。這里我們定義兩個重要的概念：庫(library) 指的是鏈接到程序的組件，通過本地函數(shù)調(diào)用來使用庫提供的功能；而服務(wù) (service) 是進(jìn)程外的組件，通過網(wǎng)絡(luò)服務(wù)請求 (web service request) 或者遠(yuǎn)程函數(shù)調(diào)用之類的機(jī)制來使用里面的功能。注意這和很多面向?qū)ο蟪绦蚶锓?wù)對象的機(jī)制是不同的 。

之所以在組件化的軟件里用服務(wù)，而不是庫，一個主要原因就是各個服務(wù)是可以獨(dú)立部署的。比如說，如果在同一個軟件里用了多個庫，那么就算只是修改了其中一個，都會導(dǎo)致整個軟件要被重新部署；相反，如果用的是服務(wù)，那只需要重新部署修改過的就可以。然而，有個問題是，當(dāng)修改服務(wù)時，可能會把服務(wù)接口也給修改了，這樣一來，服務(wù)的調(diào)用者和開發(fā)者就得自己私下協(xié)調(diào)了。好的微服務(wù)架構(gòu)，就應(yīng)該盡量避免這種問題；非要修改服務(wù)契約的話，也得循序漸進(jìn)，讓調(diào)用者有跡可循，不用私下協(xié)調(diào)。

使用服務(wù)作為組件的另一個后果是更顯式的組件接口。大多數(shù)語言都沒有很好的機(jī)制來定義顯式發(fā)布的接口。通常，只有文檔和規(guī)程可以防止客戶機(jī)破壞組件的封裝，從而導(dǎo)致組件之間的緊密耦合。通過使用顯式的遠(yuǎn)程調(diào)用機(jī)制，服務(wù)可以更容易地避免這種情況。使用這樣的服務(wù)確實(shí)有缺點(diǎn)。遠(yuǎn)程調(diào)用比進(jìn)程內(nèi)調(diào)用更昂貴，因此遠(yuǎn)程api需要粗粒度，這通常更難以使用。如果您需要更改組件之間的職責(zé)分配，那么當(dāng)您跨越流程邊界時，這種行為的移動就更加困難了。

我們可以觀察到服務(wù)映射到運(yùn)行時進(jìn)程，但這只是第一次近似。服務(wù)可能包括多個進(jìn)程，這些進(jìn)程將始終會一起開發(fā)和部署，例如應(yīng)用進(jìn)程和服務(wù)所用到的數(shù)據(jù)庫。

根據(jù)服務(wù)能力進(jìn)行管理

當(dāng)將大型應(yīng)用程序拆分為不同組件時，通常的管理側(cè)重于技術(shù)層，由技術(shù)層引領(lǐng)UI團(tuán)隊(duì)、服務(wù)器端邏輯團(tuán)隊(duì)和數(shù)據(jù)庫團(tuán)隊(duì)的工作。當(dāng)團(tuán)隊(duì)的這種生產(chǎn)線被隔離時，即使是簡單的改變也會引起跨團(tuán)隊(duì)的項(xiàng)目耗時耗力。聰明的團(tuán)隊(duì)將圍繞這一點(diǎn)進(jìn)行優(yōu)化——僅把邏輯強(qiáng)加到他們所能觸及的任何方式中。換句話說，邏輯無處不在。這是Conway定律的一個例子。

任何如設(shè)計系統(tǒng)（廣義定義）的組織，必將創(chuàng)造出一個設(shè)計，其設(shè)計結(jié)構(gòu)是組織的通信結(jié)構(gòu)的副本。

在劃分層面，微服務(wù)方法是不同的，分解成圍繞業(yè)務(wù)能力所組織的服務(wù)。這些服務(wù)需要對該業(yè)務(wù)領(lǐng)域的軟件進(jìn)行廣泛的實(shí)施，包括用戶界面、持久性存儲和任何外部協(xié)作。因此，團(tuán)隊(duì)是跨職能的，包括開發(fā)所需的全部技能：用戶體驗(yàn)、數(shù)據(jù)庫和項(xiàng)目管理。

任務(wù)調(diào)度 微服務(wù)

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。