作為一名開發者，你肯定經常聽到像“我們採用了可伸縮的微服務架構”、“我們正在計劃切換到微服務架構”之類的話，然後你尋思著：微服務到底是什麼？近日，西達爾特·馬霍特拉（Sidharth Malhotra）通過真實世界的比喻解釋了什麼是微服務架構，重點內容如下。

大冰激凌機——單體

　　冰激凌機由四個部件組成——冰淇淋勺、堅果粉碎器、巧克力漏斗和草莓糖漏斗。冰淇淋勺往杯子裡新增香草或芒果冰激凌，堅果粉碎器將碎堅果撒在冰激凌上，巧克力或草莓漏斗把液體糖漿倒在冰激凌上。對於顧客來說，除了冰激凌勺之外，其他都是可選的。 　　假設你是冰激凌店的老闆，一開始你有一臺小冰激凌機，這個冰激凌機配備了所有上述的四個部件。顧客很喜歡你家的冰激凌，你的生意越來越紅火。那麼接下來你會怎麼做？你會買一臺更大的冰激凌機，這樣就可以在同樣的時間內做出更多的冰激凌。按照這樣的節奏發展下去，終有一天你會沒辦法再擴大規模，因為工廠生產不出更大的冰激凌機了。 在軟體開發領域，這就是所謂的單體架構。一個包含了所有元件的應用程式，程式碼都存放在一個程式碼基庫裡。隨著需求的增長，你租用了越來越大的機器，而到了某個時刻肯定會達到極限，因為你租不到比目前更大的機器了。 　　這時，你一定會想到通過購買更多的冰激凌機來解決這個問題。所以你放棄了購買更大的冰激凌機的想法，而是購買更多小型的冰激凌機。 　　這就是所謂的“克隆”，你會使用多個應用程式例項來處理使用者請求。 　　

每臺機器各司其職——微服務

　　在剛開店時，你只聘請了一名負責維修和升級機器的師傅。但在購買了多臺機器之後，你覺得有必要聘請更多的師傅，因為你不希望有機器壞了影響生意。 現在，有顧客希望你家的店能夠增加不同口味的冰激凌。你決定在冰激凌勺裡增加巧克力冰激凌。但因為冰激凌機的四個部件相互依賴，動了其中一個就會影響到其他部件，等維修師傅好不容易加好了新口味的冰激凌，草莓糖漏斗卻壞了， 　　因為伸縮性受到了限制，你決定搭建新的基礎設施。你要求工廠把原先冰激凌機的每個部件獨立成單獨的機器，變成一個冰激凌勺機，一個堅果粉碎機，兩個漏斗機（一個可以流出巧克力，一個可以流出草莓糖）。並且你把維修師傅分成幾組，每一組負責不同的機器。 　　這就是所謂的微服務架構，大單體被拆分成多個獨立的模組，每個模組都是一個應用程式，負責處理不同的任務。 　　

單體與微服務

　　對於伸縮性，你可能已經注意到了，在購買了最大型的冰激凌之後，你就沒辦法再擴大規模了。但有了單獨的部件機器（微服務）之後，你可以購買更多的部件機器。 　　對於可維護性，為了給冰激凌機增加新口味的冰激凌，卻不小心弄壞了草莓糖漏斗，因為一個大單體系統的不同部分通常是相互依賴的，修改某個部分會影響到其他部分。而在微服務架構裡，不同的機器由不同的團隊負責，每個團隊管好自己負責的機器，避免了衝突。這種獨立的開發模式也加快了發版的速度，因為在一個大型組織裡，團隊內的溝通比團隊間的溝通效率更高。 　　關於成本，你可能會想，多買幾臺大冰激凌機不就能解決伸縮性問題嗎？但也請試想一下，如果你只想增加冰激凌口味並保持其他部分不變，你不得不為此購買整套機器。而在微服務機構中，你可以只買冰激凌勺機。這樣就節約了很多成本，因為你可以根據每個服務的請求量來增加或者減少單個服務的例項數量。 　　關於就緒時間，大冰激凌機已經把所有的部件都整合好了，只要把它放在正確的地方，並啟動它就可以了。但是，獨立的部件機器在使用前需要用傳送帶把它們連線在一起。因此，微服務需要更多的時間和專業知識才能讓它執行起來。 　　在測試和部署方面，大冰激凌機的測試和部署相對困難，因為所有的部件相互依賴，需要每個部件都整合好了才能測試和部署。但對於部件機器來說，因為每種機器都是獨立的，所以測試和部署也相對容易。 以上就是今天的內容，你理解單體與微服務是什麼了嗎？   原文連結[有牆]：Beginner’s Guide to Microservices: Explaining it to a 5 Year Old