基本springboot 2.0版本 spring-cloud的使用

基本springboot 2.0版本 spring-cloud的使用

Spring Cloud與Spring Boot版本匹配關係

Spring Cloud	Spring Boot
Finchley	兼容Spring Boot 2.0.x，不兼容Spring Boot 1.5.x
Dalston和Edgware	兼容Spring Boot 1.5.x，不兼容Spring Boot 2.0.x
Camden	兼容Spring Boot 1.4.x，也兼容Spring Boot 1.5.x
Brixton	兼容Spring Boot 1.3.x，也兼容Spring Boot 1.4.x
Angel	兼容Spring Boot 1.2.x

 

從Spring Cloud與Spring Boot版本匹配關係能夠看出，若是項目使用的spring boot 版本在 2.0以上，那麼必須使用spring cloud 版本 爲

Finchley.RELEASE版本 這個版本與之前的D版本有一些區別，下面主要講的就是spring cloud F版本的簡單使用

我這裏也本身搭了一套關於spring-cloud的基本使用的demo，下面我來詳細介紹下該項目

其中gitHub地址爲: https://github.com/yihec/springCloud

 

 

 

首先介紹下各個module的用途：

1.首先是eureka-server 這是一個服務註冊中心,全部的服務都會在此上面管理,在Application 上增長@EnableEurekaServer註解便可, Eureka服務端能夠部署成爲高可用，每個服務器都會複製註冊的服務狀態到其餘服務器，而後打開網址http://localhost:1001/能夠看到各個註冊的服務信息

 

2.config-server 配置中心,將各個服務配置保存在git,用於統一話管理配置文件,在 Application 上增長@EnableConfigServer註解便可。

3.server-1 和 server-2 這兩個都是服務生產者,裏面除了本地服務外，另外在server-1中使用Feign 調用了server-2的接口，Feign封裝了HTTP調用服務方法，使得客戶端像調用本地方法那樣直接調用方法，相似Dubbo中暴露遠程服務的方式，區別在於Dubbo是基於私有二進制協議，而Feign本質上仍是個HTTP客戶端。 另外還使用了一個Spring Cloud 斷路器 Hystrix， 如下是關於Hystrix的詳細介紹：

<1>服務降級:

在調用接口的時候，能夠實現一個fallback方法, 當請求後端服務出現異常的時候, 可使用fallback

方法返回的值.fallback方法的返回值通常是設置的默認值或者來自緩存.

<2>斷路器:

當Hystrix Command請求後端服務失敗數量超過必定比例(默認50%), 斷路器會切換到開路狀態(Open).

這時全部請求會直接失敗而不會發送到後端服務. 斷路器保持在開路狀態一段時間後(默認5秒),

自動切換到半開路狀態(HALF-OPEN). 這時會判斷下一次請求的返回狀況, 若是請求成功, 斷路器切回閉路

狀態(CLOSED),不然從新切換到開路狀態(OPEN). 即有自我檢測並恢復的能力.

<3> 資源隔離:

在Hystrix中, 主要經過線程池來實現資源隔離. 一般在使用的時候咱們會根據調用的遠程服務劃分出多個線

程池. 例如調用產品服務的Command放入A線程池, 調用帳戶服務的Command放入B線程池. 這樣作的主要

優勢是運行環境被隔離開了. 這樣就算調用服務的代碼存在bug或者因爲其餘緣由致使本身所在線程池被耗

盡時, 不會對系統的其餘服務形成影響. 可是帶來的代價就是維護多個線程池會對系統帶來額外的性能開

銷. 若是是對性能有嚴格要求並且確信本身調用服務的客戶端代碼不會出問題的話, 可使用Hystrix的信號

模式(Semaphores)來隔離資源.

 

另外當服務愈來愈多的時候，這時候就須要用到服務鏈路追蹤(Spring Cloud Sleuth)

在spring Cloud爲F版本的時候，已經不須要本身構建Zipkin Server了，只須要下載jar便可，下載地址：

https://dl.bintray.com/openzipkin/maven/io/zipkin/java/zipkin-server/ 而後使用java -jar啓動，

再打開http://localhost:9411/的界面，我在server-1 中調用了server-2的接口，而後點擊依賴分析，能夠看到詳細的調用狀況

 

 

4：service-zuul 路由網關 (zuul)服務，zuul 是微服務架構的不可或缺的一部分，提供動態路由，監控，安全，權限認證等服務。能夠在這裏面進行統一的好比異常處理，權限認證等等。其實跟spring中的uri 過濾器有點像，首先全部的請求第一時間通過這裏，而後經過 過濾處理，跳轉不一樣的頁面

 

5.消息總線(Spring Cloud Bus) Spring Cloud Bus 將分佈式的節點用輕量的消息代理鏈接起來。它能夠用於廣播配置文件的更改或者服務之間的通信，也能夠用於監控。主要就是說，當修改了配置中心的配置以後，之前通常來講須要從新啓動項目，而如今不須要進行重啓就能夠實現配置刷新。

1.引入spring-cloud-starter-bus-amqp

2.配置rabbitmq信息

3.項目中引入@RefreshScope 註解，而後啓動項目

此時rabbitmq管理頁面，會自動建立一個 topic 類型的 Exchange

 

 

接着修改配置中心，也就是git倉庫裏面的配置信息，而後調用http://localhost:2001/actuator/bus-refresh/ 記得要使用POST方式，最好在postman裏面調用，瀏覽器中是不行的，而後頁面自動刷新配置信息，具體實現能夠參考 server-1 中的代碼

6：hystrix-dashboard 斷路器監控(Hystrix Dashboard) 在微服務架構中爲例保證程序的可用性，防止程序出錯致使網絡阻塞，出現了斷路器模型。斷路器的情況反應了一個程序的可用性和健壯性，它是一個重要指標。Hystrix Dashboard是做爲斷路器狀態的一個組件，提供了數據監控和友好的圖形化界面。

啓動server-1項目，輸入網址http://localhost:2001/hystrix，

 

在SpringBoot 2.0版本中會出現Unable to connect to Command Metric Stream.異常信息，此時須要配置 servlet

 

 

 

而後 在界面依次輸入：http://localhost:2001/hystrix.stream 、2000 、aa(標題，隨便取)；點肯定。而後調用接口輸入網址 http://localhost:2001/HelloServer2 ，會出現下面頁面，這個就是服務調用錯誤的提示

最後啓動server-2，接口調用成功

以上就是關於spring-cloud的一些簡單使用，其中有疑問或者不對的地方，但願你們留言指出，感謝!

參考資料：https://blog.csdn.net/forezp/article/details/70148833/

https://gitee.com/didispace/SpringCloud-Learning