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

• 2019 年 10 月 4 日
• 筆記

前言:

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

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

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

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

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

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

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

微服務的優勢

大項目可以持續交付

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

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

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

易於維護

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

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

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

服務可以獨立擴展

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

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

更強的容錯性

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

可以靈活的採用最新技術

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

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

微服務的弊端

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

• 服務的拆分

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

• 分佈式系統帶來的挑戰

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

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

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

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

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

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