1、什麼是springcloud,有什麼做用前端
Spring Cloud是一系列框架的有序集合。它利用Spring Boot的開發便利性巧妙地簡化了分佈式系統基礎設施的開發,如服務發現註冊、配置中心、消息總線、負載均衡、斷路器、數據監控等,均可以用Spring Boot的開發風格作到一鍵啓動和部署。算法
Spring Cloud是一個全家桶式的技術棧,包含了不少組件,實例 fhadmin 官網 。先從其最核心的幾個組件入手,來剖析一下其底層的工做原理。也就是Eureka、Ribbon、Feign、Hystrix、Zuul這幾個組件。spring
Eureka數據庫
Eureka是微服務架構中的註冊中心,專門負責服務的註冊與發現。庫存服務、倉儲服務、積分服務中都有一個Eureka Client組件,Eureka Client這個組件專門負責將這個服務的信息註冊到Eureka Server中(就是告訴Eureka Server,本身在哪臺機器上,監聽着哪一個端口)。而Eureka Server是一個註冊中心,裏面有一個註冊表,保存了各服務所在的機器和端口號。後端
訂單服務裏也有一個Eureka Client組件,這個Eureka Client組件會找Eureka Server問一下:庫存服務在哪臺機器啊?監聽着哪一個端口啊?倉儲服務呢?積分服務呢?而後就能夠把這些相關信息從Eureka Server的註冊表中拉取到本身本地緩存起來。緩存
總結:安全
Eureka Client:負責將這個服務的信息註冊到Eureka Server中網絡
Eureka Server:註冊中心,裏面有一個註冊表,保存了各個服務所在的機器和端口號架構
Feign併發
Feign的一個關鍵機制就是使用了動態代理。
首先,若是你對某個接口定義了@FeignClient註解,Feign就會針對這個接口建立一個動態代理
接着你要是調用那個接口,本質就是會調用 Feign建立的動態代理,這是核心中的核心
Feign的動態代理會根據你在接口上的@RequestMapping等註解,來動態構造出你要請求的服務的地址
最後針對這個地址,發起請求、解析響應
Ribbon
Ribbon的做用是負載均衡,會幫你在每次請求時選擇一臺機器,均勻的把請求分發到各個機器上。Ribbon的負載均衡默認使用的最經典的Round Robin輪詢算法。
Ribbon是和Feign以及Eureka緊密協做,完成工做的,具體以下:
首先Ribbon會從 Eureka Client裏獲取到對應的服務註冊表,也就知道了全部的服務都部署在了哪些機器上,在監聽哪些端口號。
而後Ribbon就可使用默認的Round Robin算法,從中選擇一臺機器
Feign就會針對這臺機器,構造併發起請求。
Hystrix
Hystrix會搞不少個小小的線程池,好比訂單服務請求庫存服務是一個線程池,請求倉儲服務是一個線程池,請求積分服務是一個線程池。每一個線程池裏的線程就僅僅用於請求那個服務。
降級:每次調用積分服務,你就在數據庫裏記錄一條消息,說給某某用戶增長了多少積分,由於積分服務掛了,致使沒增長成功!這樣等積分服務恢復了,你能夠根據這些記錄手工加一下積分。這個過程,就是所謂的降級。
Zuul
Zuul,也就是微服務網關。這個組件是負責網絡路由的。全部請求都往網關走,網關會根據請求中的一些特徵,將請求轉發給後端的各個服務。有一個網關以後,還有不少好處,好比能夠作統一的降級、限流、認證受權、安全,等等。
總結:
Eureka:各個服務啓動時,Eureka Client都會將服務註冊到Eureka Server,而且Eureka Client還能夠反過來從Eureka Server拉取註冊表,從而知道其餘服務在哪裏
Ribbon:服務間發起請求的時候,基於Ribbon作負載均衡,從一個服務的多臺機器中選擇一臺
Feign:基於Feign的動態代理機制,根據註解和選擇的機器,拼接請求URL地址,發起請求
Hystrix:發起請求是經過Hystrix的線程池來走的,不一樣的服務走不一樣的線程池,實現了不一樣服務調用的隔離,避免了服務雪崩的問題
Zuul:若是前端、移動端要調用後端系統,統一從Zuul網關進入,由Zuul網關轉發請求給對應的服務