Spring Cloud Alibaba 本地調試介紹及方案設計
本地調試： 這里是指在開發環境中，部署了一整套的某個項目或者產品的服務，開發人員開發時，本地會起一個或多個服務，這些服務和開發環境中部署的服務是相同的，這種情況下，一個服務就會有多個實例，大多數微服務中的默認負載均衡策略都是輪詢，這些實例會輪流被調用。
為了方便 本地調試，需要提供一種策略，可以指定在負載均衡時，選擇哪個實例進行調用。在使用 Nacos 作為注冊中心時，可以通過 上線和下線 的方式來選擇使用哪個實例，但是這種方式只能強制調用某個實例，如果開發環境還有其他人在調試，自己程序 設置斷點 時會阻塞所有調用，非常不利于多人調試的協調。
為了解決 本地調試 的問題，本文實現了一種簡單實用的策略，可以通過 Nacos 動態配置服務路由，還可以基于用戶，部門，組織等級別配置服務路由，實現 本地調試 的同時，實際上也實現 灰度發布。
2 框架環境本文基于 Spring Cloud Alibaba 框架，和 Spring Cloud 相比增加了一部分針對 Dubbo 的方案，因此本文適合以下框架參考：
Spring Cloud Alibaba Spring CloudSpring Cloud GatewaySpring Cloud Ribbon
Dubbo下圖是 Spring Cloud Alibaba 框架中，一次方法調用的可能情況，Ailbaba 這部分多的是圖中 ServiceA -> ServiceB 部分使用 Dubbo 協議。Spring Cloud 框架中，用的是 ServiceA -> ServiceC 這種 Feign（HTTP） 方式。
圖中的所有過濾器和攔截器，雖然名稱不同，但是作用相同。這部分的主要作用就是 獲取或傳遞路由規則，例如，可以實現基于 HTTP Header 設置路由規則的配置，可以基于 HTTP 和 token 實現基于用戶的路由規則配置，這部分的實現和需求有關，沒有統一的實現。
3 方案設計這里以這兩種場景簡單舉個例子。
3.1 基于 HTTP Header 的本地調試方案
在這個方案中，按照上面的流程圖敘述一遍。
用戶調用服務前，在 Header 中設置調用規則，比如增加 service-route 請求頭，請求頭的內容為 servicea:10.10.10.130;serviceb:10.10.10.100;servicec:10.10.10.0/24，在請求頭中指明需要控制路由的服務信息（不需要控制的直接省略走默認）。 通過 Spring Cloud Gateway 的 GlobalFilter 實現提取請求頭信息，將配置信息記錄下來（如 ThreadLocal） 負載均衡時，根據這里的配置選擇優先路由的服務，調用 ServiceA 時，仍然是 HTTP 請求，請求頭會傳遞過去。 攔截器獲取請求頭中的路由規則，這一步和 1 類似，但是屬于 Spring MVC 的攔截器，獲取路由規則后記錄下來（如 ThreadLocal） ServiceA 調用 ServiceB 是 Dubbo 協議的路徑，和 7,8 Feign 方式沒有先后順序，是兩個分支。 在 4 這一步通過 Dubbo 的 Consumer Filter 過濾器和 RpcContext 將路由信息記錄到 attachment 中，這樣可以把路由配置傳遞到 ServiceB，如果 ServiceB 還需要調用其他服務，路由仍然會起到作用。 在 Dubbo 的 Router 實現中，根據路由信息選擇優先調用的服務，然后進行調用。 Dubbo 的 Provider Filter 從 RpcContext 獲取路由配置，記錄下來（如 ThreadLocal），如果后續調用其他服務，邏輯和 4，5，6一樣。在 6 這一步的 Provider Filter 結束調用的時候，注意清空路由信息（如 ThreadLocal.clear()），避免對其他調用產生污染。 這一步和4，5，6沒有順序關系，是純 Spring Cloud 方式的調用，在 ServiceA 調用時，通過自定義 Ribbon 中的 IRule 實現基于自己路由規則的調用。 在最終調用 ServiceC 之前，通過 Feign 的 RequestInterceptor 攔截器添加 service-route 頭，將服務路由傳遞下去。 和第3步相同，通過 Spring MVC 攔截器獲取服務路由記錄下來。后續在調用其他服務時，Dubbo服務走4，5，6，Feign方式走7，8，9。3.2 基于操作用戶的本地調試方案
基于操作用戶的方案中，和上面類似，但是不需要在每次請求的時候設置 HTTP Header，但是需要一種方式存取服務路由的配置。
這里以使用 Nacos 配置管理實現服務路由配置的存取。
根據自己使用的用戶在 Nacos 配置服務路由，配置名規則如 服務名.user-routes，使用 Spring Cloud Alibaba 的默認組 dubbo，用戶服務路由的配置規則可以自己定義，這里舉個簡單例子：
enabled: true # 啟用，停用ip: 10.10.0.0/24 # 默認優先IP或網段，所有IP都支持具體IP和網段userIps: # Map<Long, String>，優先級最高，針對用戶配置 IP 優先 # userId: IP 1: 10.10.0.100 2: 10.10.0.101# 這部分定義根據自己需要設計 deptIps: # 針對部門配置 # deptId: IP 1: 10.10.0.0/24orgIps: # 針對組織配置 # orgId: IP 1: 10.10.10.0/24
Spring Cloud Gateway 的 GlobalFilter 根據請求 token 獲取 用戶信息，記錄用戶信息（如 ThreadLocal）。
負載均衡時，使用 Nacos ConfigService，根據 服務名.user-routes 查詢配置信息，同時監聽該配置信息，根據這里的配置選擇優先路由的服務。 攔截器根據請求 token 獲取 用戶信息，記錄用戶信息（如 ThreadLocal）。 ServiceA 調用 ServiceB 是 Dubbo 協議的路徑，和 7,8 Feign 方式沒有先后順序，是兩個分支。 在 4 這一步通過 Dubbo 的 Consumer Filter 過濾器和 RpcContext 將用戶信息記錄到 attachment 中，這樣可以把用戶信息傳遞到 ServiceB，如果 ServiceB 還需要調用其他服務，用戶信息仍然會起到作用。 在 Dubbo 的 Router 實現中，根據路由信息選擇優先調用的服務，然后進行調用。 Dubbo 的 Provider Filter 從 RpcContext 獲取用戶信息，記錄下來（如 ThreadLocal），如果后續調用其他服務，邏輯和 4，5，6一樣。在 6 這一步的 Provider Filter 結束調用的時候，注意清空用戶信息（如 ThreadLocal.clear()），避免對其他調用產生污染。 這一步和4，5，6沒有順序關系，是純 Spring Cloud 方式的調用，在 ServiceA 調用時，通過自定義 Ribbon 中的 IRule 實現基于自己路由規則的調用。 在最終調用 ServiceC 之前，通過 Feign 的 RequestInterceptor 攔截器設置token或用戶信息，將操作用戶傳遞下去。 和第3步相同，通過 Spring MVC 攔截器獲取用戶信息記錄下來。后續在調用其他服務時，Dubbo服務走4，5，6，Feign方式走7，8，9。本文選擇第 2 種方案，針對 1~9 步，分別講解需要實現的接口和接口應用（生效）的配置。
4 實現要點上面提到的 ThreadLocal，實現時使用一個 static 變量存儲，提供相應的存取清空的靜態方法，方便跨接口的 用戶信息 傳遞。
4.1 Spring Cloud Gateway 全局過濾器
假設有一個 UserGlobalFilter，該過濾器根據 token 獲取并緩存用戶信息，在請求完成后需要清空緩存的用戶信息。
Spring Cloud Gateway 中的過濾器，直接在 @Configuration 的配置類中用 @Bean 提供即可。
4.2 Ribbon 負載均衡
實現 ribbon-loadbalancer 中的 com.netflix.loadbalancer.IRule 接口，將來調用具體服務時通過 choose 接口返回符合條件的實例。
實現這個接口之后，需要特殊的方式注冊該接口，在啟動類增加注解 @RibbonClients(defaultConfiguration = UserRuleConfiguration.class)，注解中指定了一個配置類，這個類一定不要添加 @Configuration 注解?。。?/b>。
在這個類中，通過 @Bean 注解返回一個 IRule 接口的實現。
在 Ribbon 中，會創建一個新的 ApplicationContext 來初始化這些配置，在這個新的 ApplicationContext 中，配置的 IRule 實現會被使用。
4.3 Spring MVC 攔截器
實現 HandlerInterceptor 攔截器，從請求獲取用戶信息并記錄下來。
攔截器想要生效，需要提供一個配置類，繼承 WebMvcConfigurer 接口，實現 addInterceptors 方法，在這個方法實現中添加攔截器的實現類。
4.4 Dubbo Consumer Filter 過濾器
實現Dubbo 的Filter接口，通過 RpcContext 傳遞前面記錄的用戶信息。
可以在實現類添加 @Activate 注解，指定 group 為 CommonConstants.CONSUMER。
按照 dubbo SPI 要求，添加 META-INF/dubbo/org.apache.dubbo.rpc.Filter 文件，寫上實現類。
4.5 Dubbo Router 路由
這一步實際上可以放在 Dubbo 負載均衡實現，也可以用 Router 實現。
使用 Router 時，需要同時使用 RouterFactory 和 Router 接口，然后配置 RouterFactory 的 SPI 配置文件。
在 Router 的 route 方法中根據規則返回合適的 Invoker。
4.6 Dubbo Provider Filter 過濾器
實現Dubbo 的Filter接口，通過 RpcContext 獲取傳遞過來的用戶信息。
可以在實現類添加 @Activate 注解，指定 group 為 CommonConstants.PROVIDER。
按照 dubbo SPI 要求，添加 META-INF/dubbo/org.apache.dubbo.rpc.Filter 文件，寫上實現類。
這個實現類可以和 4.4 的放一個 Filter 實現中，需要自己區分當前是 consumer 還是 provider 實現不同的邏輯。
4.7 Ribbon 負載均衡，同 4.2
這一步的實現和 4.2 一樣，4.2 是用在 Spring Cloud Gateway 中，這里是配置到具體的服務中。配置方式一樣。
4.8 Feign RequestInterceptor 攔截器
首先實現 RequestInterceptor 接口，在實現中往 requst 的 Header 中放置要傳遞的數據。
接口想要生效，需要和 Ribbon 類似的配置。
在 @EnableFeignClients 的注解中，通過 defaultConfiguration 設置一個 Feign 的配置類。在這個配置中通過 @Bean 提供 RequestInterceptor 接口的實現。
4.9 Spring MVC 攔截器，同 4.3
4.3 中是網關調用服務，4.9是服務通過 Feign （或resttemplate）調用服務，對被調用的服務來說都是 HTTP 請求，因此都會執行 Spring MVC 的攔截器，所以這里的實現是一樣的。
5. 總結本文提供了本地調試的方案和主要的實現要點，可以根據文中的關鍵指引和自己的實際需求實現自己的方案。關于本地調試如果有更好的方案，歡迎留言討論。
附：工具方法判斷IP是否相等或輸入子網IP的方法：
public static boolean ipInRange(String ip, String cidr) {if(cidr.indexOf(’/’) < 0) {return ip.equals(cidr);}int ipAddr = ipToInt(ip);int type = Integer.parseInt(cidr.replaceAll('.*/', ''));String cidrIp = cidr.replaceAll('/.*', '');if(type == 32){return ip.equals(cidrIp);}int cidrIpAddr = ipToInt(cidrIp);int mask = 0xFFFFFFFF << (32 - type);return (ipAddr & mask) == (cidrIpAddr & mask);}public static int ipToInt(String ip) {String[] ips = ip.split('.');return (Integer.parseInt(ips[0] << 24) |Integer.parseInt(ips[1] << 16) |Integer.parseInt(ips[2] << 8) |Integer.parseInt(ips[3]));}
到此這篇關于Spring Cloud Alibaba 本地調試方案的文章就介紹到這了,更多相關Spring Cloud Alibaba 本地調試內容請搜索好吧啦網以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持好吧啦網！
相關文章：
網公網安備