當前位置：首頁 > news >正文

網站開發(fā) 保修期網絡推廣文案怎么寫

news 2025/7/3 12:45:13

網站開發(fā) 保修期,網絡推廣文案怎么寫,怎么做網站301重定向,網頁設計與制作的實訓報告雪崩問題微服務中，服務間調用關系錯綜復雜，一個微服務往往依賴于多個其它微服務。微服務之間相互調用，因為調用鏈中的一個服務故障，引起整個鏈路都無法訪問的情況。如果服務提供者A發(fā)生了故障，當前的應用的部分業(yè)務…

雪崩問題

微服務中，服務間調用關系錯綜復雜，一個微服務往往依賴于多個其它微服務。

微服務之間相互調用，因為調用鏈中的一個服務故障，引起整個鏈路都無法訪問的情況。

如果服務提供者A發(fā)生了故障，當前的應用的部分業(yè)務因為依賴于服務A，因此也會被阻塞。此時，其它不依賴于服務A的業(yè)務似乎不受影響。但是，依賴服務A的業(yè)務請求被阻塞，用戶不會得到響應，則tomcat的這個線程不會釋放，于是越來越多的用戶請求到來，越來越多的線程會阻塞；服務器支持的線程和并發(fā)數(shù)有限，請求一直阻塞，會導致服務器資源耗盡，從而導致所有其它服務都不可用，那么當前服務也就不可用了。那么，依賴于當前服務的其它服務隨著時間的推移，最終也都會變的不可用，形成級聯(lián)失敗，雪崩就發(fā)生了。

解決雪崩問題的常見方式

解決雪崩問題的常見方式有四種：

超時處理：設定超時時間，請求超過一定時間沒有響應就返回錯誤信息，不會無休止等待。

倉壁模式：倉壁模式來源于船艙的設計：船艙都會被隔板分離為多個獨立空間，當船體破損時，只會導致部分空間進入，將故障控制在一定范圍內，避免整個船體都被淹沒。可以限定每個業(yè)務能使用的線程數(shù)，避免耗盡整個tomcat的資源，因此也叫線程隔離。

斷路器模式：由斷路器統(tǒng)計業(yè)務執(zhí)行的異常比例，如果超出閾值則會熔斷該業(yè)務，攔截訪問該業(yè)務的一切請求。斷路器會統(tǒng)計訪問某個服務的請求數(shù)量，異常比例。當發(fā)現(xiàn)訪問服務B的請求異常比例過高時，認為服務B有導致雪崩的風險，會攔截訪問服務B的一切請求，形成熔斷。

流量控制：限制業(yè)務訪問的QPS，避免服務因流量的突增而故障。

限流是對服務的保護，避免因瞬間高并發(fā)流量而導致服務故障，進而避免雪崩。是一種預防措施。

超時處理、線程隔離、降級熔斷是在部分服務故障時，將故障控制在一定范圍，避免雪崩。是一種補救措施。

Sentinel介紹和安裝

Sentinel是阿里巴巴開源的一款微服務流量控制組件。官網地址：home | Sentinel?

Sentinel 具有以下特征:豐富的應用場景、完備的實時監(jiān)控、廣泛的開源生態(tài)、完善的 SPI 擴展點

安裝Sentinel

entinel官方提供了UI控制臺，方便我們對系統(tǒng)做限流設置。大家可以在GitHub下載。

將jar包放到任意非中文目錄，執(zhí)行命令：

java -jar sentinel-dashboard-1.8.1.jar

修改Sentinel的默認端口、賬戶、密碼，可以通過下列配置：

配置項	默認值	說明
server.port	8080	服務端口
sentinel.dashboard.auth.username	sentinel	默認用戶名
sentinel.dashboard.auth.password	sentinel	默認密碼

微服務整合Sentinel

引入sentinel依賴?

<dependency><groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>

配置控制臺

server:port: 8088
spring:cloud: sentinel:transport:dashboard: localhost:8080

訪問service的任意端點

打開瀏覽器，訪問對應的服務的地址http://localhost:8088/order/101，這樣才能觸發(fā)sentinel的監(jiān)控。

流量控制

限流是避免服務因突發(fā)的流量而發(fā)生故障，是對微服務雪崩問題的預防。

簇點鏈路

當請求進入微服務時，首先會訪問DispatcherServlet，然后進入Controller、Service、Mapper，這樣的一個調用鏈就叫做簇點鏈路。簇點鏈路中被監(jiān)控的每一個接口就是一個資源。

默認情況下sentinel會監(jiān)控SpringMVC的每一個端點（Endpoint，也就是controller中的方法），因此SpringMVC的每一個端點（Endpoint）就是調用鏈路中的一個資源。

流控、熔斷等都是針對簇點鏈路中的資源來設置的，因此我們可以點擊對應資源后面的按鈕來設置規(guī)則：

流控：流量控制

降級：降級熔斷

熱點：熱點參數(shù)限流，是限流的一種

授權：請求的權限控制

直接模式：可在流控按鈕，填寫限流規(guī)則

關聯(lián)模式

關聯(lián)模式：統(tǒng)計與當前資源相關的另一個資源，觸發(fā)閾值時，對當前資源限流

當/write資源訪問量觸發(fā)閾值時，就會對/read資源限流，避免影響/write資源。?

比如用戶支付時需要修改訂單狀態(tài)，同時用戶要查詢訂單。查詢和修改操作會爭搶數(shù)據庫鎖，產生競爭。業(yè)務需求是優(yōu)先支付和更新訂單的業(yè)務，因此當修改訂單業(yè)務觸發(fā)閾值時，需要對查詢訂單業(yè)務限流。?

滿足下面條件可以使用關聯(lián)模式

????????兩個有競爭關系的資源

????????一個優(yōu)先級高，一個優(yōu)先級低的資源

鏈路模式?

鏈路模式：只針對從指定鏈路訪問到本資源的請求做統(tǒng)計，判斷是否超過閾值。

有兩條請求鏈路：

/test1 --> /common

/test2 --> /common

如果只希望統(tǒng)計從/test2進入到/common的請求，則可以這樣配置。

給service添加資源標記

默認情況下，Service中的方法是不被Sentinel監(jiān)控的，需要我們自己通過注解來標記要監(jiān)控的方法。

給Service的queryGoods方法添加@SentinelResource注解：

@SentinelResource("goods")
public void queryGoods(){System.err.println("查詢商品");
}

鏈路模式中，是對不同來源的兩個鏈路做監(jiān)控。但是sentinel默認會給進入SpringMVC的所有請求設置同一個root資源，會導致鏈路模式失效。

我們需要關閉這種對SpringMVC的資源聚合，修改service服務的application.yml文件：

spring:cloud:sentinel:web-context-unify: false # 關閉context整合

?重啟服務，可以查看到sentinel的簇點鏈路規(guī)則中，出現(xiàn)了新的資源。

添加流控規(guī)則，測試即可。

總結

?直接：對當前資源限流

?關聯(lián)：高優(yōu)先級資源觸發(fā)閾值，對低優(yōu)先級資源限流。

?鏈路：閾值統(tǒng)計時，只統(tǒng)計從指定資源進入當前資源的請求，是對請求來源的限流

流控效果

流控效果是指請求達到流控閾值時應該采取的措施，包括三種：

快速失敗：達到閾值后，新的請求會被立即拒絕并拋出FlowException異常。是默認的處理方式。
warm up：預熱模式，對超出閾值的請求同樣是拒絕并拋出異常。但這種模式閾值會動態(tài)變化，從一個較小值逐漸增加到最大閾值。
排隊等待：讓所有的請求按照先后次序排隊執(zhí)行，兩個請求的間隔不能小于指定時長

warm up

閾值一般是一個微服務能承擔的最大QPS，但是一個服務剛剛啟動時，一切資源尚未初始化（冷啟動），如果直接將QPS跑到最大值，可能導致服務瞬間宕機。

warm up也叫預熱模式，是應對服務冷啟動的一種方案。請求閾值初始值是 maxThreshold / coldFactor，持續(xù)指定時長后，逐漸提高到maxThreshold值。而coldFactor的默認值是3.

排隊等待

當請求超過QPS閾值時，快速失敗和warm up 會拒絕新的請求并拋出異常。而排隊等待則是讓所有請求進入一個隊列中，然后按照閾值允許的時間間隔依次執(zhí)行。后來的請求必須等待前面執(zhí)行完成，如果請求預期的等待時間超出最大時長，則會被拒絕。?

原理：

例如：QPS = 5，意味著每200ms處理一個隊列中的請求；timeout = 2000，意味著預期等待時長超過2000ms的請求會被拒絕并拋出異常。

比如現(xiàn)在一下子來了12 個請求，因為每200ms執(zhí)行一個請求，那么：

第6個請求的預期等待時長 = 200 * （6 - 1） = 1000ms
第12個請求的預期等待時長 = 200 * （12-1） = 2200ms

現(xiàn)在，第1秒同時接收到10個請求，但第2秒只有1個請求，此時QPS的曲線這樣的：

如果使用隊列模式做流控，所有進入的請求都要排隊，以固定的200ms的間隔執(zhí)行，QPS會變的很平滑：?

平滑的QPS曲線，對于服務器來說是更友好的。

總結?

快速失敗：QPS超過閾值時，拒絕新的請求

warm up： QPS超過閾值時，拒絕新的請求；QPS閾值是逐漸提升的，可以避免冷啟動時高并發(fā)導致服務宕機。

排隊等待：請求會進入隊列，按照閾值允許的時間間隔依次執(zhí)行請求；如果請求預期等待時長大于超時時間，直接拒絕

熱點參數(shù)限流

之前的限流是統(tǒng)計訪問某個資源的所有請求，判斷是否超過QPS閾值。而熱點參數(shù)限流是分別統(tǒng)計參數(shù)值相同的請求，判斷是否超過QPS閾值。

全局參數(shù)限流

代表的含義是：對hot這個資源的0號參數(shù)（第一個參數(shù)）做統(tǒng)計，每1秒相同參數(shù)值的請求數(shù)不能超過5?

熱點參數(shù)限流

剛才的配置中，對查詢商品這個接口的所有商品一視同仁，QPS都限定為5.

而在實際開發(fā)中，可能部分商品是熱點商品，例如秒殺商品，我們希望這部分商品的QPS限制與其它商品不一樣，高一些。那就需要配置熱點參數(shù)限流的高級選項了：

結合上一個配置，這里的含義是對0號的long類型參數(shù)限流，每1秒相同參數(shù)的QPS不能超過5，有兩個例外：

?如果參數(shù)值是100，則每1秒允許的QPS為10

?如果參數(shù)值是101，則每1秒允許的QPS為15

注意事項：熱點參數(shù)限流對默認的SpringMVC資源無效，需要利用@SentinelResource注解標記資源?

隔離和降級

限流是一種預防措施，雖然限流可以盡量避免因高并發(fā)而引起的服務故障，但服務還會因為其它原因而故障。

而要將這些故障控制在一定范圍，避免雪崩，就要靠線程隔離（艙壁模式）和熔斷降級手段了。

線程隔離：調用者在調用服務提供者時，給每個調用的請求分配獨立線程池，出現(xiàn)故障時，最多消耗這個線程池內資源，避免把調用者的所有資源耗盡。

熔斷降級：是在調用方這邊加入斷路器，統(tǒng)計對服務提供者的調用，如果調用的失敗比例過高，則熔斷該業(yè)務，不允許訪問該服務的提供者了。

不管是線程隔離還是熔斷降級，都是對客戶端（調用方）的保護。需要在調用方 發(fā)起遠程調用時做線程隔離、或者服務熔斷。

而我們的微服務遠程調用都是基于Feign來完成的，因此我們需要將Feign與Sentinel整合，在Feign里面實現(xiàn)線程隔離和服務熔斷。

FeignClient整合Sentinel

SpringCloud中，微服務調用都是通過Feign來實現(xiàn)的，因此做客戶端保護必須整合Feign和Sentinel。

修改配置，開啟sentinel功能?

修改Service的application.yml文件，開啟Feign的Sentinel功能：

feign:sentinel:enabled: true # 開啟feign對sentinel的支持

編寫失敗降級邏輯

業(yè)務失敗后，不能直接報錯，而應該返回用戶一個友好提示或者默認結果，這個就是失敗降級邏輯。

給FeignClient編寫失敗后的降級邏輯

①方式一：FallbackClass，無法對遠程調用的異常做處理

②方式二：FallbackFactory，可以對遠程調用的異常做處理，我們選擇這種

步驟一：在feing-api項目中定義類，實現(xiàn)FallbackFactory：

public class UserClientFallbackFactory implements FallbackFactory<UserClient> {@Overridepublic UserClient create(Throwable throwable) {return new UserClient() {@Overridepublic User findById(Long id) {log.error("查詢用戶異常", throwable);return new User();}};}
}

步驟二：在feing-api項目中的DefaultFeignConfiguration類中將UserClientFallbackFactory注冊為一個Bean：

@Bean
public UserClientFallbackFactory userClientFallbackFactory(){return new UserClientFallbackFactory();
}

步驟三：在feing-api項目中的UserClient接口中使用UserClientFallbackFactory：

@FeignClient(value = "userservice", fallbackFactory = UserClientFallbackFactory.class)
public interface UserClient {@GetMapping("/user/{id}")User findById(@PathVariable("id") Long id);
}

總結

Sentinel支持的雪崩解決方案：

線程隔離（倉壁模式）

降級熔斷

Feign整合Sentinel的步驟：

在application.yml中配置：feign.sentienl.enable=true

給FeignClient編寫FallbackFactory并注冊為Bean

將FallbackFactory配置到FeignClient

線程隔離（艙壁模式）?

線程隔離有兩種方式實現(xiàn)：

線程池隔離
信號量隔離（Sentinel默認采用）

線程池隔離：給每個服務調用業(yè)務分配一個線程池，利用線程池本身實現(xiàn)隔離效果

信號量隔離：不創(chuàng)建線程池，而是計數(shù)器模式，記錄業(yè)務使用的線程數(shù)量，達到信號量上限時，禁止新的請求。

兩者的優(yōu)缺點：

sentinel的線程隔離?

在添加限流規(guī)則時，可以選擇兩種閾值類型：

QPS：就是每秒的請求數(shù)，在快速入門中已經演示過
線程數(shù)：是該資源能使用用的tomcat線程數(shù)的最大值。也就是通過限制線程數(shù)量，實現(xiàn)線程隔離（艙壁模式）

總結

線程隔離的兩種手段是？

信號量隔離

線程池隔離

信號量隔離的特點是？

基于計數(shù)器模式，簡單，開銷小

線程池隔離的特點是？

基于線程池模式，有額外開銷，但隔離控制更強

?熔斷降級

熔斷降級是解決雪崩問題的重要手段。其思路是由斷路器統(tǒng)計服務調用的異常比例、慢請求比例，如果超出閾值則會熔斷該服務。即攔截訪問該服務的一切請求；而當服務恢復時，斷路器會放行訪問該服務的請求。

斷路器控制熔斷和放行是通過狀態(tài)機來完成的：

狀態(tài)機包括三個狀態(tài)：

closed：關閉狀態(tài)，斷路器放行所有請求，并開始統(tǒng)計異常比例、慢請求比例。超過閾值則切換到open狀態(tài)
open：打開狀態(tài)，服務調用被熔斷，訪問被熔斷服務的請求會被拒絕，快速失敗，直接走降級邏輯。Open狀態(tài)5秒后會進入half-open狀態(tài)
half-open：半開狀態(tài)，放行一次請求，根據執(zhí)行結果來判斷接下來的操作。
- 請求成功：則切換到closed狀態(tài)
- 請求失敗：則切換到open狀態(tài)

斷路器熔斷策略有三種：慢調用、異常比例、異常數(shù)

慢調用

慢調用：業(yè)務的響應時長（RT）大于指定時長的請求認定為慢調用請求。在指定時間內，如果請求數(shù)量超過設定的最小數(shù)量，慢調用比例大于設定的閾值，則觸發(fā)熔斷。

?RT超過500ms的調用是慢調用，統(tǒng)計最近10000ms內的請求，如果請求量超過10次，并且慢調用比例不低于0.5，則觸發(fā)熔斷，熔斷時長為5秒。然后進入half-open狀態(tài)，放行一次請求做測試。

異常比例、異常數(shù)?

異常比例或異常數(shù)：統(tǒng)計指定時間內的調用，如果調用次數(shù)超過指定請求數(shù)，并且出現(xiàn)異常的比例達到設定的比例閾值（或超過指定異常數(shù)），則觸發(fā)熔斷。

統(tǒng)計最近1000ms內的請求，如果請求量超過10次，并且異常比例不低于0.4，則觸發(fā)熔斷。?

?

統(tǒng)計最近1000ms內的請求，如果請求量超過10次，并且異常比例不低于2次，則觸發(fā)熔斷。?

授權規(guī)則

授權規(guī)則可以對調用方的來源做控制，有白名單和黑名單兩種方式。

白名單：來源（origin）在白名單內的調用者允許訪問
黑名單：來源（origin）在黑名單內的調用者不允許訪問

點擊左側菜單的授權，可以看到授權規(guī)則：

資源名：就是受保護的資源，例如/order/{orderId}
流控應用：是來源者的名單，
- 如果是勾選白名單，則名單中的來源被許可訪問。
- 如果是勾選黑名單，則名單中的來源被禁止訪問。

我們允許請求從gateway到order-service，不允許瀏覽器訪問order-service，那么白名單中就要填寫網關的來源名稱（origin）。

獲取origin

Sentinel是通過RequestOriginParser這個接口的parseOrigin來獲取請求的來源的。

public interface RequestOriginParser {/*** 從請求request對象中獲取origin，獲取方式自定義*/String parseOrigin(HttpServletRequest request);
}

這個方法的作用就是從request對象中，獲取請求者的origin值并返回。

默認情況下，sentinel不管請求者從哪里來，返回值永遠是default，也就是說一切請求的來源都被認為是一樣的值default。

因此，我們需要自定義這個接口的實現(xiàn)，讓不同的請求，返回不同的origin。

@Component
public class HeaderOriginParser implements RequestOriginParser {@Overridepublic String parseOrigin(HttpServletRequest request) {// 1.獲取請求頭String origin = request.getHeader("origin");// 2.非空判斷if (StringUtils.isEmpty(origin)) {origin = "blank";}return origin;}
}

給網關添加請求頭

獲取請求origin的方式是從reques-header中獲取origin值，我們必須讓所有從gateway路由到微服務的請求都帶上origin頭。這個需要利用GatewayFilter來實現(xiàn)AddRequestHeaderGatewayFilter。修改gateway服務中的application.yml，添加一個defaultFilter：

spring:cloud:gateway:default-filters:- AddRequestHeader=origin,gatewayroutes:

這樣，從gateway路由的所有請求都會帶上origin頭，值為gateway。而從其它地方到達微服務的請求則沒有這個頭。

配置授權規(guī)則

添加一個授權規(guī)則，放行origin值為gateway的請求。

自定義異常結果

默認情況下，發(fā)生限流、降級、授權攔截時，都會拋出異常到調用方。異常結果都是flow limmiting（限流）。這樣不夠友好，無法得知是限流還是降級還是授權攔截。

異常類型

而如果要自定義異常時的返回結果，需要實現(xiàn)BlockExceptionHandler接口：

public interface BlockExceptionHandler {/*** 處理請求被限流、降級、授權攔截時拋出的異常：BlockException*/void handle(HttpServletRequest request, HttpServletResponse response, BlockException e) throws Exception;
}

這個方法有三個參數(shù)：

HttpServletRequest request：request對象

HttpServletResponse response：response對象

BlockException e：被sentinel攔截時拋出的異常

BlockException包含多個不同的子類：

異常	說明
FlowException	限流異常
ParamFlowException	熱點參數(shù)限流的異常
DegradeException	降級異常
AuthorityException	授權規(guī)則異常
SystemBlockException	系統(tǒng)規(guī)則異常

自定義異常處理?

@Component
public class SentinelExceptionHandler implements BlockExceptionHandler {@Overridepublic void handle(HttpServletRequest request, HttpServletResponse response, BlockException e) throws Exception {String msg = "未知異常";int status = 429;if (e instanceof FlowException) {msg = "請求被限流了";} else if (e instanceof ParamFlowException) {msg = "請求被熱點參數(shù)限流";} else if (e instanceof DegradeException) {msg = "請求被降級了";} else if (e instanceof AuthorityException) {msg = "沒有權限訪問";status = 401;}response.setContentType("application/json;charset=utf-8");response.setStatus(status);response.getWriter().println("{\"msg\": " + msg + ", \"status\": " + status + "}");}
}