究竟是否應該使用「微服務架構」？

前言

通過當前服務端的洗禮以後，市場出現了一波微服務的熱潮。而後就出現了很大的一個問題，不管什麼項目，不少人想都不想，都直接開始說咱們使用微服務架構來完成吧，用這個、這個組件很簡單就能實現。。。並且，如今市場上不少學習教程都直接教授微服務的架構使用。不少學習的人看到這樣的趨勢就會隨大流，就致使了當前的問題，炒做這樣概念的人不少，不多人知其因此然。

通過一段時間的整理，梳理出了下面幾個點，可供參考。

但願通過這些簡短的參考能幫助你認識，技術的因此然。

 

什麼是「微服務架構」

官方：一種將一個單一應用程序開發爲一組小型服務的方法，每一個服務運行在本身的進程中，服務間通訊採用輕量級通訊機制。這些服務圍繞業務能力構建而且能夠獨立部署。依賴一個最小型的集中式管理。

總結爲幾點：

一、獨立運行

二、獨立部署

三、獨立開發

四、輕量級通訊

五、集中管理

這樣說仍是有點抽象，舉個實際的例子來講，好比購物：咱們能夠拆分爲，用戶微服務，訂單微服務，商品微服務…..

每一個服務都有以上特色，之間獨立，又能夠通訊，依賴一些管理的東西去管理他們。

中心思想：把大系統拆分紅小型系統，把大事化小，以下降系統的複雜性

 

「微服務架構」的優勢和缺點

若是隻是說一個東西的優勢是沒用的，只有對比來看，因此咱們對比單體應用來講明其優勢。

一、部署：

單體應用部署確定簡單，一個包扔進去，容器啓動就能夠了。

微服務應用部署會負責，服務越多部署越麻煩，並且有些依賴與一些中間件，因此運維和部署的壓力變大是確定的。（這裏並非說必定的，已經有一些運維部署的軟件方便了微服務的部署）

二、開發和維護：

單體應用若是要進行開發，代碼即便分離的再好，那麼仍是在一塊兒，因此會顯得臃腫，維護起來不方便，若是須要改動一個點，整個服務必須所有從新啓動。

微服務開發由於自己分離，因此顯得清晰，維護起來方便，一個地方的服務出現問題，只須要改動對應服務並重啓對應服務便可。

三、擴展：

單體應用擴展可想而知，受限而且壓力很大，到最後不少人會發現，加入或者擴展功能時寧肯新開發一個也不肯意去依賴原來的代碼就怕改了原來的代碼以前的代碼出現問題。

微服務擴展能力較好，新加入一個功能不會對原來的系統形成影響。並且若是一個大的功能被禁用，直接中止對應服務便可。

四、通訊：

對於單體應用來講，本身自己都是內部服務調用不存在通訊問題，對於外部庫來講，通訊方式取決於外部庫的依賴。

微服務之間的通訊就須要依賴比較靠譜的通訊系統了，由於不免服務與服務之間會有依賴，那麼通訊方式的選擇就尤其重要了。

 

究竟是否應該使用「微服務架構」？

最後咱們再來看看咱們一開始的問題，是否是就能總結出如下幾個點了。而後我結合一些書本和經驗作下面一個總結，但願對你有幫助。

一、系統大小

這是咱們首要的考慮目標，若是一個系統很小，好比一個官網，那你說作微服務就是扯淡了。那麼如何肯定一個系統的大小呢？能夠參考一下下面這個標準。

若是你的項目能分紅三個或三個以上的耦合度很低的項目，那麼就算大。

若是你的項目數據庫表超過30張，且單表數據輕鬆百萬，那麼就算大。

若是你的項目以後會進行擴展，而且擴展以後會達到上面的若是，那麼也算大。

雖然只是經驗上的估計參考，可是也從側面體現出，若是項目不大，那麼真的就不必。

 

二、技術能力

微服務依賴的能力有如下幾點

拆分服務的能力

處理分佈式問題（網絡請求，分佈式事務等）的能力

強大的運維能力

若是一個系統決定使用微服務架構，那麼前期的拆分就顯得很是重要，有經驗的拆分可讓服務之間的耦合對降到最低，而且相應的業務沒有問題。相應的，若是沒有處理分佈式問題的能力也是不行的，最後纔是項目部署運維的能力。

 

三、團隊規模和時間

若是你的團隊規模不超過10人，那麼除非大家能力都很是牛，並且都能獨當一面，那麼當我沒說，理論上不建議。

在開發週期時間不容許的狀況下不要執意去切換，從單體切換到微服務，由於二者區別不只僅是在服務上，包括通訊等等方面耗時都不短，測試上面就須要更加多的時間去測試。並且微服務的開發效率上面是一開始慢，到項目大了以後開發效率才慢慢的體現出來。

微服務畢竟存在通訊，並且服務器想對多，項目穩定性上確定要打折扣。你的團隊須要提早了解到這樣的問題，並作好遇到問題的準備和處理，這也是須要時間的。

團隊之間的溝通，有通訊必然有交流，否則別人怎麼知道你的服務是怎麼樣的。那麼接口文檔編寫的時間和對接接口的時間，調試的時間，剩下我就很少說了，你應該懂了。

 

總結

一個技術或者一個架構不是萬能的，每一個技術都有適用的場景，咱們所要作的不是一味的追求最新，而是明白它的使用場景或者優勢缺點，從而來考慮是否使用。

這裏上面也只是拋磚引玉，全部的細節確定不是一篇文章或者一本書能說完的，只要你去考慮了，借鑑一些別人的經驗去發現可能存在的問題，那麼即便最後出現問題也能夠被解決。

 

參考文檔：

《SpringCloud與Docker微服務架構實戰》

http://www.infoq.com/cn/minibooks/microservice--from-zero