一、必不可少的 Hystrix
- 1.什么是 Hystrix之熔斷和降級
- 2.什么是Hystrix之其他
二、微服務網關——Zuul
- 1.Zuul 的路由功能
- - 1)簡單配置
  - 2)統一前綴
  - 3)路由策略配置
  - 4)服務名屏蔽
  - 5)路徑屏蔽
  - 6)敏感請求頭屏蔽
- 2.Zuul 的過濾功能
- - 1)簡單實作一個請求時間日志列印
  - 2)令牌桶限流
- 3.關于 Zuul 的其他
- 4.為什么要使用進行配置管理？
- 5.Config 是什么
三、引出 Spring Cloud Bus
四、總結

一、必不可少的 Hystrix

1.什么是 Hystrix之熔斷和降級

在分布式環境中，不可避免地會有許多服務依賴項中的某些失敗，Hystrix是一個庫，可通過添加等待時間容限和容錯邏輯來幫助您控制這些分布式服務之間的互動，Hystrix通過隔離服務之間的訪問點，停止服務之間的級聯故障并提供后備選項來實作此目的，所有這些都可以提高系統的整體彈性，

總體來說 Hystrix 就是一個能進行熔斷和降級的庫，通過使用它能提高整個系統的彈性，

那么什么是熔斷和降級呢？再舉個栗子，此時我們整個微服務系統是這樣的，服務A呼叫了服務B，服務B再呼叫了服務C，但是因為某些原因，服務C頂不住了，這個時候大量請求會在服務C阻塞，

服務C阻塞了還好，畢竟只是一個系統崩潰了，但是請注意這個時候因為服務C不能回傳回應，那么服務 B呼叫服務C的的請求就會阻塞，同理服務B阻塞了，那么服務A也會阻塞崩潰，

請注意，為什么阻塞會崩潰，因為這些請求會消耗占用系統的執行緒、IO 等資源，消耗完你這個系統服務器不就崩了么，

這就叫 服務雪崩，媽耶，上面兩個熔斷和降級你都沒給我解釋清楚，你現在又給我扯什么 服務雪崩？

別急，聽我慢慢道來，

不聽我也得講下去！

所謂熔斷就是服務雪崩的一種有效解決方案，當指定時間窗內的請求失敗率達到設定閾值時，系統將通過 斷路器 直接將此請求鏈路斷開，

也就是我們上面服務B呼叫服務C在指定時間窗內，呼叫的失敗率到達了一定的值，那么 Hystrix 則會自動將服務B與C 之間的請求都斷了，以免導致服務雪崩現象，

其實這里所講的熔斷就是指的 Hystrix 中的 斷路器模式 ，你可以使用簡單的 @HystrixCommand 注解來標注某個方法，這樣 Hystrix 就會使用 斷路器 來“包裝”這個方法，每當呼叫時間超過指定時間時(默認為1000ms)，斷路器將會中斷對這個方法的呼叫，

當然你可以對這個注解的很多屬性進行設定，比如設定超時時間，像這樣，

@HystrixCommand( 
	commandProperties = {@HystrixProperty(name = 
"execution.isolation.thread.timeoutInMilliseconds",value = "1200")} 
)public List<Xxx> getXxxx() { 
	// ...省略代碼邏輯 
}

但是，我查閱了一些博客，發現他們都將熔斷和降級的概念混淆了，以我的理解，**降級是為了更好的用戶體驗，當一個方法呼叫例外時，通過執行另一種代碼邏輯來給用戶友好的回復，**這也就對應著 Hystrix 的 后備處理 模式，你可以通過設定 fallbackMethod 來給一個方法設定備用的代碼邏輯，比如這個時候有一個熱點新聞出現了，我們會推薦給用戶查看詳情，然后用戶會通過id去查詢新聞的詳情，但是因為這條新聞太火了(比如最近什么*易對吧)，大量用戶同時訪問可能會導致系統崩潰，那么我們就進行 服務降級 ，一些請求會做一些降級處理比如當前人數太多請稍后查看等等，

// 指定了后備方法呼叫 
@HystrixCommand(fallbackMethod = "getHystrixNews") 
@GetMapping("/get/news") 
public News getNews(@PathVariable("id") int id) { 
	// 呼叫新聞系統的獲取新聞api 代碼邏輯省略 
}
//
public News getHystrixNews(@PathVariable("id") int id) { 
	// 做服務降級 
	// 回傳當前人數太多，請稍后查看 
}

2.什么是Hystrix之其他

我在閱讀《Spring微服務實戰》這本書的時候還接觸到了一個 艙壁模式 的概念，在不使用艙壁模式的情況下，服務A呼叫服務B，這種呼叫默認的是 使用同一批執行緒來執行 的，而在一個服務出現性能問題的時候，就會出現所有執行緒被刷爆并等待處理作業，同時阻塞新請求，最終導致程式崩潰，而艙壁模式會將遠程資源呼叫隔離在他們自己的執行緒池中，以便可以控制單個表現不佳的服務，而不會使該程式崩潰，

具體其原理我推薦大家自己去了解一下，本篇文章中對 艙壁模式 不做過多解釋，當然還有 Hystrix 儀表盤，它是用來實時監控 Hystrix 的各項指標資訊的，這里我將這個問題也拋出去，希望有不了解的可以自己去搜索一下，

二、微服務網關——Zuul

ZUUL 是從設備和 web 站點到 Netflix 流應用后端的所有請求的前門，作為邊界服務應用，ZUUL 是為了實作動態路由、監視、彈性和安全性而構建的，它還具有根據情況將請求路由到多個 Amazon Auto Scaling Groups（亞馬遜自動縮放組，亞馬遜的一種云計算方式）的能力

在上面我們學習了 Eureka 之后我們知道了服務提供者是消費者通過 Eureka Server 進行訪問的，即 Eureka Server 是服務提供者的統一入口，那么整個應用中存在那么多消費者需要用戶進行呼叫，這個時候用戶該怎樣訪問這些消費者工程呢？當然可以像之前那樣直接訪問這些工程，但這種方式沒有統一的消費者工程呼叫入口，不便于訪問與管理，而 Zuul 就是這樣的一個對于消費者的統一入口，

如果學過前端的肯定都知道 Router 吧，比如 Flutter 中的路由，Vue，React中的路由，用了 Zuul 你會發現在路由功能方面和前端配置路由基本是一個理，我偶爾擼擼 Flutter，

大家對網關應該很熟吧，簡單來講網關是系統唯一對外的入口，介于客戶端與服務器端之間，用于對請求進行鑒權、限流、路由、監控等功能，

沒錯，網關有的功能， Zuul 基本都有，而 Zuul 中最關鍵的就是 路由和過濾器 了，在官方檔案中 Zuul 的標題就是

Router and Filter : Zuul

1.Zuul 的路由功能

1)簡單配置

本來想給你們復制一些代碼，但是想了想，因為各個代碼配置比較零散，看起來也比較零散，我決定還是給你們畫個圖來解釋吧，

比如這個時候我們已經向 Eureka Server 注冊了兩個 Consumer 、三個 Provicer ，這個時候我們再加個 Zuul 網關應該變成這樣子了，

emmm，資訊量有點大，我來解釋一下，關于前面的知識我就不解釋了，

首先， Zuul 需要向 Eureka 進行注冊，注冊有啥好處呢？

你傻呀， Consumer 都向 Eureka Server 進行注冊了，我網關是不是只要注冊就能拿到所有 Consumer 的資訊了？

拿到資訊有什么好處呢？

我拿到資訊我是不是可以獲取所有的 Consumer 的元資料(名稱，ip，埠)？

拿到這些元資料有什么好處呢？拿到了我們是不是直接可以做路由映射？比如原來用戶呼叫 Consumer1 的介面 localhost:8001/studentInfo/update 這個請求，我們是不是可以這樣進行呼叫了呢？ localhost:9000/consumer1/studentInfo/update 呢？你這樣是不是恍然大悟了？

這里的url為了讓更多人看懂所以沒有使用 restful 風格，

上面的你理解了，那么就能理解關于 Zuul 最基本的配置了，看下面，

server: 
	port: 9000 
eureka: 
	client: 
		service-url: 
			# 這里只要注冊 Eureka 就行了 
			defaultZone: http://localhost:9997/eureka

然后在啟動類上加入 @EnableZuulProxy 注解就行了，沒錯，就是那么簡單，

2)統一前綴

這個很簡單，就是我們可以在前面加一個統一的前綴，比如我們剛剛呼叫的是
localhost:9000/consumer1/studentInfo/update ，這個時候我們在 yaml 組態檔中添加如下，

zuul: 
	prefix: /zuul

這樣我們就需要通過 localhost:9000/zuul/consumer1/studentInfo/update 來進行訪問了，

3)路由策略配置

你會發現前面的訪問方式(直接使用服務名)，需要將微服務名稱暴露給用戶，會存在安全性問題，所以，可以自定義路徑來替代微服務名稱，即自定義路由策略，

zuul: 
	routes: 
		consumer1: /FrancisQ1/** 
		consumer2: /FrancisQ2/**

這個時候你就可以使用 localhost:9000/zuul/FrancisQ1/studentInfo/update` 進行訪問了，

4)服務名屏蔽

這個時候你別以為你好了，你可以試試，在你配置完路由策略之后使用微服務名稱還是可以訪問的，這個時候你需要將服務名屏蔽，

zuul: 
	ignore-services: "*"

5)路徑屏蔽

Zuul 還可以指定屏蔽掉的路徑 URI，即只要用戶請求中包含指定的 URI 路徑，那么該請求將無法訪問到指定的服務，通過該方式可以限制用戶的權限，

zuul: 
	ignore-patterns: **/auto/**

這樣關于 auto 的請求我們就可以過濾掉了，

** 代表匹配多級任意路徑
*代表匹配一級任意路徑

6)敏感請求頭屏蔽

默認情況下，像 Cookie 、 Set-Cookie 等敏感請求頭資訊會被 zuul 屏蔽掉，我們可以將這些默認屏蔽去掉，當然，也可以添加要屏蔽的請求頭，

2.Zuul 的過濾功能

如果說，路由功能是 Zuul 的基操的話，那么 過濾器 就是 Zuul 的利器了，畢竟所有請求都經過網關 (Zuul)，那么我們可以進行各種過濾，這樣我們就能實作限流，灰度發布，權限控制 等等，

1)簡單實作一個請求時間日志列印

要實作自己定義的 Filter 我們只需要繼承 ZuulFilter 然后將這個過濾器類以 @Component 注解加入 Spring 容器中就行了，

在給你們看代碼之前我先給你們解釋一下關于過濾器的一些注意點，

過濾器型別： Pre 、 Routing 、 Post ，前置 Pre 就是在請求之前進行過濾， Routing 路由過濾器就是我們上面所講的路由策略，而 Post 后置過濾器就是在 Response 之前進行過濾的過濾器，你可以觀察上圖結合著理解，并且下面我會給出相應的注釋，

// 加入Spring容器 
@Component 
public class PreRequestFilter extends ZuulFilter { 
	// 回傳過濾器型別 這里是前置過濾器 
	@Override 
	public String filterType() { 
		return FilterConstants.PRE_TYPE; 
	}
	// 指定過濾順序 越小越先執行，這里第一個執行 
	// 當然不是只真正第一個 在Zuul內置中有其他過濾器會先執行 
	// 那是寫死的 比如 SERVLET_DETECTION_FILTER_ORDER = -3 
	@Override
	public int filterOrder() { 
		return 0; 
	}
	// 什么時候該進行過濾 
	// 這里我們可以進行一些判斷，這樣我們就可以過濾掉一些不符合規定的請求等等 
	@Override 
	public boolean shouldFilter() { 
		return true; 
	}
	// 如果過濾器允許通過則怎么進行處理 
	@Override 
	public Object run() throws ZuulException { 
		// 這里我設定了全域的RequestContext并記錄了請求開始時間 
		RequestContext ctx = RequestContext.getCurrentContext(); 
		ctx.set("startTime", System.currentTimeMillis()); 
		return null; 
	} 
}

// lombok的日志 
@Slf4j 
// 加入 Spring 容器 
@Component 
public class AccessLogFilter extends ZuulFilter { 
	// 指定該過濾器的過濾型別 
	// 此時是后置過濾器 
	@Override 
	public String filterType() { 
		return FilterConstants.POST_TYPE; 
	}
	// SEND_RESPONSE_FILTER_ORDER 是最后一個過濾器 
	// 我們此過濾器在它之前執行 
	@Override 
	public int filterOrder() { 
		return FilterConstants.SEND_RESPONSE_FILTER_ORDER - 1; 
	}
	@Override 
	public boolean shouldFilter() { 
		return true; 
	}
	// 過濾時執行的策略 
	@Override 
	public Object run() throws ZuulException { 
		RequestContext context = RequestContext.getCurrentContext(); 
		HttpServletRequest request = context.getRequest(); 
		// 從RequestContext獲取原先的開始時間 并通過它計算整個時間間隔 
		Long startTime = (Long) context.get("startTime"); 
		// 這里我可以獲取HttpServletRequest來獲取URI并且列印出來 
		String uri = request.getRequestURI(); 
		long duration = System.currentTimeMillis() - startTime; 
		log.info("uri: " + uri + ", duration: " + duration / 100 + "ms"); 
		return null; 
	} 
}

上面就簡單實作了請求時間日志列印功能，你有沒有感受到 Zuul 過濾功能的強大了呢？

沒有？好的、那我們再來，

2)令牌桶限流

當然不僅僅是令牌桶限流方式， Zuul 只要是限流的活它都能干，這里我只是簡單舉個栗子，

我先來解釋一下什么是 令牌桶限流 吧，

首先我們會有個桶，如果里面沒有滿那么就會以一定 固定的速率 會往里面放令牌，一個請求過來首先要從桶中獲取令牌，如果沒有獲取到，那么這個請求就拒絕，如果獲取到那么就放行，

下面我們就通過 Zuul 的前置過濾器來實作一下令牌桶限流，

package com.lgq.zuul.filter; 

import com.google.common.util.concurrent.RateLimiter; 
import com.netflix.zuul.ZuulFilter; 
import com.netflix.zuul.context.RequestContext; 
import com.netflix.zuul.exception.ZuulException; 
import lombok.extern.slf4j.Slf4j; 
import org.springframework.cloud.netflix.zuul.filters.support.FilterConstants; 
import org.springframework.stereotype.Component; 

@Component 
@Slf4j 
public class RouteFilter extends ZuulFilter { 
	// 定義一個令牌桶，每秒產生2個令牌，即每秒最多處理2個請求 
	private static final RateLimiter RATE_LIMITER = RateLimiter.create(2); 
	@Override 
	public String filterType() { 
		return FilterConstants.PRE_TYPE; 
	}
	@Override 
	public int filterOrder() { 
		return -5; 
	}

	@Override 
	public Object run() throws ZuulException { 
		log.info("放行"); 
		return null; 
	}
	
	@Override 
	public boolean shouldFilter() { 
		RequestContext context = RequestContext.getCurrentContext(); 
		if(!RATE_LIMITER.tryAcquire()) { 
			log.warn("訪問量超載"); 
			// 指定當前請求未通過過濾 
			context.setSendZuulResponse(false); 
			// 向客戶端回傳回應碼429，請求數量過多 
			context.setResponseStatusCode(429); 
			return false; 
		}
		return true; 
	} 
}

這樣我們就能將請求數量控制在一秒兩個，有沒有覺得很酷？

3.關于 Zuul 的其他

Zuul 的過濾器的功能肯定不止上面我所實作的兩種，它還可以實作 權限校驗，包括我上面提到的 灰度發布 等等，

當然， Zuul 作為網關肯定也存在 單點問題 ，如果我們要保證 Zuul 的高可用，我們就需要進行 Zuul 的集群配置，這個時候可以借助額外的一些負載均衡器比如 Nginx ，

##Spring Cloud配置管理——Config

4.為什么要使用進行配置管理？

當我們的微服務系統開始慢慢地龐大起來，那么多 Consumer 、 Provider 、 Eureka Server 、 Zuul 系統都會持有自己的配置，這個時候我們在專案運行的時候可能需要更改某些應用的配置，如果我們不進行配置的統一管理，我們只能去每個應用下一個一個尋找組態檔然后修改組態檔再重啟應用，

首先對于分布式系統而言我們就不應該去每個應用下去分別修改組態檔，再者對于重啟應用來說，服務無法訪問所以直接拋棄了可用性，這是我們更不愿見到的，

那么有沒有一種方法既能對組態檔統一地進行管理，又能在專案運行時動態修改組態檔呢？

那就是我今天所要介紹的 Spring Cloud Config ，

能進行配置管理的框架不止 Spring Cloud Config 一種，大家可以根據需求自己選擇（ disconf，阿波羅等等），而且對于 Config 來說有些地方實作的不是那么盡人意，

5.Config 是什么

Spring Cloud Config 為分布式系統中的外部化配置提供服務器和客戶端支持，使用 Config服務器，可以在中心位置管理所有環境中應用程式的外部屬性，

簡單來說， Spring Cloud Config 就是能將各個應用/系統/模塊的組態檔存放到 統一的地方然后進行管理(Git 或者 SVN)，

你想一下，我們的應用是不是只有啟動的時候才會進行組態檔的加載，那么我們的 Spring Cloud Config 就暴露出一個介面給啟動應用來獲取它所想要的組態檔，應用獲取到組態檔然后再進行它的初始化作業，就如下圖，

當然這里你肯定還會有一個疑問，如果我在應用運行時去更改遠程配置倉庫(Git)中的對應組態檔，那么依賴于這個組態檔的已啟動的應用會不會進行其相應配置的更改呢？

答案是不會的，

什么？那怎么進行動態修改組態檔呢？這不是出現了 配置漂移 嗎？你個渣男，你又騙我！

別急嘛，你可以使用 Webhooks ，這是 github 提供的功能，它能確保遠程庫的組態檔更新后客戶端中的配置資訊也得到更新，

噢噢，這還差不多，我去查查怎么用，

慢著，聽我說完， Webhooks 雖然能解決，但是你了解一下會發現它根本不適合用于生產環境，所以基本不會使用它的，

而一般我們會使用 Bus 訊息總線 + Spring Cloud Config 進行配置的動態重繪，

三、引出 Spring Cloud Bus

用于將服務和服務實體與分布式訊息系統鏈接在一起的事件總線，在集群中傳播狀態更改很有用（例如配置更改事件），

你可以簡單理解為 Spring Cloud Bus 的作用就是管理和廣播分布式系統中的訊息，也就是訊息引擎系統中的廣播模式，當然作為 訊息總線 的 Spring Cloud Bus 可以做很多事而不僅僅是客戶端的配置重繪功能，

而擁有了 Spring Cloud Bus 之后，我們只需要創建一個簡單的請求，并且加上 @ResfreshScope 注解就能進行配置的動態修改了，下面我畫了張圖供你理解，

四、總結

這兩篇文章中我帶大家初步了解了 Spring Cloud 的各個組件，他們有

Eureka 服務發現框架
Ribbon 行程內負載均衡器
Open Feign 服務呼叫映射
Hystrix 服務降級熔斷器
Zuul 微服務網關
Config 微服務統一配置中心
Bus 訊息總線

如果你能這個時候能看懂文首那張圖，也就說明了你已經對 Spring Cloud 微服務有了一定的架構認識，

參考資料：《Java中高級核心知識全面決議》限量100份，有一些人已經通過我之前的文章獲取了哦！
名額有限先到先得！！！還有更多Java Pdf學習資料等你來拿！！！
有想要獲取這份學習資料的同學可以點擊這里免費獲取》》》》》》》

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/247645.html

標籤：其他

上一篇：課程設計-三層架構ASP.NET作品分享網站（sql server資料庫）

下一篇：SpringBoot小白第一天第二章(SpringBoot優缺點和運行springboot的三種方式)

Java中高級核心知識全面決議——什么是Spring Cloud、需要掌握哪些知識點？（下）

目錄