了解spring中的CloudNetflix Hystrix彈性客戶端
一、為什么要有客戶端彈性模式
所有的系統(tǒng)都會(huì)遇到故障,分布式系統(tǒng)單點(diǎn)故障概率更高。如何構(gòu)建應(yīng)用程序來(lái)應(yīng)對(duì)故障,是每個(gè)軟件開(kāi)發(fā)人員工作的關(guān)鍵部分。但是通常在構(gòu)建系統(tǒng)時(shí),大多數(shù)工程師只考慮到基礎(chǔ)設(shè)施或關(guān)鍵服務(wù)徹底發(fā)生故障,使用諸如集群關(guān)鍵服務(wù)器、服務(wù)間的負(fù)載均衡以及異地部署等技術(shù)。盡管這些方法考慮到組件系統(tǒng)的徹底故障,但他們之解決了構(gòu)建彈性系統(tǒng)的一小部分問(wèn)題。當(dāng)服務(wù)崩潰時(shí),很容易檢測(cè)到該服務(wù)以及失效,因此應(yīng)用程序可以饒過(guò)它。然而,當(dāng)服務(wù)運(yùn)行緩慢時(shí),檢測(cè)到這個(gè)服務(wù)性能越發(fā)低下并繞過(guò)它是非常困難的,因?yàn)橐韵聨讉€(gè)原因:
- 服務(wù)的降級(jí)可以是以間歇性的故障開(kāi)始,并形成不可逆轉(zhuǎn)的勢(shì)頭————可能開(kāi)始只是一小部分服務(wù)調(diào)用變慢,直到突然間應(yīng)用程序容器耗盡了線程(所有線程都在等待調(diào)用完成)并徹底崩潰。
- 應(yīng)用程序通常的設(shè)計(jì)是處理遠(yuǎn)程資源的徹底故障,而不是部分降級(jí)————通常,只要服務(wù)沒(méi)有完全死掉,應(yīng)用程序?qū)⒗^續(xù)調(diào)用這個(gè)服務(wù),直到資源耗盡崩潰。
性能較差的遠(yuǎn)程服務(wù)會(huì)導(dǎo)致很大的潛在問(wèn)題,它們不僅難以檢測(cè),還會(huì)觸發(fā)連鎖反應(yīng),從而影響整個(gè)應(yīng)用程序生態(tài)系統(tǒng)。如果沒(méi)有適當(dāng)?shù)谋Wo(hù)措施,一個(gè)性能不佳的服務(wù)可以迅速拖垮整個(gè)應(yīng)用程序?;谠啤⒒谖⒎?wù)的應(yīng)用程序特別容易受到這些類(lèi)型的終端影響,因?yàn)檫@些應(yīng)用由大量細(xì)粒度的分布式服務(wù)組成,這些服務(wù)在完成用戶的事務(wù)時(shí)涉及不同的基礎(chǔ)設(shè)施。
二、什么是客戶端彈性模式
客戶端彈性模式是在遠(yuǎn)程服務(wù)發(fā)生錯(cuò)誤或表現(xiàn)不佳時(shí)保護(hù)遠(yuǎn)程資源(另一個(gè)微服務(wù)調(diào)用或者數(shù)據(jù)庫(kù)查詢(xún))免于崩潰。這些模式的目標(biāo)是為了能讓客戶端“快速失敗”,不消耗諸如數(shù)據(jù)庫(kù)連接、線程池之類(lèi)的資源,還可以避免遠(yuǎn)程服務(wù)的問(wèn)題向客戶端的消費(fèi)者進(jìn)行傳播,引發(fā)“雪崩”效應(yīng)。spring cloud 主要使用的有四種客戶端彈性模式:
客戶端負(fù)載均衡(client load balance)模式
斷路器(circuit breaker)模式
本模式模仿的是電路中的斷路器。有了軟件斷路器,當(dāng)遠(yuǎn)程服務(wù)被調(diào)用時(shí),斷路器將監(jiān)視這個(gè)調(diào)用,如果調(diào)用時(shí)間太長(zhǎng),斷路器將介入并中斷調(diào)用。此外,如果對(duì)某個(gè)遠(yuǎn)程資源的調(diào)用失敗次數(shù)達(dá)到某個(gè)閾值,將會(huì)采取快速失敗策略,阻止將來(lái)調(diào)用失敗的遠(yuǎn)程資源。
后備(fallback)模式
當(dāng)遠(yuǎn)程調(diào)用失敗時(shí),將執(zhí)行替代代碼路徑,并嘗試通過(guò)其他方式來(lái)處理操作,而不是產(chǎn)生一個(gè)異常。也就是為遠(yuǎn)程操作提供一個(gè)應(yīng)急措施,而不是簡(jiǎn)單的拋出異常。
艙壁(bulkhead)模式
艙壁模式是建立在造船的基礎(chǔ)概念上。我們都知道一艘船會(huì)被劃分為多個(gè)水密艙(艙壁),因而即使少數(shù)幾個(gè)部位被擊穿漏水,整艘船并不會(huì)被淹沒(méi)。將這個(gè)概念帶入到遠(yuǎn)程調(diào)用中,如果所有調(diào)用都使用的是同一個(gè)線程池來(lái)處理,那么很有可能一個(gè)緩慢的遠(yuǎn)程調(diào)用會(huì)拖垮整個(gè)應(yīng)用程序。在艙壁模式中可以隔離每個(gè)遠(yuǎn)程資源,并分配各自的線程池,使之互不影響。
下圖展示了這些模式是如何運(yùn)用到微服務(wù)中的:
三、spring cloud 中使用
使用 Netflix 的 Hystrix 庫(kù)來(lái)實(shí)現(xiàn)上述彈性模式。繼續(xù)使用上一節(jié)的項(xiàng)目,給 licensingservice 服務(wù)實(shí)現(xiàn)彈性模式。
1、代碼修改
依賴(lài)引入
首先修改 POM 文件,添加下面兩個(gè)依賴(lài):
<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-hystrix</artifactId> </dependency> <!--本依賴(lài)不是必須的,spring-cloud-starter-hystrix已經(jīng)帶了,但是在Camden.SR5發(fā)行版本中使用了1.5.6,這個(gè)版本有一個(gè)不一致的地方,在沒(méi)有后備的情況下會(huì)拋出java.lang.reflect.UndeclaredThrowableException而不是com.netflix.hystrix.exception.HystrixRuntimeException, 在后續(xù)版本中修復(fù)了這個(gè)問(wèn)題--> <dependency> <groupId>com.netflix.hystrix</groupId> <artifactId>hystrix-javanica</artifactId> <version>1.5.9</version> </dependency>
然后在啟動(dòng)類(lèi)上加入@EnableCircuitBreaker啟用 Hystrix。
2、實(shí)現(xiàn)斷路器
首先修改 organizationservice 項(xiàng)目中的 OrganizationController,模擬延遲,每隔兩次讓線程 sleep 2 秒
@RestController public class OrganizationController { private static int count=1; @GetMapping(value = "/organization/{orgId}") public Object getOrganizationInfo(@PathVariable("orgId") String orgId) throws Exception{ if(count%2==0){ TimeUnit.SECONDS.sleep(2); } count++; Map<String, String> data = new HashMap<>(2); data.put("id", orgId); data.put("name", orgId + "公司"); return data; } }
只需在方法上添加@HystrixCommand,即可實(shí)現(xiàn)超時(shí)短路。如果 Spring 掃描到該注解注釋的類(lèi),它將動(dòng)態(tài)生成一個(gè)代理,來(lái)包裝這個(gè)方法,并通過(guò)專(zhuān)門(mén)用于處理遠(yuǎn)程調(diào)用的線程池來(lái)管理對(duì)該方法的所有調(diào)用。
修改 licensingservice 服務(wù)中的 OrganizationByRibbonService,OrganizationFeignClient,給其中的方法加上@HystrixCommand的注解。
然后再訪問(wèn)接口localhost:10011/licensingByRibbon/11313,localhost:10011/licensingByFeign/11313。多次訪問(wèn)可發(fā)現(xiàn)拋出錯(cuò)誤com.netflix.hystrix.exception.HystrixRuntimeException,斷路器生效,默認(rèn)情況下操時(shí)時(shí)間為 1s。
{ "timestamp": 1543823192424, "status": 500, "error": "Internal Server Error", "exception": "com.netflix.hystrix.exception.HystrixRuntimeException", "message": "OrganizationFeignClient#getOrganization(String) timed-out and no fallback available.", "path": "/licensingByFeign/11313/" }
可通過(guò)設(shè)置注解參數(shù)來(lái)修改操時(shí)時(shí)間。設(shè)置超時(shí)時(shí)間大于 2s 后便不會(huì)報(bào)操時(shí)錯(cuò)誤。(不知道為什么在 Feign 中設(shè)置失敗,ribbon 中正常。)。一般都是將配置寫(xiě)在配置文件中。
@HystrixCommand(commandProperties = { @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "20000") })
3、后備處理
由于遠(yuǎn)程資源的消費(fèi)者和資源本身之間存在存在一個(gè)"中間人",因此開(kāi)發(fā)人員能夠攔截服務(wù)故障,并選擇替代方案。在 Hystrix 中進(jìn)行后備處理,非常容易實(shí)現(xiàn)。
1.在ribbon 中的實(shí)現(xiàn)
只需在@HystrixCommand注解中加入屬性 fallbackMethod="methodName",那么在執(zhí)行失敗時(shí),便會(huì)執(zhí)行后備方法。注意防備方法必須和被保護(hù)方法在同一個(gè)類(lèi)中,并且方法簽名必須相同。修改 licensingservice 中 service 包下的 OrganizationByRibbonService 類(lèi),改為如下:
@Component public class OrganizationByRibbonService { private RestTemplate restTemplate; @Autowired public OrganizationByRibbonService(RestTemplate restTemplate) { this.restTemplate = restTemplate; } @HystrixCommand(commandProperties = { @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "1000") },fallbackMethod = "getOrganizationWithRibbonBackup") public Organization getOrganizationWithRibbon(String id) throws Exception { ResponseEntity<Organization> responseEntity = restTemplate.exchange("http://organizationservice/organization/{id}", HttpMethod.GET, null, Organization.class, id); return responseEntity.getBody(); } public Organization getOrganizationWithRibbonBackup(String id)throws Exception{ Organization organization = new Organization(); organization.setId("0"); organization.setName("組織服務(wù)調(diào)用失敗"); return organization; } }
啟動(dòng)應(yīng)用,多次訪問(wèn)localhost:10011/licensingByRibbon/11313/,可以發(fā)現(xiàn)調(diào)用失敗時(shí),會(huì)啟用后備方法。
2.在feign 中實(shí)現(xiàn)
在 feign 中實(shí)現(xiàn)后備模式,需要編寫(xiě)一個(gè) feign 接口的實(shí)現(xiàn)類(lèi),然后在 feign 接口中指定該類(lèi)。以 licensingservice 為例。首先在 client 包中添加一個(gè) OrganizationFeignClientImpl 類(lèi),代碼如下:
@Component public class OrganizationFeignClientImpl implements OrganizationFeignClient{ @Override public Organization getOrganization(String orgId) { Organization organization=new Organization(); organization.setId("0"); organization.setName("后備模式返回的數(shù)據(jù)"); return organization; } }
然后修改 OrganizationFeignClient 接口的注解,將@FeignClient("organizationservice")改為@FeignClient(name="organizationservice",fallback = OrganizationFeignClientImpl.class。
重啟項(xiàng)目,多次訪問(wèn)localhost:10011/licensingByFeign/11313/,可發(fā)現(xiàn)后備服務(wù)起作用了。
在確認(rèn)是否要啟用后備服務(wù)時(shí),要注意以下兩點(diǎn):
- 后備是一種在資源操時(shí)或失敗時(shí)提供行動(dòng)方案的機(jī)制。如果只是用后備來(lái)捕獲操時(shí)異常然后只做日志記錄,那只需要 try..catch 即可,捕獲 HystrixRuntimeException 異常。
- 注意后備方法所執(zhí)行的操作。如果在后備服務(wù)中調(diào)用另一個(gè)分布式服務(wù),需要注意用@HystrixCommand 方法注解包裝后備方法。
4、實(shí)現(xiàn)艙壁模式
在基于微服務(wù)的應(yīng)用程序中,通常需要調(diào)用多個(gè)微服務(wù)來(lái)完成特定的任務(wù),在不適用艙壁的模式下,這些調(diào)用默認(rèn)是使用同一批線程來(lái)執(zhí)行調(diào)用的,而這些線程是為了處理整個(gè) Java 容器的請(qǐng)求而預(yù)留的。因此在存在大量請(qǐng)求的情況下,一個(gè)服務(wù)出現(xiàn)性能問(wèn)題會(huì)導(dǎo)致 Java 容器內(nèi)的所有線程被占用,同時(shí)阻塞新請(qǐng)求,最終容器徹底崩潰。
Hystrix 使用線程池來(lái)委派所有對(duì)遠(yuǎn)程服務(wù)的調(diào)用,默認(rèn)情況下這個(gè)線程池有 10 個(gè)工作線程。但是這樣很容易出現(xiàn)一個(gè)運(yùn)行緩慢的服務(wù)占用全部的線程,所有 hystrix 提供了一種一種易于使用的機(jī)制,在不同的遠(yuǎn)程資源調(diào)用間創(chuàng)建‘艙壁',將不同服務(wù)的調(diào)用隔離到不同的線程池中,使之互不影響。
要實(shí)現(xiàn)隔離的線程池,只需要在@HystrixCommand上加入線程池的注解,這里以 ribbon 為例(Feign 類(lèi)似)。修改 licensingservice 中 service 包下的 OrganizaitonByRibbonService 類(lèi),將getOrganizationWithRibbon方法的注解改為如下:
@HystrixCommand(commandProperties = { @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "1000") }, fallbackMethod = "getOrganizationWithRibbonBackup", threadPoolKey = "licenseByOrgThreadPool", threadPoolProperties = { @HystrixProperty(name = "coreSize", value = "30"), @HystrixProperty(name = "maxQueueSize", value = "10") })
如果將maxQueueSize屬性值設(shè)為-1,將使用SynchronousQueue保存所有的傳入請(qǐng)求,同步隊(duì)列會(huì)強(qiáng)制要求正在處理中的請(qǐng)求數(shù)量永遠(yuǎn)不能超過(guò)線程池的大小。設(shè)為大于 1 的值將使用LinkedBlockingQueue。
注意:示例代碼中都是硬編碼屬性值到 Hystrix 注解中的。在實(shí)際應(yīng)用環(huán)境中,一般都是將配置項(xiàng)配置在 Spring Cloud Config 中的,方便統(tǒng)一管理。
本次用到全部代碼:點(diǎn)擊跳轉(zhuǎn)
以上就是本文的全部?jī)?nèi)容,希望對(duì)大家的學(xué)習(xí)有所幫助,也希望大家多多支持腳本之家。
- SpringCloud客戶端的負(fù)載均衡Ribbon的實(shí)現(xiàn)
- Spring Cloud Ribbon實(shí)現(xiàn)客戶端負(fù)載均衡的方法
- Spring Cloud Ribbon實(shí)現(xiàn)客戶端負(fù)載均衡的示例
- 使用Spring Cloud Feign作為HTTP客戶端調(diào)用遠(yuǎn)程HTTP服務(wù)的方法(推薦)
- 詳解spring cloud中使用Ribbon實(shí)現(xiàn)客戶端的軟負(fù)載均衡
- Spring Cloud實(shí)現(xiàn)提供API給客戶端的方法詳解
- SpringCloud添加客戶端Eureka Client過(guò)程解析
相關(guān)文章
Intellij IDEA如何自定義注釋模板的實(shí)現(xiàn)方法
這篇文章主要介紹了Intellij IDEA如何自定義注釋模板的實(shí)現(xiàn)方法,小編覺(jué)得挺不錯(cuò)的,現(xiàn)在分享給大家,也給大家做個(gè)參考。一起跟隨小編過(guò)來(lái)看看吧2019-05-05centos下GitLab+Jenkins持續(xù)集成環(huán)境搭建(安裝jenkins)
這篇文章主要為大家詳細(xì)介紹了centos下搭建GitLab+Jenkins持續(xù)集成環(huán)境,安裝jenkins的方法,具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下2018-04-04APP轉(zhuǎn)盤(pán)抽獎(jiǎng)Java服務(wù)端接口詳解
這篇文章主要為大家詳細(xì)介紹了APP轉(zhuǎn)盤(pán)抽獎(jiǎng)Java服務(wù)端接口,具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下2019-01-01SpringBoot攔截器讀取流后不能再讀取的問(wèn)題
這篇文章主要介紹了SpringBoot攔截器讀取流后不能再讀取的問(wèn)題,具有很好的參考價(jià)值,希望對(duì)大家有所幫助。如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2021-10-10spring cloud 使用Zuul 實(shí)現(xiàn)API網(wǎng)關(guān)服務(wù)問(wèn)題
這篇文章主要介紹了spring cloud 使用Zuul 實(shí)現(xiàn)API網(wǎng)關(guān)服務(wù)問(wèn)題,非常不錯(cuò),具有一定的參考借鑒價(jià)值,需要的朋友可以參考下2018-05-05java后端+前端使用WebSocket實(shí)現(xiàn)消息推送的詳細(xì)流程
后端向前端推送消息就需要長(zhǎng)連接,首先想到的就是websocket,下面這篇文章主要給大家介紹了關(guān)于java后端+前端使用WebSocket實(shí)現(xiàn)消息推送的詳細(xì)流程,需要的朋友可以參考下2022-10-10SpringBoot+?Sharding?Sphere?輕松實(shí)現(xiàn)數(shù)據(jù)庫(kù)字段加解密功能
在Spring?Boot生態(tài)中,有一個(gè)非常厲害的開(kāi)源框架:Apache?ShardingSphere,它是一款分布式?SQL?事務(wù)和查詢(xún)引擎,可通過(guò)數(shù)據(jù)分片、彈性伸縮、加密等能力對(duì)任意數(shù)據(jù)庫(kù)進(jìn)行增強(qiáng),今天通過(guò)這篇文章,我們一起來(lái)了解一下如何在?Spring?Boot?中快速實(shí)現(xiàn)數(shù)據(jù)的加解密功能2024-07-07