一、為什麼要使用微服務架構？
隨著使用者增加，流量增大，單個伺服器部署已無法滿足複雜業務處理和系統執行時，考慮負載均衡，橫向擴充套件將整個專案部署到很多臺機器，使用代理來協呼叫戶訪問問題；
但隨之出現的問題是，負載均衡只是將同一套系統部署了N遍，分別部署在了A、B、C.....等多臺伺服器上，假設系統有使用者模組、訂單模組、物流模組、售後模組等等。。。，但每個模組的使用頻率不同，所以有可能造成伺服器資源浪費，而且並未從根源解決核心業務處理速度問題。
於是，出現了微服務架構：將系統按照功能模組進行拆分，各個伺服器各司其職，分別處理整個業務環節中自己所負責的模組。例如：A伺服器專門處理使用者管理相關功能，B、C伺服器專門處理訂單相關功能，D伺服器專門處理支付結算功能等等。。。，將各模組拆分單獨處理，對外提供服務，各模組之間通過呼叫其他伺服器提供的服務進行資料交換。由於需要不同伺服器之間進行通訊，所以微服務需要解決以下幾個問題
二、微服務需要解決哪些問題？
1、這麼多服務，客戶端該如何進行訪問？（API閘道器）
2、這麼多服務分別部署在不同的伺服器上，他們之間如何進行通訊？（RPC框架）
3、這麼多服務如何暴露出去？如何讓別人可以知道並且呼叫？如何統一管理這些服務？（服務註冊與發現）
4、服務掛了怎麼辦？（熔斷機制）
基於這四個核心問題，於是就出現了以下幾種解決方案
三、微服務解決方案
1、SpringCloud Netflix ，出了一整套解決方案
API閘道器：Zuul 元件
RPC框架：Feign ---> HTTPClient ---> http通訊方式，同步並阻塞
服務註冊與發現：Eureka
熔斷機制：Hystrix
2、Apache Dubbo + Zookeeper 並不是一套完善的解決方案
API閘道器：未提供，需自行實現或使用第三方外掛
RPC框架：Dubbo 一個高效能的基於Java實現的RPC框架
服務註冊與發現：Zookeeper
熔斷機制：未提供，藉助了 Hystrix
3、SpringCloud Alibaba 一站式解決方案
。。。