分散式微服務架構(一)

enjoybeng 發表於 2021-07-14
微服務

一、為什麼要使用微服務架構?

  隨著使用者增加,流量增大,單個伺服器部署已無法滿足複雜業務處理和系統執行時,考慮負載均衡,橫向擴充套件將整個專案部署到很多臺機器,使用代理來協呼叫戶訪問問題;

但隨之出現的問題是,負載均衡只是將同一套系統部署了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  一站式解決方案

    。。。

相關文章