您好,登錄后才能下訂單哦!
這篇“SpringCloud Alibaba框架實例應用分析”文章的知識點大部分人都不太理解,所以小編給大家總結了以下內容,內容詳細,步驟清晰,具有一定的借鑒價值,希望大家閱讀完這篇文章能有所收獲,下面我們一起來看看這篇“SpringCloud Alibaba框架實例應用分析”文章吧。
如果系統(tǒng)采用了微服務的架構模式,隨著微服務數(shù)量的不斷增多,服務之間的調用關系會變得縱橫交錯,需要引入服務治理的功能。服務治理也是在微服務架構模式下的一種最核心和最基本的模塊,主要用來實現(xiàn)各個微服務的自動注冊與發(fā)現(xiàn)。能夠實現(xiàn)注冊中心功能的組件有:Zookeeper、Eureka、Consul、Etcd、Nacos等。SpringCloud Alibaba框架用的是nacos。
Nacos除了提供服務注冊與發(fā)現(xiàn)功能外,還有一個重要功能是作為配置中心統(tǒng)一管理各服務的配置數(shù)據(jù)。集成nacos后只需要在application.yml文件中加入nacos配置即可,其余的配置加到nacos中,可以在線編輯修改發(fā)布,不需要重啟對應的服務。
Ribbon負載均衡是使用RestTemplate加上@loadBalance注解就可以通過服務名加上負載均衡策略去調用遠程的服務。
但是這樣實現(xiàn)的負載均衡仍然需要在業(yè)務代碼中調用遠程接口,有點low。OpenFeign組件是這種負載均衡實現(xiàn)方式的升級,面向接口編程,也就是說,咱們把注冊中心中每一個服務都以一個接口的形式體現(xiàn)。@FeignClient注解把一個龐大的微服務抽象成了一個接口,@FeignClient(value = “xxxxx”)中的value 屬性具體指定是哪個微服務。
那么OpenFeign底層會幫我們通過微服務的服務名去獲取到我們最關心的服務IP+Port,然后通過接口中的方法上配的@GetMapping(“/xxx/xxx”)來定位到具體方法。我們服務的消費者只需要調用這個接口中的方法,配合Ribbon使用,那么底層就會自動的調用遠方的服務,負載均衡策略默認使用的是Ribbon中的輪詢機制。
Feign是SpringCloud中的一個輕量級RestFul的Http客戶端,內置了Ribbon,用于客戶端負載均衡,使用方法是使用Feign的注解去修飾一個接口,客戶端調用這個接口那么久是調用遠程的微服務了。
OpenFeign在Feign的基礎上支持了SpringMVC的注解,如@RequestMapping等。OpenFeign的@FeigenClient注解可以解析SpringMvc的@RequestMapping注解下的接口,通過動態(tài)代理的方式產生實現(xiàn)類,實現(xiàn)類中進行負載均衡的微服務遠程調用!
Sentinel 從流量控制、熔斷降級、系統(tǒng)負載保護等多個維度保護服務的穩(wěn)定性,它分為兩個部分:
核心庫(Java 客戶端)不依賴任何框架/庫,同時對 Dubbo / Spring Cloud 等框架也有較好的支持,整合時在項目的pom.xml文件中引入Sentinel的依賴即可。
控制臺(Dashboard)基于 Spring Boot 開發(fā),從官網(wǎng)下載的是后臺打好的jar包,可以直接運行,不需要額外的 Tomcat 等應 用容器。
集成sentinel的服務中接口被調用后,可以從sentinel控制臺看到它自動攔截到了每個接口,點擊該接口就可以進行各種限流配置,如設置QPS閾值、并發(fā)流程數(shù)等。注意:因為Sentinel是懶加載機制,所以需要訪問一下接口,再去訪問Sentinel 才有數(shù)據(jù),并不是直接啟動Sentinel就有的。
系統(tǒng)中微服務數(shù)量較多時可能發(fā)生某些服務中斷或者訪問異常的情況,導致其他調用此服務的微服務也出現(xiàn)異常,從而系統(tǒng)可能出現(xiàn)不可用的情況,所以有必要添加服務容錯機制。具體實現(xiàn)方式是在微服務中添加sentinel依賴并在Feign中增加如下配置:
feign: sentinel: enabled: true
容錯類需要實現(xiàn)一個被容錯的接口,并實現(xiàn)這個接口的方法,比如要為userService中的方法容錯就要先建一個容錯類userServiceFallBack類實現(xiàn)UserService接口,接口方法具體實現(xiàn)是userService服務中斷或異常后的處理邏輯,比如返回各默認的對象等。接下來,在被遠程調用的微服務的UserService 接口上的@FeignClient注解上指定容錯類,如下所示。
@FeignClient(value = “server-user”, fallback = UserServiceFallBack.class)
API網(wǎng)關,其實就是整個系統(tǒng)的統(tǒng)一入口。網(wǎng)關會封裝微服務的內部結構,為客戶端提供統(tǒng)一的入口服務,同時,一些與具體業(yè)務邏輯無關的通用邏輯可以在網(wǎng)關中實現(xiàn),比如認證、授權、路由轉發(fā)、限流、監(jiān)控等。目前,比較主流的API網(wǎng)關有:Nginx+Lua、Kong網(wǎng)關、Zuul網(wǎng)關(Netflix開源的網(wǎng)關)、Apache Shenyu網(wǎng)關、SpringCloud Gateway網(wǎng)關。SpringCloud Alibaba技術棧中,并沒有單獨實現(xiàn)網(wǎng)關的組件,一般使用SpringCloud Gateway實現(xiàn)網(wǎng)關功能。
客戶端請求到 Gateway 網(wǎng)關,會先經(jīng)過 Gateway Handler Mapping 進行請求和路由匹配。匹配成功后再發(fā)送到 Gateway Web Handler 處理,然后會經(jīng)過特定的過濾器鏈,經(jīng)過所有前置過濾后,會發(fā)送代理請求。請求結果返回后,最后會執(zhí)行所有的后置過濾器。
在實際應用中,我們可以增加一個網(wǎng)關微服務,然后集成nacos服務,這樣就能通過網(wǎng)關端口來統(tǒng)一訪問注冊到nacos中的其他微服務,也可以集成Sentinel在網(wǎng)關服務中實現(xiàn)限流。
為什么要實現(xiàn)鏈路跟蹤?單體架構中可以使用AOP在調用具體的業(yè)務邏輯前后分別打印一下時間即可計算出整體的調用時間,使用 AOP捕獲異常也可知道是哪里的調用導致的異常。但是在分布式微服務場景下,使用AOP技術是無法追蹤到各個微服務的調用情況的,也就無法知道系統(tǒng)中處理一次請求的整體調用鏈路。
每個微服務只需要添加Sleuth的依賴,就可以在命令行查看鏈路追蹤情況。
Sleuth支持抽樣采集數(shù)據(jù)。尤其是在高并發(fā)場景下,如果采集所有的數(shù)據(jù),那么采集的數(shù)據(jù)量就太大了,非常耗費系統(tǒng)的性能,通常的做法是可以減少一部分數(shù)據(jù)量,配置如下:
sleuth: enabled: true sampler.percentage: 1.0 #request采樣率
Sleuth支持對異步任務的鏈路追蹤,在項目中使用@Async注解開啟一個異步任務后,Sleuth會為異步任務重新生成一個Span。
在實際項目中通過查看日志的情況來了解系統(tǒng)調用的鏈路情況效率太差了,一般會將Sleuth和ZipKin進行整合,利用ZipKin將日志進行聚合,將鏈路日志進行可視化展示,并支持全文檢索。Zipkin總體上分為服務端和客戶端,我們需要下載并啟動ZipKin服務端的Jar包(默認監(jiān)聽的端口號為9411),在各微服務中集成ZipKin的客戶端(添加ZipKin依賴)。
通過ZipKin能夠查看服務的調用鏈路,并且能夠查看分析具體微服務的調用情況,找出系統(tǒng)的瓶頸點,進而進行針對性的優(yōu)化。另外,ZipKin中也支持下載系統(tǒng)調用鏈路的Json數(shù)據(jù),可以將數(shù)據(jù)保存到ElasticSearch、Cassandra或者MySQL中。
通過消息隊列,我們可以實現(xiàn)多個進程之間的通信,例如,可以實現(xiàn)多個微服務之間的消息通信。MQ的最簡模型就是生產者生產消息,將消息發(fā)送到MQ,消息消費者訂閱MQ,消費消息。使用的比較多的MQ包含RabbitMQ、Kafka和RocketMQ。
引入MQ最大的優(yōu)點就是異步解耦和流量削峰,但是引入MQ后也有很多需要注意的事項和問題,主要包括:系統(tǒng)的整體可用性降低、系統(tǒng)的復雜度變高、引入了消息一致性的問題。
以上就是關于“SpringCloud Alibaba框架實例應用分析”這篇文章的內容,相信大家都有了一定的了解,希望小編分享的內容對大家有幫助,若想了解更多相關的知識內容,請關注億速云行業(yè)資訊頻道。
免責聲明:本站發(fā)布的內容(圖片、視頻和文字)以原創(chuàng)、轉載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權內容。