微服務(wù)的優(yōu)勢在哪里，為什么別人都在說微服務(wù)好

微服務(wù)的優(yōu)勢在哪里，為什么別人都在說微服務(wù)好

前言:

在介紹微服務(wù)時，首先得先理解什么是微服務(wù)，顧名思義，微服務(wù)得從兩個方面去理解，什么是"微"、什么是"服務(wù)"，

微，狹義來講就是體積小、著名的"2 pizza 團隊"很好的詮釋了這一解釋（2 pizza 團隊最早是亞馬遜 CEO Bezos提出來的，意思是說單個服務(wù)的設(shè)計，所有參與人從設(shè)計、開發(fā)、測試、運維所有人加起來 只需要2個披薩就夠了 ）。 而所謂服務(wù)，一定要區(qū)別于系統(tǒng)，服務(wù)一個或者一組相對較小且獨立的功能單元，是用戶可以感知最小功能集。

微服務(wù)這么火，多少人多少公司都想試試水。

了解到很多小伙伴在找 Java 開發(fā)工作時，如果這個公司用的微服務(wù)架構(gòu)，就覺得很牛逼，進去了很有前景，如果沒用微服務(wù)，甚者還用的是以前的 SSH ，就會覺得沒前景，不想去。由此可見微服務(wù)在大家心中的分量。

不過話說回來，并非每一個項目都是適合用微服務(wù)架構(gòu)，也并非每一個公司都需要微服務(wù)架構(gòu)。有個朋友在某網(wǎng)紅茶公司做微服務(wù)開發(fā)，新項目架構(gòu)師強行上馬微服務(wù)，結(jié)果項目上線后，一個小小的變更都要修改許多服務(wù)才能解決，沒辦法，架構(gòu)師只能卷鋪蓋走人了，項目又變回了單體應(yīng)用。

我覺得這樣的例子不是個案，項目要不要上馬微服務(wù)，還是要看項目和公司的具體情況，不盲目，不跟風。

今天來和大家聊一聊微服務(wù)到底有哪些好處，又有哪些弊端。

微服務(wù)的優(yōu)勢

大項目可以持續(xù)交付

微服務(wù)將一個大系統(tǒng)拆分成很多個互相獨立的服務(wù)，每一個服務(wù)都可以由一個團隊去完成，并且配備自己的開發(fā)、部署，而且可以獨立于其他的團隊。每一個團隊開發(fā)的微服務(wù)都可以由自己的代碼倉庫、以及部署流水線等，互不相擾。

在微服務(wù)中，一個大項目被拆分成 n 多個小項目，每一個小項目都可以非常方便的進行測試、部署，而不會牽一發(fā)而動全身，原本需要全員高度警戒的項目上線，現(xiàn)在分散到不同的團隊中去完成。

我六月底參加深圳的一個線下技術(shù)活動，某在線編程的 CEO 談到他們公司的發(fā)版，說：“我說話的這會兒，我們可能就有新版本在發(fā)布。”，這句話令我印象深刻。傳統(tǒng)的單體應(yīng)用，沒人敢這么搞，微服務(wù)時代，這一切才變得可能。

易于維護

這個不必多說，相信大家都理解。

一個傳統(tǒng)的單體應(yīng)用，如果你新接手，一時半會還不一定能理出一個頭緒，而如果是微服務(wù)，由于比較小巧玲瓏，一個微服務(wù)只負責一件事情，很容易理出頭緒，然后上手開發(fā)。

并且相對于單體應(yīng)用，微服務(wù)規(guī)模都比較小，無論你用 Eclipse 還是 IDEA，項目啟動、測試速度都比較快。

服務(wù)可以獨立擴展

獨立擴展，可以讓我們充分使用硬件資源。

傳統(tǒng)的單體應(yīng)用，所有的功能模塊都寫在一起，有的模塊是 CPU 運算密集型的，有的模塊則是對內(nèi)存需求更大的，這些模塊的代碼寫在一起，部署的時候，我們只能選擇 CPU 運算更強，內(nèi)存更大的機器，如果采用了了微服務(wù)架構(gòu)，不同的系統(tǒng)獨立部署，壓力大的時候，可以獨立進行集群化部署，這些操作都不會影響到已經(jīng)運行的其他微服務(wù)，非常靈活。

更強的容錯性

由于每一個微服務(wù)都是獨立運行的，處理得當，我們在微服務(wù)架構(gòu)中可以實現(xiàn)更好的故障隔離。當一個微服務(wù)發(fā)生問題時，例如內(nèi)存泄漏，不會影響到其他的微服務(wù)。

可以靈活的采用最新技術(shù)

傳統(tǒng)的單體應(yīng)用一個非常大的弊端就是技術(shù)棧升級非常麻煩，這也是為什么你經(jīng)常會見到用 10 年前的技術(shù)棧做的項目，現(xiàn)在還需要繼續(xù)開發(fā)維護。不是他們不愿意升級，而是升級實在是太麻煩了，傷筋動骨。

而在微服務(wù)架構(gòu)中，每一個服務(wù)都是獨立運行的，單個微服務(wù)的技術(shù)升級則非常容易。你可以隨意去嘗試你喜歡的最新技術(shù)。因為試錯成本很低，因此大家可以盡情的玩耍。

微服務(wù)的弊端

事物都有兩面性，微服務(wù)也有一些挑戰(zhàn)，這些挑戰(zhàn)性問題如果處理不好，你使用微服務(wù)可能反而適得其反。那么都有哪些問題呢？

• 服務(wù)的拆分

個人覺得，這是最大的挑戰(zhàn)，我了解到一些公司做微服務(wù)，但是服務(wù)拆分的亂七八糟。這樣到后期越搞越亂，越搞越麻煩，你可能會覺得微服務(wù)真坑爹，后悔當初信了說微服務(wù)好的鬼話。

• 分布式系統(tǒng)帶來的挑戰(zhàn)

記得以前在網(wǎng)上看到過一個段子：

沒用分布式架構(gòu)之前，你只有一個問題：并發(fā)性能不足。用了分布式架構(gòu)，多出了一堆問題：數(shù)據(jù)如何同步、主鍵如何產(chǎn)生、如何熔斷、分布式事務(wù)如何處理......。

這個段子形象的說明了分布式系統(tǒng)帶來的挑戰(zhàn)。

• 多個研發(fā)團隊的協(xié)調(diào)管理

傳統(tǒng)的單體應(yīng)用開發(fā)，一個團隊管理好就行了，現(xiàn)在不同的團隊開發(fā)不同的微服務(wù)，要協(xié)調(diào)多個團隊共同配合，才能做好微服務(wù)開發(fā)，這對項目管理提出了挑戰(zhàn)。

好了，本文就先說這么多，大伙可以留言說說你的項目有沒有使用微服務(wù)，出于什么樣的考慮而使用了目前的架構(gòu)呢？