首先，讓我們定義一下什么是“整體”和“微服務(wù)”。一個(gè)獨(dú)立的體系結(jié)構(gòu)是作為一個(gè)大型系統(tǒng)構(gòu)建的，通常是一個(gè)代碼庫(kù)。無(wú)論更改了什么，通常都會(huì)同時(shí)部署前端和末端代碼。然而，微服務(wù)架構(gòu)是將應(yīng)用程序構(gòu)建為一組小型服務(wù)，每個(gè)服務(wù)都有自己的代碼庫(kù)。這些服務(wù)是圍繞特定功能構(gòu)建的，通?？梢元?dú)立部署。

傳統(tǒng)的智慧從一塊巨石開(kāi)始說(shuō)教。當(dāng)一個(gè)精簡(jiǎn)的團(tuán)隊(duì)在緊迫的期限內(nèi)開(kāi)始工作時(shí)，這種誘惑尤其強(qiáng)烈。但傳統(tǒng)智慧總是正確的嗎?我的好朋友Darby Frey在擔(dān)任Gamut的高級(jí)平臺(tái)工程主管后，最近啟動(dòng)了一個(gè)新項(xiàng)目。盡管在他之前的公司里，他是用一塊巨石開(kāi)始的，但他發(fā)現(xiàn)(在適當(dāng)?shù)那闆r下)用一塊巨石開(kāi)始并不總是最好的方法。

在Belly, Darby和他的團(tuán)隊(duì)將他們的整體分解成一個(gè)相當(dāng)大的微服務(wù)架構(gòu)。他們?cè)O(shè)法把它弄到一個(gè)好地方，但只是在幾個(gè)月的試驗(yàn)和磨難后才遷移到微服務(wù)。有了這段新鮮的經(jīng)歷，他在Gamut的新項(xiàng)目中對(duì)微服務(wù)更加謹(jǐn)慎:

“我是‘鐵板一塊’團(tuán)隊(duì)的堅(jiān)定成員。(我想)讓我們建立一個(gè)單一的應(yīng)用程序，然后把事情分開(kāi)，如果我們開(kāi)始感到痛苦，”他說(shuō)。雖然這是一個(gè)新項(xiàng)目，但達(dá)比的團(tuán)隊(duì)規(guī)模較小，而且他有嚴(yán)格的時(shí)間表，所以從表面上看，一塊巨石似乎是顯而易見(jiàn)的選擇。“(但有了這個(gè)新項(xiàng)目)，我急于避免重復(fù)過(guò)去的錯(cuò)誤。”

有了這些，他發(fā)現(xiàn)自己面臨著一個(gè)我們都在掙扎的決定，我們應(yīng)該從一個(gè)整體還是一個(gè)微服務(wù)開(kāi)始，我們?nèi)绾螞Q定?

理解的選擇

要在兩者之間做出選擇，我們應(yīng)該首先確定“整體”和“微服務(wù)”的確切含義。

Particle公司的CTO Zachary Crockett告訴我:“系統(tǒng)架構(gòu)位于一個(gè)頻譜上……當(dāng)討論微服務(wù)時(shí)，人們往往關(guān)注這個(gè)頻譜的一端:許多微小的應(yīng)用程序相互傳遞太多的消息。在這個(gè)范圍的另一端，你有一個(gè)巨大的龐然大物在做太多的事情。對(duì)于任何實(shí)際的系統(tǒng)，在這兩個(gè)極端之間都有許多可能的面向服務(wù)的體系結(jié)構(gòu)。

定義龐然大物

單片應(yīng)用程序構(gòu)建為單個(gè)的、統(tǒng)一的單元。通常，一個(gè)整體由三部分組成:數(shù)據(jù)庫(kù)、客戶端用戶界面(由HTML頁(yè)面和/或在瀏覽器中運(yùn)行的JavaScript組成)和服務(wù)器端應(yīng)用程序。服務(wù)器端應(yīng)用程序?qū)⑻幚鞨TTP請(qǐng)求，執(zhí)行特定于域的邏輯，從數(shù)據(jù)庫(kù)檢索和更新數(shù)據(jù)，并填充要發(fā)送到瀏覽器的HTML視圖。

在一個(gè)整體中，服務(wù)器端應(yīng)用程序邏輯、前端客戶端邏輯、后臺(tái)作業(yè)等都定義在同一個(gè)龐大的代碼庫(kù)中。結(jié)果是:如果開(kāi)發(fā)人員希望進(jìn)行任何更改或更新，他們需要一次性構(gòu)建和部署整個(gè)堆棧。

與你所想的相反，巨石并不是一個(gè)過(guò)時(shí)的建筑，我們不需要把它留在過(guò)去。在某些情況下，一塊巨石是最理想的。工程主管史蒂文•Czerwinski Scaylr和谷歌前員工解釋說(shuō),因?yàn)樗膱F(tuán)隊(duì)在Scaylr很小,一個(gè)統(tǒng)一的應(yīng)用程序相比,更易于管理的一切分裂成microservices:“(在早期的Scaylr)盡管我們有這些積極的經(jīng)驗(yàn)使用microservices在谷歌,我們?nèi)?一塊)的路線,因?yàn)閾碛幸粋€(gè)龐大的服務(wù)器意味著更少的工作對(duì)我們兩個(gè)工程師。”

當(dāng)考慮一個(gè)整體架構(gòu)時(shí)，你的團(tuán)隊(duì)?wèi)?yīng)該考慮以下幾點(diǎn):

龐然大物優(yōu)點(diǎn)

較少的橫切關(guān)注點(diǎn):單片架構(gòu)的主要優(yōu)點(diǎn)是，大多數(shù)應(yīng)用程序通常都有大量的橫切關(guān)注點(diǎn)，比如日志記錄、速率限制和安全特性，比如審計(jì)跟蹤和DOS保護(hù)。當(dāng)所有東西都在同一個(gè)應(yīng)用程序中運(yùn)行時(shí)，很容易將組件連接到那些橫切關(guān)注點(diǎn)上。

更少的操作開(kāi)銷(xiāo):擁有一個(gè)[大型]應(yīng)用程序意味著只需要為一個(gè)應(yīng)用程序設(shè)置日志記錄、監(jiān)視和測(cè)試。它的部署通常也不那么復(fù)雜。

性能:也有性能優(yōu)勢(shì)，因?yàn)楣蚕韮?nèi)存訪問(wèn)比進(jìn)程間通信(IPC)更快。

龐然大物缺點(diǎn)

緊密耦合:隨著應(yīng)用程序的發(fā)展，單片應(yīng)用程序服務(wù)往往會(huì)變得緊密耦合和糾纏不清，這使得出于諸如獨(dú)立擴(kuò)展或代碼可維護(hù)性等目的而隔離服務(wù)變得非常困難。

更難理解:單片架構(gòu)也更難理解，因?yàn)楫?dāng)您查看特定的服務(wù)或控制器時(shí)，可能存在依賴性、副作用和不可思議的地方。

定義MICROSERVICES

微服務(wù)本身并沒(méi)有本質(zhì)上的“微”。雖然它們往往比一般的巨石要小，但它們并不一定要小。有些是，但是規(guī)模是相對(duì)的，而且在組織之間沒(méi)有衡量單位的標(biāo)準(zhǔn)。

微服務(wù)體系結(jié)構(gòu)風(fēng)格是一種將單個(gè)應(yīng)用程序作為一組小服務(wù)來(lái)開(kāi)發(fā)的方法，每個(gè)小服務(wù)都在自己的進(jìn)程中運(yùn)行，并與輕量級(jí)機(jī)制(通常是HTTP資源API)進(jìn)行通信。這些服務(wù)是圍繞業(yè)務(wù)功能構(gòu)建的，可以通過(guò)完全自動(dòng)化的部署機(jī)制獨(dú)立部署。對(duì)這些服務(wù)的集中管理很少。

在考慮微服務(wù)時(shí)，您的團(tuán)隊(duì)?wèi)?yīng)該牢記:

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

更好的組織:微服務(wù)體系結(jié)構(gòu)通常組織得更好，因?yàn)槊總€(gè)微服務(wù)都有一個(gè)非常具體的工作，不關(guān)心其他組件的工作。

解耦:解耦的服務(wù)也更容易重新組合和配置，以滿足不同應(yīng)用程序的需要(例如，同時(shí)服務(wù)于web客戶端和公共API)。它們還允許在更大的集成系統(tǒng)中快速、獨(dú)立地交付單個(gè)部件。

性能:在適當(dāng)?shù)那闆r下，微服務(wù)也可以具有性能優(yōu)勢(shì)，這取決于它們的組織方式，因?yàn)樗梢愿綦x熱門(mén)服務(wù)并獨(dú)立于應(yīng)用程序的其余部分進(jìn)行伸縮。

更少的錯(cuò)誤:微服務(wù)通過(guò)在系統(tǒng)的不同部分之間建立一個(gè)難以跨越的邊界來(lái)支持并行開(kāi)發(fā)。這樣做的話，你就很難——或者至少更難——去做錯(cuò)誤的事情:也就是說(shuō)，把不應(yīng)該連接的部分連接起來(lái)，把需要連接的部分連接得太緊。

Microservices缺點(diǎn)

跨每個(gè)服務(wù)的橫切關(guān)注點(diǎn):當(dāng)您構(gòu)建一個(gè)新的微服務(wù)體系結(jié)構(gòu)時(shí)，您可能會(huì)發(fā)現(xiàn)許多在設(shè)計(jì)時(shí)沒(méi)有預(yù)料到的橫切關(guān)注點(diǎn)。您將需要為每個(gè)橫切關(guān)注點(diǎn)(即測(cè)試)產(chǎn)生單獨(dú)模塊的開(kāi)銷(xiāo)，或者將橫切關(guān)注點(diǎn)封裝在所有流量都要經(jīng)過(guò)的另一個(gè)服務(wù)層中。最終，即使是單片架構(gòu)也傾向于通過(guò)外部服務(wù)層來(lái)為橫切關(guān)注點(diǎn)路由流量，但是使用單片架構(gòu)，可能會(huì)延遲工作的成本，直到項(xiàng)目更加成熟。

更高的操作開(kāi)銷(xiāo):微服務(wù)經(jīng)常部署在它們自己的虛擬機(jī)或容器上，導(dǎo)致VM爭(zhēng)用工作的激增。這些任務(wù)通常通過(guò)集裝箱船隊(duì)管理工具實(shí)現(xiàn)自動(dòng)化。

為您的組織做出正確的決定

當(dāng)您與您的團(tuán)隊(duì)坐下來(lái)討論時(shí)，優(yōu)缺點(diǎn)可以為討論一個(gè)架構(gòu)相對(duì)于另一個(gè)架構(gòu)的潛在優(yōu)點(diǎn)和缺點(diǎn)提供一個(gè)通用框架。為了有效地應(yīng)用這些一般原則，我采訪了幾十位cto，為您在決定什么對(duì)您的組織最有利時(shí)創(chuàng)建了一個(gè)考慮事項(xiàng)的規(guī)則。

你在熟悉的領(lǐng)域嗎?

Darby和他在Gamut的團(tuán)隊(duì)能夠直接研究微服務(wù)，因?yàn)樗须娮由虅?wù)平臺(tái)的經(jīng)驗(yàn)，而他的公司對(duì)于客戶的需求有著豐富的知識(shí)。另一方面，如果他走的是一條未知的道路，那么一塊巨石可能是更安全的選擇。

你的團(tuán)隊(duì)準(zhǔn)備好了嗎?

你的團(tuán)隊(duì)有微服務(wù)的經(jīng)驗(yàn)嗎?如果你在明年將團(tuán)隊(duì)規(guī)模擴(kuò)大四倍，微服務(wù)是否適合這種情況?評(píng)估團(tuán)隊(duì)的這些方面對(duì)于項(xiàng)目的成功至關(guān)重要。

如果您的團(tuán)隊(duì)準(zhǔn)備好了，那么從微服務(wù)開(kāi)始是明智的，因?yàn)樗试S您從一開(kāi)始就適應(yīng)在微服務(wù)環(huán)境中開(kāi)發(fā)的節(jié)奏。

你的基礎(chǔ)設(shè)施如何?

實(shí)際上，您將需要基于云的基礎(chǔ)設(shè)施來(lái)讓微服務(wù)為您的項(xiàng)目工作。

“(以前)，您希望從一個(gè)整體開(kāi)始，因?yàn)槟Ｍ渴鹨粋€(gè)數(shù)據(jù)庫(kù)服務(wù)器。必須為每個(gè)微服務(wù)設(shè)置一個(gè)數(shù)據(jù)庫(kù)服務(wù)器，然后向外擴(kuò)展，這是一項(xiàng)艱巨的任務(wù)。只有一個(gè)龐大的、精通技術(shù)的組織才能做到這一點(diǎn)。“而今天有了像谷歌云和亞馬遜AWS這樣的服務(wù)，你可以有很多選擇來(lái)部署微小的東西，而不需要為每個(gè)東西擁有持久層。”

評(píng)估業(yè)務(wù)風(fēng)險(xiǎn)

你可能認(rèn)為微服務(wù)是作為一家充滿雄心壯志的科技創(chuàng)業(yè)公司的“正確”道路。但微服務(wù)也帶來(lái)了商業(yè)風(fēng)險(xiǎn)。大衛(wèi)·施特勞斯解釋道:

“許多團(tuán)隊(duì)一開(kāi)始就過(guò)度構(gòu)建了他們的項(xiàng)目;每個(gè)人都希望自己的初創(chuàng)公司能成為下一個(gè)獨(dú)角獸，因此，他們應(yīng)該用微服務(wù)或其他一些高度可伸縮的基礎(chǔ)設(shè)施來(lái)構(gòu)建一切。但這通常是錯(cuò)誤的，幾乎一直都是。

他接著說(shuō)，在這些情況下，你認(rèn)為你需要擴(kuò)展的領(lǐng)域可能不是首先需要擴(kuò)展的部分，這導(dǎo)致了錯(cuò)誤的努力，即使是需要擴(kuò)展的系統(tǒng)。

環(huán)境很重要

與我交談的cto具有廣泛的單體和微服務(wù)經(jīng)驗(yàn)。一些人滿懷信心地從微服務(wù)起步，而另一些人則在一開(kāi)始就固守不變，最終隨著初創(chuàng)企業(yè)的成長(zhǎng)，他們轉(zhuǎn)向了微服務(wù)?？紤]您自己的上下文和以下場(chǎng)景，以幫助確定哪種體系結(jié)構(gòu)適合您的情況。

什么時(shí)候從一塊巨石開(kāi)始

這里有一些場(chǎng)景，表明你應(yīng)該開(kāi)始你的下一個(gè)項(xiàng)目使用單片架構(gòu):

您的團(tuán)隊(duì)正處于創(chuàng)建階段:您的團(tuán)隊(duì)很小，只有2-5名成員，因此無(wú)法處理更廣泛、開(kāi)銷(xiāo)更大的微服務(wù)體系結(jié)構(gòu)。

您正在構(gòu)建一個(gè)未經(jīng)驗(yàn)證的產(chǎn)品或概念證明:您正在構(gòu)建一個(gè)市場(chǎng)上未經(jīng)驗(yàn)證的產(chǎn)品嗎?如果它是一個(gè)新想法，它可能會(huì)隨著時(shí)間的推移而改變和進(jìn)化，因此一個(gè)整體是允許快速產(chǎn)品迭代的理想選擇。這同樣適用于概念證明，你的目標(biāo)就是盡可能多、盡可能快地學(xué)習(xí)，即使你最終把它扔掉。

您沒(méi)有微服務(wù)經(jīng)驗(yàn):如果您的團(tuán)隊(duì)之前沒(méi)有微服務(wù)經(jīng)驗(yàn)，除非您能夠證明在這么早的階段就冒著“在飛行中”學(xué)習(xí)的風(fēng)險(xiǎn)是合理的，否則這可能是另一個(gè)您應(yīng)該堅(jiān)持一個(gè)整體開(kāi)始的跡象。

何時(shí)開(kāi)始使用微服務(wù)

以下是一些場(chǎng)景，表明您應(yīng)該使用微服務(wù)啟動(dòng)下一個(gè)項(xiàng)目:

您需要快速、獨(dú)立的服務(wù)交付:微服務(wù)允許在更大的集成系統(tǒng)中快速、獨(dú)立地交付單個(gè)部件。注意，根據(jù)您的團(tuán)隊(duì)規(guī)模，可能需要一段時(shí)間才能看到服務(wù)交付的收益，而不是從整體開(kāi)始。

平臺(tái)的一部分需要非常高效:如果您的業(yè)務(wù)正在進(jìn)行pb級(jí)的日志量的密集處理，那么您可能希望用一種非常高效的語(yǔ)言(即c++)構(gòu)建服務(wù)，而您的用戶儀表板可能是用Ruby on Rails構(gòu)建的。

您計(jì)劃擴(kuò)展您的團(tuán)隊(duì):從microservices開(kāi)始，可以使您的團(tuán)隊(duì)習(xí)慣于從一開(kāi)始就在獨(dú)立的小型服務(wù)中進(jìn)行開(kāi)發(fā)，并且通過(guò)服務(wù)邊界將團(tuán)隊(duì)分隔開(kāi)，可以在需要時(shí)更容易地?cái)U(kuò)展您的團(tuán)隊(duì)，而無(wú)需引入指數(shù)級(jí)復(fù)雜性。

整體并沒(méi)有消亡，微服務(wù)也不是最適合于每一種環(huán)境。避免僅僅因?yàn)槲⒎?wù)的爆炸式增長(zhǎng)就一頭扎進(jìn)它的誘惑。相反，請(qǐng)使用之前的cto的智慧來(lái)仔細(xì)考慮什么架構(gòu)對(duì)您最有意義。