首先，讓我們定義一下什么是“整體”和“微服務”。一個獨立的體系結構是作為一個大型系統(tǒng)構建的，通常是一個代碼庫。無論更改了什么，通常都會同時部署前端和末端代碼。然而，微服務架構是將應用程序構建為一組小型服務，每個服務都有自己的代碼庫。這些服務是圍繞特定功能構建的，通常可以獨立部署。
傳統(tǒng)的智慧從一塊巨石開始說教。當一個精簡的團隊在緊迫的期限內開始工作時，這種誘惑尤其強烈。但傳統(tǒng)智慧總是正確的嗎?我的好朋友Darby Frey在擔任Gamut的高級平臺工程主管后，最近啟動了一個新項目。盡管在他之前的公司里，他是用一塊巨石開始的，但他發(fā)現(xiàn)(在適當的情況下)用一塊巨石開始并不總是最好的方法。
在Belly, Darby和他的團隊將他們的整體分解成一個相當大的微服務架構。他們設法把它弄到一個好地方，但只是在幾個月的試驗和磨難后才遷移到微服務。有了這段新鮮的經歷，他在Gamut的新項目中對微服務更加謹慎:
“我是‘鐵板一塊’團隊的堅定成員。(我想)讓我們建立一個單一的應用程序，然后把事情分開，如果我們開始感到痛苦，”他說。雖然這是一個新項目，但達比的團隊規(guī)模較小，而且他有嚴格的時間表，所以從表面上看，一塊巨石似乎是顯而易見的選擇。“(但有了這個新項目)，我急于避免重復過去的錯誤。”
有了這些，他發(fā)現(xiàn)自己面臨著一個我們都在掙扎的決定，我們應該從一個整體還是一個微服務開始，我們如何決定?
理解的選擇
要在兩者之間做出選擇，我們應該首先確定“整體”和“微服務”的確切含義。
Particle公司的CTO Zachary Crockett告訴我:“系統(tǒng)架構位于一個頻譜上……當討論微服務時，人們往往關注這個頻譜的一端:許多微小的應用程序相互傳遞太多的消息。在這個范圍的另一端，你有一個巨大的龐然大物在做太多的事情。對于任何實際的系統(tǒng)，在這兩個極端之間都有許多可能的面向服務的體系結構。
定義龐然大物
單片應用程序構建為單個的、統(tǒng)一的單元。通常，一個整體由三部分組成:數據庫、客戶端用戶界面(由HTML頁面和/或在瀏覽器中運行的JavaScript組成)和服務器端應用程序。服務器端應用程序將處理HTTP請求，執(zhí)行特定于域的邏輯，從數據庫檢索和更新數據，并填充要發(fā)送到瀏覽器的HTML視圖。
在一個整體中，服務器端應用程序邏輯、前端客戶端邏輯、后臺作業(yè)等都定義在同一個龐大的代碼庫中。結果是:如果開發(fā)人員希望進行任何更改或更新，他們需要一次性構建和部署整個堆棧。
與你所想的相反，巨石并不是一個過時的建筑，我們不需要把它留在過去。在某些情況下，一塊巨石是最理想的。工程主管史蒂文•Czerwinski Scaylr和谷歌前員工解釋說,因為他的團隊在Scaylr很小,一個統(tǒng)一的應用程序相比,更易于管理的一切分裂成microservices:“(在早期的Scaylr)盡管我們有這些積極的經驗使用microservices在谷歌,我們去(一塊)的路線,因為擁有一個龐大的服務器意味著更少的工作對我們兩個工程師。”
當考慮一個整體架構時，你的團隊應該考慮以下幾點:
龐然大物優(yōu)點
較少的橫切關注點:單片架構的主要優(yōu)點是，大多數應用程序通常都有大量的橫切關注點，比如日志記錄、速率限制和安全特性，比如審計跟蹤和DOS保護。當所有東西都在同一個應用程序中運行時，很容易將組件連接到那些橫切關注點上。
更少的操作開銷:擁有一個[大型]應用程序意味著只需要為一個應用程序設置日志記錄、監(jiān)視和測試。它的部署通常也不那么復雜。
性能:也有性能優(yōu)勢，因為共享內存訪問比進程間通信(IPC)更快。
龐然大物缺點
緊密耦合:隨著應用程序的發(fā)展，單片應用程序服務往往會變得緊密耦合和糾纏不清，這使得出于諸如獨立擴展或代碼可維護性等目的而隔離服務變得非常困難。
更難理解:單片架構也更難理解，因為當您查看特定的服務或控制器時，可能存在依賴性、副作用和不可思議的地方。
定義MICROSERVICES
微服務本身并沒有本質上的“微”。雖然它們往往比一般的巨石要小，但它們并不一定要小。有些是，但是規(guī)模是相對的，而且在組織之間沒有衡量單位的標準。
微服務體系結構風格是一種將單個應用程序作為一組小服務來開發(fā)的方法，每個小服務都在自己的進程中運行，并與輕量級機制(通常是HTTP資源API)進行通信。這些服務是圍繞業(yè)務功能構建的，可以通過完全自動化的部署機制獨立部署。對這些服務的集中管理很少。
在考慮微服務時，您的團隊應該牢記:
Microservices優(yōu)點
更好的組織:微服務體系結構通常組織得更好，因為每個微服務都有一個非常具體的工作，不關心其他組件的工作。
解耦:解耦的服務也更容易重新組合和配置，以滿足不同應用程序的需要(例如，同時服務于web客戶端和公共API)。它們還允許在更大的集成系統(tǒng)中快速、獨立地交付單個部件。
性能:在適當的情況下，微服務也可以具有性能優(yōu)勢，這取決于它們的組織方式，因為它可以隔離熱門服務并獨立于應用程序的其余部分進行伸縮。
更少的錯誤:微服務通過在系統(tǒng)的不同部分之間建立一個難以跨越的邊界來支持并行開發(fā)。這樣做的話，你就很難——或者至少更難——去做錯誤的事情:也就是說，把不應該連接的部分連接起來，把需要連接的部分連接得太緊。
Microservices缺點
跨每個服務的橫切關注點:當您構建一個新的微服務體系結構時，您可能會發(fā)現(xiàn)許多在設計時沒有預料到的橫切關注點。您將需要為每個橫切關注點(即測試)產生單獨模塊的開銷，或者將橫切關注點封裝在所有流量都要經過的另一個服務層中。最終，即使是單片架構也傾向于通過外部服務層來為橫切關注點路由流量，但是使用單片架構，可能會延遲工作的成本，直到項目更加成熟。
更高的操作開銷:微服務經常部署在它們自己的虛擬機或容器上，導致VM爭用工作的激增。這些任務通常通過集裝箱船隊管理工具實現(xiàn)自動化。
為您的組織做出正確的決定
當您與您的團隊坐下來討論時，優(yōu)缺點可以為討論一個架構相對于另一個架構的潛在優(yōu)點和缺點提供一個通用框架。為了有效地應用這些一般原則，我采訪了幾十位cto，為您在決定什么對您的組織最有利時創(chuàng)建了一個考慮事項的規(guī)則。
你在熟悉的領域嗎?
Darby和他在Gamut的團隊能夠直接研究微服務，因為他有電子商務平臺的經驗，而他的公司對于客戶的需求有著豐富的知識。另一方面，如果他走的是一條未知的道路，那么一塊巨石可能是更安全的選擇。
你的團隊準備好了嗎?
你的團隊有微服務的經驗嗎?如果你在明年將團隊規(guī)模擴大四倍，微服務是否適合這種情況?評估團隊的這些方面對于項目的成功至關重要。
如果您的團隊準備好了，那么從微服務開始是明智的，因為它允許您從一開始就適應在微服務環(huán)境中開發(fā)的節(jié)奏。
你的基礎設施如何?
實際上，您將需要基于云的基礎設施來讓微服務為您的項目工作。
“(以前)，您希望從一個整體開始，因為您希望部署一個數據庫服務器。必須為每個微服務設置一個數據庫服務器，然后向外擴展，這是一項艱巨的任務。只有一個龐大的、精通技術的組織才能做到這一點。“而今天有了像谷歌云和亞馬遜AWS這樣的服務，你可以有很多選擇來部署微小的東西，而不需要為每個東西擁有持久層。”
評估業(yè)務風險
你可能認為微服務是作為一家充滿雄心壯志的科技創(chuàng)業(yè)公司的“正確”道路。但微服務也帶來了商業(yè)風險。大衛(wèi)·施特勞斯解釋道:
“許多團隊一開始就過度構建了他們的項目;每個人都希望自己的初創(chuàng)公司能成為下一個獨角獸，因此，他們應該用微服務或其他一些高度可伸縮的基礎設施來構建一切。但這通常是錯誤的，幾乎一直都是。
他接著說，在這些情況下，你認為你需要擴展的領域可能不是首先需要擴展的部分，這導致了錯誤的努力，即使是需要擴展的系統(tǒng)。
環(huán)境很重要
與我交談的cto具有廣泛的單體和微服務經驗。一些人滿懷信心地從微服務起步，而另一些人則在一開始就固守不變，最終隨著初創(chuàng)企業(yè)的成長，他們轉向了微服務?？紤]您自己的上下文和以下場景，以幫助確定哪種體系結構適合您的情況。
什么時候從一塊巨石開始
這里有一些場景，表明你應該開始你的下一個項目使用單片架構:
您的團隊正處于創(chuàng)建階段:您的團隊很小，只有2-5名成員，因此無法處理更廣泛、開銷更大的微服務體系結構。
您正在構建一個未經驗證的產品或概念證明:您正在構建一個市場上未經驗證的產品嗎?如果它是一個新想法，它可能會隨著時間的推移而改變和進化，因此一個整體是允許快速產品迭代的理想選擇。這同樣適用于概念證明，你的目標就是盡可能多、盡可能快地學習，即使你最終把它扔掉。
您沒有微服務經驗:如果您的團隊之前沒有微服務經驗，除非您能夠證明在這么早的階段就冒著“在飛行中”學習的風險是合理的，否則這可能是另一個您應該堅持一個整體開始的跡象。
何時開始使用微服務
以下是一些場景，表明您應該使用微服務啟動下一個項目:
您需要快速、獨立的服務交付:微服務允許在更大的集成系統(tǒng)中快速、獨立地交付單個部件。注意，根據您的團隊規(guī)模，可能需要一段時間才能看到服務交付的收益，而不是從整體開始。
平臺的一部分需要非常高效:如果您的業(yè)務正在進行pb級的日志量的密集處理，那么您可能希望用一種非常高效的語言(即c++)構建服務，而您的用戶儀表板可能是用Ruby on Rails構建的。
您計劃擴展您的團隊:從microservices開始，可以使您的團隊習慣于從一開始就在獨立的小型服務中進行開發(fā)，并且通過服務邊界將團隊分隔開，可以在需要時更容易地擴展您的團隊，而無需引入指數級復雜性。
整體并沒有消亡，微服務也不是最適合于每一種環(huán)境。避免僅僅因為微服務的爆炸式增長就一頭扎進它的誘惑。相反，請使用之前的cto的智慧來仔細考慮什么架構對您最有意義。
