前言

spring cloud是一個(gè)基于springboot實(shí)現(xiàn)的微服務(wù)架構(gòu)開(kāi)發(fā)工具，使用springcloud框架進(jìn)行微服務(wù)業(yè)務(wù)開(kāi)發(fā)是java后端開(kāi)發(fā)必備技能，目前主流的SpringCloud分為SpringCloud Netflix和阿里云開(kāi)源的SpringCloud Alibaba兩個(gè)系列，由于博主一直用的是springcloud alibaba，所以本文以此為例總結(jié)一下SpringCloud Alibaba都有哪些組件及各自的作用。本文非實(shí)戰(zhàn)文章，但是參考了冰河老師的《SpringCloud Alibaba實(shí)戰(zhàn)》一書(shū)。

1.集成Nacos實(shí)現(xiàn)服務(wù)的自動(dòng)注冊(cè)與發(fā)現(xiàn)

如果系統(tǒng)采用了微服務(wù)的架構(gòu)模式，隨著微服務(wù)數(shù)量的不斷增多，服務(wù)之間的調(diào)用關(guān)系會(huì)變得縱橫交錯(cuò)，需要引入服務(wù)治理的功能。服務(wù)治理也是在微服務(wù)架構(gòu)模式下的一種最核心和最基本的模塊，主要用來(lái)實(shí)現(xiàn)各個(gè)微服務(wù)的自動(dòng)注冊(cè)與發(fā)現(xiàn)。能夠?qū)崿F(xiàn)注冊(cè)中心功能的組件有：Zookeeper、Eureka、Consul、Etcd、Nacos等。SpringCloud Alibaba框架用的是nacos。

Nacos除了提供服務(wù)注冊(cè)與發(fā)現(xiàn)功能外，還有一個(gè)重要功能是作為配置中心統(tǒng)一管理各服務(wù)的配置數(shù)據(jù)。集成nacos后只需要在application.yml文件中加入nacos配置即可，其余的配置加到nacos中，可以在線(xiàn)編輯修改發(fā)布，不需要重啟對(duì)應(yīng)的服務(wù)。

2. Feign負(fù)載均衡

Ribbon負(fù)載均衡是使用RestTemplate加上@loadBalance注解就可以通過(guò)服務(wù)名加上負(fù)載均衡策略去調(diào)用遠(yuǎn)程的服務(wù)。
但是這樣實(shí)現(xiàn)的負(fù)載均衡仍然需要在業(yè)務(wù)代碼中調(diào)用遠(yuǎn)程接口，有點(diǎn)low。OpenFeign組件是這種負(fù)載均衡實(shí)現(xiàn)方式的升級(jí)，面向接口編程，也就是說(shuō)，咱們把注冊(cè)中心中每一個(gè)服務(wù)都以一個(gè)接口的形式體現(xiàn)。
@FeignClient注解把一個(gè)龐大的微服務(wù)抽象成了一個(gè)接口，@FeignClient(value = “xxxxx”)中的value 屬性具體指定是哪個(gè)微服務(wù)。
那么OpenFeign底層會(huì)幫我們通過(guò)微服務(wù)的服務(wù)名去獲取到我們最關(guān)心的服務(wù)IP+Port，然后通過(guò)接口中的方法上配的@GetMapping(“/xxx/xxx”)來(lái)定位到具體方法。我們服務(wù)的消費(fèi)者只需要調(diào)用這個(gè)接口中的方法，配合Ribbon使用，那么底層就會(huì)自動(dòng)的調(diào)用遠(yuǎn)方的服務(wù)，負(fù)載均衡策略默認(rèn)使用的是Ribbon中的輪詢(xún)機(jī)制。

注：OpenFeign和Feign的區(qū)別：

Feign是SpringCloud中的一個(gè)輕量級(jí)RestFul的Http客戶(hù)端，內(nèi)置了Ribbon，用于客戶(hù)端負(fù)載均衡，使用方法是使用Feign的注解去修飾一個(gè)接口，客戶(hù)端調(diào)用這個(gè)接口那么久是調(diào)用遠(yuǎn)程的微服務(wù)了。
OpenFeign在Feign的基礎(chǔ)上支持了SpringMVC的注解，如@RequestMapping等。OpenFeign的@FeigenClient注解可以解析SpringMvc的@RequestMapping注解下的接口，通過(guò)動(dòng)態(tài)代理的方式產(chǎn)生實(shí)現(xiàn)類(lèi)，實(shí)現(xiàn)類(lèi)中進(jìn)行負(fù)載均衡的微服務(wù)遠(yuǎn)程調(diào)用！

3.使用Sentinel實(shí)現(xiàn)了接口的限流

Sentinel 從流量控制、熔斷降級(jí)、系統(tǒng)負(fù)載保護(hù)等多個(gè)維度保護(hù)服務(wù)的穩(wěn)定性，它分為兩個(gè)部分:

1. 核心庫(kù)（Java 客戶(hù)端）不依賴(lài)任何框架/庫(kù)，同時(shí)對(duì) Dubbo / Spring Cloud 等框架也有較好的支持，整合時(shí)在項(xiàng)目的pom.xml文件中引入Sentinel的依賴(lài)即可。
2. 控制臺(tái)（Dashboard）基于 Spring Boot 開(kāi)發(fā)，從官網(wǎng)下載的是后臺(tái)打好的jar包，可以直接運(yùn)行，不需要額外的 Tomcat 等應(yīng) 用容器。

集成sentinel的服務(wù)中接口被調(diào)用后，可以從sentinel控制臺(tái)看到它自動(dòng)攔截到了每個(gè)接口，點(diǎn)擊該接口就可以進(jìn)行各種限流配置，如設(shè)置QPS閾值、并發(fā)流程數(shù)等。
注意：因?yàn)镾entinel是懶加載機(jī)制，所以需要訪問(wèn)一下接口，再去訪問(wèn)Sentinel 才有數(shù)據(jù)，并不是直接啟動(dòng)Sentinel就有的。

4.Feign整合Sentinel實(shí)現(xiàn)容錯(cuò)

系統(tǒng)中微服務(wù)數(shù)量較多時(shí)可能發(fā)生某些服務(wù)中斷或者訪問(wèn)異常的情況，導(dǎo)致其他調(diào)用此服務(wù)的微服務(wù)也出現(xiàn)異常，從而系統(tǒng)可能出現(xiàn)不可用的情況，所以有必要添加服務(wù)容錯(cuò)機(jī)制。具體實(shí)現(xiàn)方式是在微服務(wù)中添加sentinel依賴(lài)并在Feign中增加如下配置：

feign:
sentinel:
enabled: true

容錯(cuò)類(lèi)需要實(shí)現(xiàn)一個(gè)被容錯(cuò)的接口，并實(shí)現(xiàn)這個(gè)接口的方法，比如要為userService中的方法容錯(cuò)就要先建一個(gè)容錯(cuò)類(lèi)userServiceFallBack類(lèi)實(shí)現(xiàn)UserService接口,接口方法具體實(shí)現(xiàn)是userService服務(wù)中斷或異常后的處理邏輯，比如返回各默認(rèn)的對(duì)象等。接下來(lái)，在被遠(yuǎn)程調(diào)用的微服務(wù)的UserService 接口上的@FeignClient注解上指定容錯(cuò)類(lèi)，如下所示。

@FeignClient(value = “server-user”, fallback = UserServiceFallBack.class)

5.API網(wǎng)關(guān)

API網(wǎng)關(guān)，其實(shí)就是整個(gè)系統(tǒng)的統(tǒng)一入口。網(wǎng)關(guān)會(huì)封裝微服務(wù)的內(nèi)部結(jié)構(gòu)，為客戶(hù)端提供統(tǒng)一的入口服務(wù)，同時(shí)，一些與具體業(yè)務(wù)邏輯無(wú)關(guān)的通用邏輯可以在網(wǎng)關(guān)中實(shí)現(xiàn)，比如認(rèn)證、授權(quán)、路由轉(zhuǎn)發(fā)、限流、監(jiān)控等。目前，比較主流的API網(wǎng)關(guān)有：Nginx+Lua、Kong網(wǎng)關(guān)、Zuul網(wǎng)關(guān)(Netflix開(kāi)源的網(wǎng)關(guān))、Apache Shenyu網(wǎng)關(guān)、SpringCloud Gateway網(wǎng)關(guān)。SpringCloud Alibaba技術(shù)棧中，并沒(méi)有單獨(dú)實(shí)現(xiàn)網(wǎng)關(guān)的組件,一般使用SpringCloud Gateway實(shí)現(xiàn)網(wǎng)關(guān)功能。
客戶(hù)端請(qǐng)求到 Gateway 網(wǎng)關(guān)，會(huì)先經(jīng)過(guò) Gateway Handler Mapping 進(jìn)行請(qǐng)求和路由匹配。匹配成功后再發(fā)送到 Gateway Web Handler 處理，然后會(huì)經(jīng)過(guò)特定的過(guò)濾器鏈，經(jīng)過(guò)所有前置過(guò)濾后，會(huì)發(fā)送代理請(qǐng)求。請(qǐng)求結(jié)果返回后，最后會(huì)執(zhí)行所有的后置過(guò)濾器。
在實(shí)際應(yīng)用中，我們可以增加一個(gè)網(wǎng)關(guān)微服務(wù)，然后集成nacos服務(wù)，這樣就能通過(guò)網(wǎng)關(guān)端口來(lái)統(tǒng)一訪問(wèn)注冊(cè)到nacos中的其他微服務(wù)，也可以集成Sentinel在網(wǎng)關(guān)服務(wù)中實(shí)現(xiàn)限流。

6.Sleuth整合ZipKin實(shí)現(xiàn)鏈路追蹤

為什么要實(shí)現(xiàn)鏈路跟蹤？單體架構(gòu)中可以使用AOP在調(diào)用具體的業(yè)務(wù)邏輯前后分別打印一下時(shí)間即可計(jì)算出整體的調(diào)用時(shí)間，使用 AOP捕獲異常也可知道是哪里的調(diào)用導(dǎo)致的異常。但是在分布式微服務(wù)場(chǎng)景下，使用AOP技術(shù)是無(wú)法追蹤到各個(gè)微服務(wù)的調(diào)用情況的，也就無(wú)法知道系統(tǒng)中處理一次請(qǐng)求的整體調(diào)用鏈路。
每個(gè)微服務(wù)只需要添加Sleuth的依賴(lài)，就可以在命令行查看鏈路追蹤情況。

• Sleuth支持抽樣采集數(shù)據(jù)。尤其是在高并發(fā)場(chǎng)景下，如果采集所有的數(shù)據(jù)，那么采集的數(shù)據(jù)量就太大了，非常耗費(fèi)系統(tǒng)的性能,通常的做法是可以減少一部分?jǐn)?shù)據(jù)量,配置如下：

sleuth:
	enabled: true
	sampler.percentage: 1.0 #request采樣率

• Sleuth支持對(duì)異步任務(wù)的鏈路追蹤，在項(xiàng)目中使用@Async注解開(kāi)啟一個(gè)異步任務(wù)后，Sleuth會(huì)為異步任務(wù)重新生成一個(gè)Span。

 在實(shí)際項(xiàng)目中通過(guò)查看日志的情況來(lái)了解系統(tǒng)調(diào)用的鏈路情況效率太差了，一般會(huì)將Sleuth和ZipKin進(jìn)行整合，利用ZipKin將日志進(jìn)行聚合，將鏈路日志進(jìn)行可視化展示，并支持全文檢索。Zipkin總體上分為服務(wù)端和客戶(hù)端，我們需要下載并啟動(dòng)ZipKin服務(wù)端的Jar包（默認(rèn)監(jiān)聽(tīng)的端口號(hào)為9411），在各微服務(wù)中集成ZipKin的客戶(hù)端（添加ZipKin依賴(lài)）。

通過(guò)ZipKin能夠查看服務(wù)的調(diào)用鏈路，并且能夠查看分析具體微服務(wù)的調(diào)用情況，找出系統(tǒng)的瓶頸點(diǎn)，進(jìn)而進(jìn)行針對(duì)性的優(yōu)化。另外，ZipKin中也支持下載系統(tǒng)調(diào)用鏈路的Json數(shù)據(jù)，可以將數(shù)據(jù)保存到ElasticSearch、Cassandra或者M(jìn)ySQL中。

7.消息隊(duì)列MQ

通過(guò)消息隊(duì)列，我們可以實(shí)現(xiàn)多個(gè)進(jìn)程之間的通信，例如，可以實(shí)現(xiàn)多個(gè)微服務(wù)之間的消息通信。MQ的最簡(jiǎn)模型就是生產(chǎn)者生產(chǎn)消息，將消息發(fā)送到MQ，消息消費(fèi)者訂閱MQ，消費(fèi)消息。使用的比較多的MQ包含RabbitMQ、Kafka和RocketMQ。
引入MQ最大的優(yōu)點(diǎn)就是異步解耦和流量削峰，但是引入MQ后也有很多需要注意的事項(xiàng)和問(wèn)題，主要包括：系統(tǒng)的整體可用性降低、系統(tǒng)的復(fù)雜度變高、引入了消息一致性的問(wèn)題。

到此這篇關(guān)于SpringCloud Alibaba框架介紹的文章就介紹到這了,更多相關(guān)SpringCloud Alibaba框架內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論