SpringCloud?Alibaba框架實例應用分析

這篇“SpringCloud Alibaba框架實例應用分析”文章的知識點大部分人都不太理解，所以小編給大家總結了以下內容，內容詳細，步驟清晰，具有一定的借鑒價值，希望大家閱讀完這篇文章能有所收獲，下面我們一起來看看這篇“SpringCloud Alibaba框架實例應用分析”文章吧。

1.集成Nacos實現服務的自動注冊與發現

如果系統采用了微服務的架構模式，隨著微服務數量的不斷增多，服務之間的調用關系會變得縱橫交錯，需要引入服務治理的功能。服務治理也是在微服務架構模式下的一種最核心和最基本的模塊，主要用來實現各個微服務的自動注冊與發現。能夠實現注冊中心功能的組件有：Zookeeper、Eureka、Consul、Etcd、Nacos等。SpringCloud Alibaba框架用的是nacos。

Nacos除了提供服務注冊與發現功能外，還有一個重要功能是作為配置中心統一管理各服務的配置數據。集成nacos后只需要在application.yml文件中加入nacos配置即可，其余的配置加到nacos中，可以在線編輯修改發布，不需要重啟對應的服務。

2. Feign負載均衡

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

注：OpenFeign和Feign的區別：

Feign是SpringCloud中的一個輕量級RestFul的Http客戶端，內置了Ribbon，用于客戶端負載均衡，使用方法是使用Feign的注解去修飾一個接口，客戶端調用這個接口那么久是調用遠程的微服務了。
OpenFeign在Feign的基礎上支持了SpringMVC的注解，如@RequestMapping等。OpenFeign的@FeigenClient注解可以解析SpringMvc的@RequestMapping注解下的接口，通過動態代理的方式產生實現類，實現類中進行負載均衡的微服務遠程調用！

3.使用Sentinel實現了接口的限流

Sentinel 從流量控制、熔斷降級、系統負載保護等多個維度保護服務的穩定性，它分為兩個部分:

1. 核心庫（Java 客戶端）不依賴任何框架/庫，同時對 Dubbo / Spring Cloud 等框架也有較好的支持，整合時在項目的pom.xml文件中引入Sentinel的依賴即可。

2. 控制臺（Dashboard）基于 Spring Boot 開發，從官網下載的是后臺打好的jar包，可以直接運行，不需要額外的 Tomcat 等應 用容器。

集成sentinel的服務中接口被調用后，可以從sentinel控制臺看到它自動攔截到了每個接口，點擊該接口就可以進行各種限流配置，如設置QPS閾值、并發流程數等。
注意：因為Sentinel是懶加載機制，所以需要訪問一下接口，再去訪問Sentinel 才有數據，并不是直接啟動Sentinel就有的。

4.Feign整合Sentinel實現容錯

系統中微服務數量較多時可能發生某些服務中斷或者訪問異常的情況，導致其他調用此服務的微服務也出現異常，從而系統可能出現不可用的情況，所以有必要添加服務容錯機制。具體實現方式是在微服務中添加sentinel依賴并在Feign中增加如下配置：

feign:
sentinel:
enabled: true

容錯類需要實現一個被容錯的接口，并實現這個接口的方法，比如要為userService中的方法容錯就要先建一個容錯類userServiceFallBack類實現UserService接口,接口方法具體實現是userService服務中斷或異常后的處理邏輯，比如返回各默認的對象等。接下來，在被遠程調用的微服務的UserService 接口上的@FeignClient注解上指定容錯類，如下所示。

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

5.API網關

API網關，其實就是整個系統的統一入口。網關會封裝微服務的內部結構，為客戶端提供統一的入口服務，同時，一些與具體業務邏輯無關的通用邏輯可以在網關中實現，比如認證、授權、路由轉發、限流、監控等。目前，比較主流的API網關有：Nginx+Lua、Kong網關、Zuul網關(Netflix開源的網關)、Apache Shenyu網關、SpringCloud Gateway網關。SpringCloud Alibaba技術棧中，并沒有單獨實現網關的組件,一般使用SpringCloud Gateway實現網關功能。
客戶端請求到 Gateway 網關，會先經過 Gateway Handler Mapping 進行請求和路由匹配。匹配成功后再發送到 Gateway Web Handler 處理，然后會經過特定的過濾器鏈，經過所有前置過濾后，會發送代理請求。請求結果返回后，最后會執行所有的后置過濾器。
在實際應用中，我們可以增加一個網關微服務，然后集成nacos服務，這樣就能通過網關端口來統一訪問注冊到nacos中的其他微服務，也可以集成Sentinel在網關服務中實現限流。

6.Sleuth整合ZipKin實現鏈路追蹤

為什么要實現鏈路跟蹤？單體架構中可以使用AOP在調用具體的業務邏輯前后分別打印一下時間即可計算出整體的調用時間，使用 AOP捕獲異常也可知道是哪里的調用導致的異常。但是在分布式微服務場景下，使用AOP技術是無法追蹤到各個微服務的調用情況的，也就無法知道系統中處理一次請求的整體調用鏈路。
每個微服務只需要添加Sleuth的依賴，就可以在命令行查看鏈路追蹤情況。

• Sleuth支持抽樣采集數據。尤其是在高并發場景下，如果采集所有的數據，那么采集的數據量就太大了，非常耗費系統的性能,通常的做法是可以減少一部分數據量,配置如下：

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

• Sleuth支持對異步任務的鏈路追蹤，在項目中使用@Async注解開啟一個異步任務后，Sleuth會為異步任務重新生成一個Span。

 在實際項目中通過查看日志的情況來了解系統調用的鏈路情況效率太差了，一般會將Sleuth和ZipKin進行整合，利用ZipKin將日志進行聚合，將鏈路日志進行可視化展示，并支持全文檢索。Zipkin總體上分為服務端和客戶端，我們需要下載并啟動ZipKin服務端的Jar包（默認監聽的端口號為9411），在各微服務中集成ZipKin的客戶端（添加ZipKin依賴）。

通過ZipKin能夠查看服務的調用鏈路，并且能夠查看分析具體微服務的調用情況，找出系統的瓶頸點，進而進行針對性的優化。另外，ZipKin中也支持下載系統調用鏈路的Json數據，可以將數據保存到ElasticSearch、Cassandra或者MySQL中。

7.消息隊列MQ

通過消息隊列，我們可以實現多個進程之間的通信，例如，可以實現多個微服務之間的消息通信。MQ的最簡模型就是生產者生產消息，將消息發送到MQ，消息消費者訂閱MQ，消費消息。使用的比較多的MQ包含RabbitMQ、Kafka和RocketMQ。
引入MQ最大的優點就是異步解耦和流量削峰，但是引入MQ后也有很多需要注意的事項和問題，主要包括：系統的整體可用性降低、系統的復雜度變高、引入了消息一致性的問題。

以上就是關于“SpringCloud Alibaba框架實例應用分析”這篇文章的內容，相信大家都有了一定的了解，希望小編分享的內容對大家有幫助，若想了解更多相關的知識內容，請關注億速云行業資訊頻道。