閱讀目錄：

• 1. 閘道器請求流程
• 2. Eureka 服務治理
• 3. Config 配置中心
• 4. Hystrix 監控
• 5. 服務呼叫鏈路
• 6. ELK 日誌鏈路
• 7. 統一格式返回

目前公司使用的 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 的流程，ELK 預設技術棧裡是沒有 Filebeat 的，Logstash 用作日誌收集的時候，CPU 和記憶體會佔用資源比較大，所以我們使用輕量化的 Filebeat 進行日誌的收集，Filebeat 部署在每個業務服務所在的伺服器，然後將收集到的日誌資料傳輸到 Logstash，Logstash 可以部署兩到三臺伺服器上，用作日誌的過濾和分析工作，然後再將處理後的日誌資料，傳輸到 ElasticSearch 儲存。

7. 統一格式返回

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