微服務的優勢在哪里，為什么別人都在說微服務好

微服務的優勢在哪里，為什么別人都在說微服務好

前言:

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

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

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

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

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

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

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

微服務的優勢

大項目可以持續交付

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

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

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

易于維護

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

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

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

服務可以獨立擴展

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

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

更強的容錯性

由于每一個微服務都是獨立運行的，處理得當，我們在微服務架構中可以實現更好的故障隔離。當一個微服務發生問題時，例如內存泄漏，不會影響到其他的微服務。

可以靈活的采用最新技術

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

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

微服務的弊端

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

• 服務的拆分

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

• 分布式系統帶來的挑戰

記得以前在網上看到過一個段子：

沒用分布式架構之前，你只有一個問題：并發性能不足。用了分布式架構，多出了一堆問題：數據如何同步、主鍵如何產生、如何熔斷、分布式事務如何處理......。

這個段子形象的說明了分布式系統帶來的挑戰。

• 多個研發團隊的協調管理

傳統的單體應用開發，一個團隊管理好就行了，現在不同的團隊開發不同的微服務，要協調多個團隊共同配合，才能做好微服務開發，這對項目管理提出了挑戰。

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