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

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

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

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

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

理解的選擇

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

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

定義龐然大物

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

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

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

當(dāng)考慮一個整體架構(gòu)時，你的團隊?wèi)?yīng)該考慮以下幾點:

龐然大物優(yōu)點

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

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

性能:也有性能優(yōu)勢，因為共享內(nèi)存訪問比進程間通信(IPC)更快。

龐然大物缺點

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

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

定義MICROSERVICES

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

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

在考慮微服務(wù)時，您的團隊?wèi)?yīng)該牢記:

Microservices優(yōu)點

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

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

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

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

Microservices缺點

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

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

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

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

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

Darby和他在Gamut的團隊能夠直接研究微服務(wù)，因為他有電子商務(wù)平臺的經(jīng)驗，而他的公司對于客戶的需求有著豐富的知識。另一方面，如果他走的是一條未知的道路，那么一塊巨石可能是更安全的選擇。

你的團隊準(zhǔn)備好了嗎?

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

如果您的團隊準(zhǔn)備好了，那么從微服務(wù)開始是明智的，因為它允許您從一開始就適應(yīng)在微服務(wù)環(huán)境中開發(fā)的節(jié)奏。

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

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

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

評估業(yè)務(wù)風(fēng)險

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

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

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

環(huán)境很重要

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

什么時候從一塊巨石開始

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

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

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

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

何時開始使用微服務(wù)

以下是一些場景，表明您應(yīng)該使用微服務(wù)啟動下一個項目:

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

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

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

整體并沒有消亡，微服務(wù)也不是最適合于每一種環(huán)境。避免僅僅因為微服務(wù)的爆炸式增長就一頭扎進它的誘惑。相反，請使用之前的cto的智慧來仔細考慮什么架構(gòu)對您最有意義。