什麼是集羣、分佈式和微服務？

如何選應用架構？
最近微服務架構很是流行，10我的的小公司作個項目也要求把微服務架構作爲硬性條件，網站日訪問量不到1000的web應用也要求用微服務架構，那麼到底使用微服務架構好很差，我來通俗的講一下。要弄清楚這個問題，須要理解下面幾個流行語。

集羣

通俗解釋一下集羣：爲了建設一棟房子，須要砌磚，一我的砌磚太慢，須要10我的磚瓦工人同事去砌，這樣就大大提升了效率，咱們說這10我的就組成了一個集羣。集羣是全部人都是幹同一件事，你們一塊兒幹，每一個人相互之間不依賴。放到咱們的軟件生產環境，集羣就是經過堆積服務器硬件來作同一個工做來提升效率。

分佈式

分佈式，顧名思義，就是有個分工的概念。仍是用砌磚的例子來講，咱們砌磚，須要先把搬運磚頭，放到牆邊，須要水泥砂漿，而後才能開始砌磚的工做。若是和水泥砂漿，搬磚，砌牆都給同一我的作，即便是10我的，可能效率也不高，這個時候分佈式就上場了。咱們能夠安排2我的專門和水泥砂漿，2我的搬磚運到牆下，6我的只管砌磚。這種狀況下，雖然人員沒有增多，可是效率確定會提升。那能夠這麼理解，集羣不必定是分佈式，但分佈式確定是集羣，它須要多個服務器來協同工做。那這個時候，還會有一個問題，若是水泥砂漿沒有了，那砌磚工人須要通知和水泥砂漿暫停，趕忙把弄好的水泥砂漿運到牆邊。現實中能夠用嘴喊，能夠手機打電話，服務器這個時候怎麼通知，這就涉及到rpc（remote process communication），這個咱們簡單提一下，下次能夠單獨深刻討論。

微服務

微服務是一種架構，原理和分佈式很像，它的拆分粒度很細，細到每一個人僅作一件不可分解的事情，而這些細微的事情不必定每一個都放在不一樣服務器上，一個服務器上能夠放不少微服務如A服務，B服務，C服務，另一臺服務器放B服務，C服務，D服務。值得注意的是，全部服務都須要通知一個叫註冊中心的地方，能夠理解這個爲工程項目經理，他來統一協調管理。

總結

若是你的業務很簡單，訪問量也不多，那全部應用放一臺服務器也能夠流暢的運行，這個時候連集羣都不須要用。
若是你的訪問量不多，可是業務很複雜，打個比方，以電商下單爲例，下單的過程，須要提交訂單，支付，同事須要覈查倉庫是否有庫存，而後再把地址發給第三方物流下單，若是這些事情放一塊兒作，須要30秒。用戶須要等待30秒才能看見本身是否購買成功了，這樣體驗很是很差，即便你的平臺一天只成交100單， 訪問量很小，用戶體驗仍是很差。這個時候你能夠用分佈式來解決這個問題，把支付，查庫存，通知第三方物流等拆分紅5個或者更多的工做。這樣，用戶體驗大大提升，幾秒就能夠完成一次購物。
若是你的訪問量很大，每一個流程步驟很複雜，那這個時候，你能夠將步驟分佈式，再多分配幾個服務器集羣，這個時候用微服務架構就更合適了。根據以前運營app的經驗，日訪問量幾百萬，每一個交互都是2秒之內的應用，只要帶寬足夠，將web和數據庫分離加上一個redis緩存，2臺主流服務器就足夠了。

本文由Websoft9原創發佈，轉載請註明出處。