如何選應用架構？
最近微服務架構非常流行，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原創發布，轉載請注明出處，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/228755.html
標籤：其他
上一篇：容器（六）docker managed volume【35】
下一篇：容器（六）如何共享資料？【36】