當前位置：首頁 > 前端技术 > javascript >内容正文

javascript

Spring Cloud 微服务架构全链路实践

發布時間：2023/12/20 javascript 43 豆豆

生活随笔收集整理的這篇文章主要介紹了 Spring Cloud 微服务架构全链路实践小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

閱讀目錄：

1. 網關請求流程
2. Eureka 服務治理
3. Config 配置中心
4. Hystrix 監控
5. 服務調用鏈路
6. ELK 日志鏈路
7. 統一格式返回

Java 微服務框架選型（Dubbo 和 Spring Cloud？）

目前公司使用的 Spring Cloud 整個技術組件，基本包含了上面圖中所包含的，不得不說，Spring Cloud 整個生態真的很強大，使用起來也很方便有效。

后面有時間再針對每個組件進行使用解讀，這篇文章主要說下 Spring Cloud 架構的鏈路圖，順便把自己的思路整理下來，以備查閱。

1. 網關請求流程

在 Spring Cloud 整個組件庫中，Spring Cloud Zuul 是最容易被忽視，但也是最重要的，Spring Cloud Zuul 可以和 Eureka 注冊中心集成，我們目前使用 Spring Cloud Zuul 的功能如下：

Filter 過濾器
Router 路由
Ribbon 負載均衡
Hystrix 熔斷
Retry 重試

有些功能是 Spring Cloud Zuul 自帶的，比如 Filter 和 Router，有些是結合 Spring Cloud 其他組件，比如 Ribbon 和 Hystrix。

這里重點介紹下 Filter 過濾器，分為四個過濾類型：

pre：Zuul 轉發請求之前執行，我們目前的實現是AccessTokenFilter，用于 oAuth2.0 JWT 的授權驗證。
route：Zuul 路由時執行，目前項目沒用到。
post：Zuul 路由轉發后執行，也就是已經請求成功了后端服務，我們目前的實現是CustomResponseFilter，用于統一請求格式的封裝，比如 code/msg/data 等。
error：以上過濾器發生錯誤時執行，我們目前的實現是CustomErrorFilter，用于攔截過濾器執行的出現的錯誤，然后統一格式封裝返回，另外，error 過濾器好像并不能捕獲后端服務執行出現的錯誤。

另外，關于 oAuth2.0 JWT 的授權驗證，實現的方式有兩種：

授權的配置在后端服務中（每個服務都需要當作 Resource Server 進行配置，需要配置公鑰，接口的授權具體配置在注解中），Zuul 只做轉發，并不進行授權的驗證。
授權的配置在 Zuul 中，也就是把 Zuul 當作 Resource Server，后端服務不需要進行任何處理，Zuul 中具體的實現就是AccessTokenFilter，里面的邏輯是手動解析 JWT，然后判斷是否正確，以及解析出用戶信息/Scope/Role，然后根據當前的請求 API，對授權 Map 中的配置進行匹配，如果匹配錯誤，直接拋出 401 授權錯誤。

我們目前采用的是第二種方式，這兩種方式都有利有弊，關鍵在于自己的取舍，為什么采用第二種方式？目的就是發揮 Zuul 的作用，對外網關進行統一授權驗證。

關于授權 Map，里面存儲了所有服務接口的配置，示例配置：

private static final Map ROUTE_MAPS; static {ROUTE_MAPS = new HashMap<String, String>();ROUTE_MAPS.put("eureka-client/home", "read:ROLE_ADMIN");ROUTE_MAPS.put("eureka-client/user", "read:ROLE_ADMIN");ROUTE_MAPS.put("eureka-client/error", "read:ROLE_ADMIN"); }

這是我們目前的配置，是一個靜態的 Map，后面會存儲在 Spring Cloud Config 配置中心，Zuul 啟動時進行加載，利用 Spring Cloud Bus 動態刷新。

關于 Zuul 網關，其實還有很多需要說的，后面有機會再進行針對說明。

2. Eureka 服務治理

Eureka 遵循的是 AP 原則（服務可用性和分區容錯性），是服務治理最理想的遵循 CAP 分布式原則。

Eureka 集群中的節點是彼此平級，不像 Consul 有 master/worker 之分，集群中的 Eureka 節點彼此兩兩注冊，所以，Eureka 集群最好部署三個節點，這也是我們目前的部署方式。

另外，Eureka 的自我保護機制，可以參考這篇文章。

服務之間的相互調用，負載有兩種使用方式：

Feign：基于聲明式，顧名思義，就是需要定義接口，就像我們平常使用對象調用一樣。
Ribbon：軟負載，通過往 RestTemplate 中注入負載 Handler，然后通過負載算法選取調用（通過 Eureka 獲取服務注冊信息）。

我們目前打算使用 Ribbon 負載方式，為什么？看下面代碼就知道了：

restTemplate.getForObject("http://eureka-client/hello", String.class);

3. Config 配置中心

我們目前配置中心使用的是 Spring Cloud Config，當然你也可以使用功能更強大的 Polly（攜程開源），但 Config 目前也能滿足我們的需求，存儲倉庫我們現在使用的是 Git。

Config 配置中心提供了數據加密功能，你可以使用 RSA 的加密方式，這樣存儲在 Git 中的配置都是密文形式，Config Client 獲取加密配置的時候，Config Server 會自動進行解密返回。

配置中心的使用場景，我們目前主要是兩個地方：

項目啟動的配置信息，比如數據庫的連接字符串等。
業務服務的配置信息，也就是業務相關的配置。

另外，需要說明的是，默認情況下，如果 Git 中的配置更新了，Config Client 不會進行更新配置，我們目前的解決方式是，使用 Spring Cloud Bus 進行動態刷新配置（Config Server 中配置），具體的流程：

Git 中添加 WebHooks 腳本，比如curl -X POST http://manager1:8180/bus/refresh，當 Git 倉庫中的配置更新后，自動執行。
Config Server 中配置 Spring Cloud Bus，接受 Git 的配置刷新請求，然后利用 RabbitMQ 廣播通知所有的 Config Client 訂閱方，刷新配置信息。

4. Hystrix 監控

Hystrix 主要是用于服務熔斷/降級/隔離處理，Hystrix 配置在調用方，當被調用方服務不可用時，觸發 Hystrix 熔斷，會執行指定的 Fallback 方法，進行特殊處理。

我之前以為，Hystrix 熔斷的觸發條件是服務不可用，也就是服務請求超時（比如服務掛掉了），但我自己測試了下，服務出現 500 錯誤，也會觸發 Hystrix 熔斷，而且會自動忽略 Hystrix 的超時時間設置。

我們目前使用 Hystrix，主要有兩個地方：

內部服務調用：可以對某個 API 接口進行熔斷處理。
Zuul 網關使用：就是當 Zuul 路由轉發調用時，但有個局限性，就是只能對服務進行熔斷，并不能針對某個 API 接口熔斷。

上面圖中，主要畫的是 Hystrix 的監控流程，我們目前主要使用 RabbitMQ 進行采集傳輸，turbine-server 進行數據流的聚合，hystrix-dashboard 進行圖形化的展示。

5. 服務調用鏈路

服務調用鏈路的概念，就是當服務請求發起時，記錄整個請求鏈路的數據，以備查詢。

目前市面上，幾乎所有服務調用鏈路的實現，理論基礎都是基于 Google Dapper 的那篇論文，其中最重要的概念就是 traceId 和 spanId。

traceId 記錄整個服務鏈路的 ID，由首次請求方創建，服務鏈路中唯一。
spanId 記錄當前服務塊的 ID，由當前服務方創建。
parentId 記錄上一個請求服務的 spanId。

下面我描述下，我們目前的服務調用鏈路過程：

H5 發起請求，到 Zuul 網關，Zuul 創建全局的 traceId 和自己的 spanId，然后攜帶這些數據到業務服務 A，并利用 Spring Cloud Sluth 傳輸到 RabbitMQ。
業務服務 A，接收到 Zuul 傳輸的 traceId 和 spanId，然后把 Zuul 的 spanId 設置成 parentId，并生成自己的 spanId，然后攜帶這些數據到業務服務 B，并利用 Spring Cloud Sluth 傳輸到 RabbitMQ。
....

上面圖中，詳細說明了整個服務調用鏈路的過程，這邊再說下使用的技術棧：

Spring Cloud Sluth：和 SkyWalking 的探針概念比較類似，每個服務都進行配置，收集當然服務的請求數據（traceId 和 spanId），然后利用stream-sluth和binder-rabbit組件，將請求數據傳輸到 RabbitMQ。
Spring Cloud Zipkin：主要用于請求鏈路的 UI 展示，Zipkin 會從 RabbitMQ 讀取請求數據，然后存儲到 ElasticSearch 中，然后下次顯示直接從 ElasticSearch 中讀取。
Kibana：Kibana 也可以顯示 ElasticSearch 中的請求數據，只不過不是圖形化的，需要索引配置創建。

6. ELK 日志鏈路

ELK 可以參考下之前的幾篇文章：

ELK 架構之 Elasticsearch 和 Kibana 安裝配置
ELK 架構之 Logstash 和 Filebeat 安裝配置
ELK 架構之 Logstash 和 Filebeat 配置使用（采集過濾）
ELK 架構之 Elasticsearch、Kibana、Logstash 和 Filebeat 安裝配置匯總（6.2.4 版本）

上面圖中已經很詳細介紹了下 ELK 的流程，ELK 默認技術棧里是沒有 Filebeat 的，Logstash 用作日志收集的時候，CPU 和內存會占用資源比較大，所以我們使用輕量化的 Filebeat 進行日志的收集，Filebeat 部署在每個業務服務所在的服務器，然后將收集到的日志數據傳輸到 Logstash，Logstash 可以部署兩到三臺服務器上，用作日志的過濾和分析工作，然后再將處理后的日志數據，傳輸到 ElasticSearch 存儲。

7. 統一格式返回

關于統一格式返回，圖中已經詳細的說明了，如果你有更好的方案，歡迎探討。

總結

以上是生活随笔為你收集整理的Spring Cloud 微服务架构全链路实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。