介紹

剛開始時，由于要求簡單，所以應(yīng)用程序既簡單又小。 隨著時間要求和需求的增長，我們的應(yīng)用程序變得越來越大，越來越復(fù)雜。 這導(dǎo)致將單片服務(wù)器開發(fā)和部署為一個單元。 在某種程度上，微服務(wù)可以通過簡單的應(yīng)用程序回歸基礎(chǔ)，這些應(yīng)用程序可以通過利用彼此之間的API一起工作來滿足當(dāng)今對復(fù)雜性的需求。

什么是整體服務(wù)器？

與微服務(wù)相比，微服務(wù)最好被解釋。 整體服務(wù)器 。 它們作為一個單元開發(fā)和部署 。 對于Java，最終結(jié)果通常是單個WAR或JAR文件。 C ++ 、. Net，Scala和許多其他編程語言也是如此。

大多數(shù)軟件開發(fā)的短暫歷史都以我們開發(fā)的應(yīng)用程序規(guī)模的不斷增加為標(biāo)志。 隨著時間的流逝，我們將越來越多地添加到我們的應(yīng)用程序中，從而不斷增加它們的復(fù)雜性和大小，并降低我們的開發(fā)，測試和部署速度 。

隨著時間的流逝，我們開始將應(yīng)用程序劃分為多個層：表示層，業(yè)務(wù)層，數(shù)據(jù)訪問層等。這種分離比物理上更邏輯。 盡管開發(fā)變得容易一些，但每次更改或發(fā)布時，我們?nèi)匀恍枰獪y試和部署所有內(nèi)容。 在企業(yè)環(huán)境中，擁有花費(fèi)數(shù)小時才能構(gòu)建和部署的應(yīng)用程序并不少見。 測試，尤其是回歸測試，往往是一場噩夢，在某些情況下會持續(xù)數(shù)月之久。 隨著時間的流逝，我們進(jìn)行僅影響一個模塊的更改的能力正在下降。 分層的主要目的是使它們易于替換或升級。 這個承諾從未真正實(shí)現(xiàn)。 在大型整體應(yīng)用中更換零件幾乎從來都不容易，而且沒有風(fēng)險。

擴(kuò)展此類服務(wù)器意味著擴(kuò)展整個應(yīng)用程序，從而產(chǎn)生非常不平衡的資源利用。 如果我們需要更多的資源，即使瓶頸是一個模塊，我們也被迫在新服務(wù)器上復(fù)制所有內(nèi)容。

什么是微服務(wù)？

微服務(wù)是一種架構(gòu)和開發(fā)由小服務(wù)組成的單個應(yīng)用程序的方法。 了解微服務(wù)的關(guān)鍵是它們的獨(dú)立性 。 彼此分別開發(fā)，測試和部署。 每個服務(wù)作為單獨(dú)的進(jìn)程運(yùn)行。 不同微服務(wù)之間的唯一關(guān)系是通過它們公開的API來完成數(shù)據(jù)交換。 它們以某種方式繼承了Unix / Linux中使用的小型程序和管道的思想。 大多數(shù)Linux程序很小，并且會產(chǎn)生一些輸出。 該輸出可以作為輸入傳遞給其他程序。 鏈接在一起時，這些程序可以執(zhí)行非常復(fù)雜的操作。 它是由許多簡單單元組合而成的復(fù)雜性。

微服務(wù)的關(guān)鍵方面是：

• 他們做一件事或負(fù)責(zé)一項(xiàng)功能。
• 每個微服務(wù)都可以通過任何一組工具或語言來構(gòu)建，因?yàn)樗鼈儽舜霜?dú)立。
• 由于每個微服務(wù)在物理上是彼此分離的，因此它們實(shí)際上是松散耦合的。
• 開發(fā)不同的微服務(wù)的不同團(tuán)隊之間的相對獨(dú)立性（假設(shè)它們公開的API是預(yù)先定義的）。
• 簡化測試以及持續(xù)交付或部署

微服務(wù)的問題之一是決定何時使用它們。 最初，盡管應(yīng)用程序仍然很小，但是微服務(wù)試圖解決的問題并不存在。 但是，一旦應(yīng)用程序增長并且可以提出微服務(wù)的理由，切換到另一種體系結(jié)構(gòu)樣式的成本可能會太大。 經(jīng)驗(yàn)豐富的團(tuán)隊可能從一開始就使用微服務(wù)，因?yàn)樗麄冎浪麄円院罂赡苄枰獌斶€的技術(shù)債務(wù)比起一開始使用微服務(wù)要昂貴得多。 通常，就像Netflix，eBay和Amazon一樣，整體式應(yīng)用程序開始逐漸向微服務(wù)發(fā)展。 新模塊被開發(fā)為微服務(wù)，并與系統(tǒng)的其余部分集成。 一旦證明了自己的價值，現(xiàn)有的整體應(yīng)用程序的一部分就會重構(gòu)為微服務(wù)。

企業(yè)應(yīng)用程序開發(fā)人員經(jīng)常引起批評的一件事是數(shù)據(jù)存儲的分散化。 盡管微服務(wù)可以使用集中式數(shù)據(jù)存儲來工作（只需進(jìn)行少量調(diào)整），但至少應(yīng)該探索使該部分分散的選項(xiàng)。 將與某些服務(wù)相關(guān)的數(shù)據(jù)存儲在單獨(dú)的（分散式）存儲中并將其全部打包到同一容器中的選擇在許多情況下比將數(shù)據(jù)存儲在集中式數(shù)據(jù)庫中更好。 我們不建議始終使用分散存儲，而在設(shè)計微服務(wù)時考慮使用該選項(xiàng)。

缺點(diǎn)

運(yùn)營和部署復(fù)雜性增加

反對微服務(wù)的主要論點(diǎn)是操作和部署復(fù)雜性的增加。 這種說法是正確的，但是由于有了相對較新的工具，它可以緩解。 配置管理（CM）工具可以相對輕松地處理環(huán)境設(shè)置和部署。 Docker對容器的利用大大減少了微服務(wù)可能引起的部署麻煩。 CM工具與Docker一起使我們能夠輕松部署和擴(kuò)展微服務(wù)。 可以在文章連續(xù)部署：使用Ansible和Docker實(shí)施中找到一個示例。

在我看來，增加部署復(fù)雜性的爭論通常沒有考慮到我們在過去幾年中看到的進(jìn)步，并且被夸大了。 這并不意味著一部分工作不會從開發(fā)轉(zhuǎn)移到DevOps 。 肯定是。 但是，在許多情況下，收益要大于轉(zhuǎn)移帶來的不便。

遠(yuǎn)程過程調(diào)用

另一個反論點(diǎn)是遠(yuǎn)程進(jìn)程調(diào)用會降低性能。 通過類和方法進(jìn)行內(nèi)部調(diào)用更快，并且無法解決此問題。 性能損失對系統(tǒng)的影響取決于具體情況。 重要的因素是我們?nèi)绾尾鸱窒到y(tǒng)。 如果我們將非常小的微服務(wù)（如果有人建議它們的LOC不應(yīng)超過10-100 LOC）達(dá)到極限，那么這種影響可能是相當(dāng)大的。 我喜歡創(chuàng)建圍繞用戶，購物車，產(chǎn)品等功能組織的微服務(wù)。這減少了遠(yuǎn)程流程調(diào)用的數(shù)量。 另外，必須注意的是，如果從一個微服務(wù)到另一微服務(wù)的呼叫正在通過快速內(nèi)部LAN進(jìn)行，則負(fù)面影響相對較小。

優(yōu)點(diǎn)

以下僅是微服務(wù)可以帶來的一些優(yōu)勢。 這并不意味著在其他類型的體系結(jié)構(gòu)中不存在相同的優(yōu)勢，而是與微服務(wù)相比，與其他一些選擇相比，它們可能會更加突出。

縮放比例

擴(kuò)展微服務(wù)比單片應(yīng)用程序容易得多。 在后一種情況下，我們將整個應(yīng)用程序復(fù)制到一臺新機(jī)器上，而在微服務(wù)中，我們僅復(fù)制那些需要擴(kuò)展的服務(wù) 。 我們不僅可以擴(kuò)展需要擴(kuò)展的內(nèi)容，而且可以更好地分發(fā)內(nèi)容。 例如，我們可以將一個CPU利用率很高的服務(wù)與另一個使用大量RAM的服務(wù)放在一起，同時將第二個CPU需求服務(wù)移至其他硬件。

革新

一旦建立了初始架構(gòu)，單片服務(wù)器就不會留出太多的創(chuàng)新空間。 由于其性質(zhì)，更改事物會花費(fèi)時間，并且實(shí)驗(yàn)非常冒險，因?yàn)樗赡苡绊懰惺挛铩?例如，不能僅僅因?yàn)樗m合一個特定的模塊就更改Apache Tomcat for NodeJS。

我并不是建議我們應(yīng)該為每個模塊更改編程語言，服務(wù)器，持久性等。 但是，單片服務(wù)器趨向于相反的極端，在這種極端情況下，即使不是不受歡迎的更改也會帶來風(fēng)險。 借助微服務(wù)，我們可以分別為每個服務(wù)選擇我們認(rèn)為最佳的解決方案 。 一個可能使用Apache Tomcat，而另一個可能使用NodeJS。 一個可以用Java編寫，另一個可以用Scala編寫。 我并不是在提倡每種服務(wù)都與其他服務(wù)有所不同，但是可以以我們認(rèn)為最適合當(dāng)前目標(biāo)的方式來進(jìn)行每種服務(wù)。 最重要的是，更改和實(shí)驗(yàn)要容易得多。 畢竟，只要尊重API，我們所做的一切只會影響眾多微服務(wù)中的一個，而不會影響整個系統(tǒng)。

尺寸

由于微服務(wù)很小，因此更容易理解。 查看一個微服務(wù)正在做什么的代碼要少得多。 這本身就極大地簡化了開發(fā)，尤其是當(dāng)新來者加入該項(xiàng)目時。 最重要的是，其他所有東西都趨向于更快。 與整體應(yīng)用程序中使用的大型項(xiàng)目相比， IDE在小型項(xiàng)目中的運(yùn)行速度更快 。 由于沒有大型服務(wù)器或大量庫需要加載，因此啟動速度更快 。

部署，回滾和故障隔離

部署更快，更容易 。 部署小部件總是比部署大部件更快（如果不是更容易的話）。 如果我們意識到存在問題，則該問題的影響可能有限，并且可以更輕松地回滾 。 在回滾之前， 故障只隔離到系統(tǒng)的一小部分。 連續(xù)交付或部署可以用大型服務(wù)器無法實(shí)現(xiàn)的速度和頻率來完成。

無需長期承諾

整體應(yīng)用程序的常見問題之一是承諾。 我們經(jīng)常被迫從一開始就選擇會持續(xù)很長時間的體系結(jié)構(gòu)和技術(shù)。 畢竟，我們正在構(gòu)建一些可以持續(xù)很長時間的大型項(xiàng)目。 對于微服務(wù)， 需要長期承諾的需求并不大 。 在一種微服務(wù)中更改編程語言，如果發(fā)現(xiàn)它是一個不錯的選擇，則將其應(yīng)用于其他微服務(wù)。 如果實(shí)驗(yàn)失敗或不是最佳方案，則僅需要重做系統(tǒng)的一小部分。 同樣適用于框架，庫，服務(wù)器等。我們甚至可以使用不同的數(shù)據(jù)庫。 如果某些輕量級NoSQL似乎最適合特定的微服務(wù)，為什么不使用它并將其打包在容器中？

最佳實(shí)踐

以下大多數(shù)最佳實(shí)踐通常都可以應(yīng)用于面向服務(wù)的體系結(jié)構(gòu)。 但是，借助微服務(wù)，它們變得更加重要或有益。

貨柜

處理許多微服務(wù)很容易成為一項(xiàng)非常復(fù)雜的工作。 每種都可以用不同的編程語言編寫，可以需要不同的服務(wù)器（希望是輕量級的）或可以使用不同的庫集。 如果將每個服務(wù)打包為一個容器，那么大多數(shù)問題將消失。 我們要做的就是使用例如Docker運(yùn)行容器，并相信所需的一切都在其中。

代理微服務(wù)或API網(wǎng)關(guān)

大型企業(yè)前端可能需要調(diào)用數(shù)十甚至數(shù)百個HTTP請求（與Amazon.com一樣 ）。 與接收響應(yīng)數(shù)據(jù)相比，調(diào)用請求通常花費(fèi)更多時間。 在這種情況下，代理微服務(wù)可能會有所幫助。 他們的目標(biāo)是調(diào)用不同的微服務(wù)并返回聚合的服務(wù)。 它們不應(yīng)包含任何邏輯，而只是將多個響應(yīng)組合在一起，并以匯總數(shù)據(jù)響應(yīng)給消費(fèi)者。

反向代理

切勿直接公開微服務(wù)API。 如果沒有某種類型的編排，則消費(fèi)者與微服務(wù)之間的依賴關(guān)系變得如此之大，以至于它可能會消除自由，而微服務(wù)應(yīng)該給我們帶來自由。 諸如nginx和Apache Tomcat之類的輕量級服務(wù)器非常擅長執(zhí)行反向代理任務(wù)，并且可以輕松地以很少的開銷使用。 請查閱《 持續(xù)部署：實(shí)施 》一文，以了解將反向代理與Docker和其他一些工具結(jié)合使用的一種可能方式。

極簡主義方法

微服務(wù)應(yīng)僅包含它們真正需要的包，庫和框架。 它們越小越好。 這與單片應(yīng)用程序使用的方法形成了鮮明對比。 以前我們可能曾經(jīng)使用過像JBoss這樣的JEE服務(wù)器，它包裝了我們可能需要或可能不需要的所有工具，而微服務(wù)則可以與更簡單的解決方案一起工作。 擁有數(shù)百個微服務(wù)，每個微服務(wù)都具有完整的JBoss服務(wù)器，這會顯得過時了。 例如， Apache Tomcat是一個更好的選擇。 我傾向于使用更小的解決方案，例如，將Spray作為一種非常輕量級的RESTful API服務(wù)器。 不要打包您不需要的東西。

同樣的方法也應(yīng)應(yīng)用于操作系統(tǒng)級別。 如果我們將微服務(wù)部署為Docker容器，那么CoreOS可能是比Red Hat或Ubuntu更好的解決方案。 它擺脫了我們不需要讓我們更好地利用資源的事情。

必須進(jìn)行配置管理

隨著微服務(wù)數(shù)量的增長，對配置管理（CM）的需求也在增加。 不用工具如Puppet ， Chef或Ansible （僅舉幾例）部署許多微服務(wù)很快就成為噩夢。 實(shí)際上，無論有沒有微服務(wù)，對于最簡單的解決方案不使用CM工具都是一種浪費(fèi)。

跨職能團(tuán)隊

雖然沒有規(guī)定使用哪種類型的團(tuán)隊的規(guī)則，但是當(dāng)一個團(tuán)隊中的團(tuán)隊是多功能的時，微服務(wù)才是最好的選擇。 從開始（設(shè)計）到完成（部署和維護(hù)），應(yīng)由一個團(tuán)隊負(fù)責(zé)。 它們太小，無法從一個團(tuán)隊轉(zhuǎn)移到另一個團(tuán)隊（架構(gòu)/設(shè)計，開發(fā)，測試，部署和維護(hù)團(tuán)隊）。 最好有一個負(fù)責(zé)微服務(wù)整個生命周期的團(tuán)隊。 在許多情況下，一個團(tuán)隊可能負(fù)責(zé)多個微服務(wù)，但多個團(tuán)隊不應(yīng)該一個。

API版本控制

版本控制應(yīng)該應(yīng)用于任何API，微服務(wù)也是如此。 如果某些更改會使API格式失效，則該更改應(yīng)作為單獨(dú)的版本發(fā)布。 對于公共API或微服務(wù)，我們無法確定誰在使用它們，因此必須保持向后兼容性，或者至少要給消費(fèi)者足夠的時間來適應(yīng)。 REST API with JSON文章中發(fā)布了有關(guān)API版本控制的部分。

摘要

微服務(wù)并不能解決我們所有的問題。 沒有什么是。 它們不是所有應(yīng)用程序都應(yīng)創(chuàng)建的方式。 沒有適合所有情況的單一解決方案。

微服務(wù)已經(jīng)存在了很長時間，近年來，它們的普及程度也在不斷提高。 導(dǎo)致這種趨勢的因素很多，可伸縮性可能是最重要的一種。 新工具（尤其是Docker）的出現(xiàn)使我們能夠從新的角度看待微服務(wù)，并消除了其開發(fā)和部署所造成的部分問題。 諸如Amazon，NetFlix，eBay等“大佬”對微服務(wù)的利用，提供了足夠的信心，即企業(yè)應(yīng)用程序開發(fā)人員已經(jīng)可以評估（如果不使用）這種體系結(jié)構(gòu)樣式。

翻譯自: https://www.javacodegeeks.com/2015/01/monolithic-servers-vs-microservices.html

總結(jié)

以上是生活随笔為你收集整理的整体服务器与微服务的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。