您好,登錄后才能下訂單哦!
這篇文章主要介紹了Spring Cloud開發人員解決服務沖突和實例亂竄的示例分析,具有一定借鑒價值,感興趣的朋友可以參考下,希望大家閱讀完這篇文章之后大有收獲,下面讓小編帶著大家一起了解一下。
在我們開發微服務架構系統時,雖然說每個微服務都是孤立的可以單獨開發,但實際上并非如此,要調試和測試你的服務不僅需要您的微服務運行,還需要它的上下文服務、依賴的基礎服務等都要運行;但如果你的系統服務數和依賴比較多呢,那就是一個比較棘手的問題!有沒有辦法能提高開發效率呢?
如上圖所示,我們能不能用服務器把所有的服務都部署起來,然后開發只在本地運行自己所負責開發的服務,因為需要依賴其他服務所以本地啟動的服務也需要注冊到公共的注冊中心里;
例子中
業務服務B
有3臺實例注冊到注冊中心里分別是:服務上的、開發A與開發B自己本機啟動的
但是這樣做又會出現新的問題:服務會沖突亂竄,意思就是開發A
在debug自己的業務服務B
服務的時候可能請求會跳轉到其他人的實例上(服務器、開發B)
解決這個服務亂竄問題有一個比較優雅的方式就是自定義負載均衡規則
,主要實現以下目標:
普通用戶訪問服務器上的頁面時,請求的所有路由只調用服務器上的實例
開發A訪問時,請求的所有路由優先調用開發A本機啟動的實例
,如果沒有則調用服務器上的實例
開發B訪問時同上,請求的所有路由優先調用開發B本機啟動的實例
,如果沒有則調用服務器上的實例
要實現上面的目標有兩個比較關鍵的問題需要解決
區分不同用戶的服務實例
實現自定義負載均衡規則
直接使用注冊中心的元數據(metadata)來區分就可以了
主流的注冊中心都帶有元數據管理
以Nacos
為例,只需要在配置文件下添加
spring: cloud: nacos: discovery: server-addr: localhost:8848 metadata: version: zlt
metadata下的
version
就是我添加的元數據key
為version,value
為zlt
啟動服務后元數據就會注冊上去,如下圖
經過元數據區分后,目前是下面這個情況,服務器的實例version
為空,而開發人員自己本地啟動的實例version
為唯一標識(自己的名字)
首先在Spring Cloud
微服務框架里實例的負載均衡是由Ribbon
負責。
CustomIsolationRule類
public class CustomIsolationRule extends RoundRobinRule {/** * 優先根據版本號取實例 */@Overridepublic Server choose(ILoadBalancer lb, Object key) {if (lb == null) {return null; } String version = LbIsolationContextHolder.getVersion(); List<Server> targetList = null; List<Server> upList = lb.getReachableServers();if (StrUtil.isNotEmpty(version)) {//取指定版本號的實例targetList = upList.stream().filter( server -> version.equals( ((NacosServer) server).getMetadata().get(CommonConstant.METADATA_VERSION) ) ).collect(Collectors.toList()); }if (CollUtil.isEmpty(targetList)) {//只取無版本號的實例targetList = upList.stream().filter( server -> { String metadataVersion = ((NacosServer) server).getMetadata().get(CommonConstant.METADATA_VERSION);return StrUtil.isEmpty(metadataVersion); } ).collect(Collectors.toList()); }if (CollUtil.isNotEmpty(targetList)) {return getServer(targetList); }return super.choose(lb, key); }/** * 隨機取一個實例 */private Server getServer(List<Server> upList) {int nextInt = RandomUtil.randomInt(upList.size());return upList.get(nextInt); } }
集成輪詢規則
RoundRobinRule
來實現,主要的邏輯為
根據上游輸入的版本號
version
,有值的話則取服務元信息
中version
值一樣的實例上游的版本號
version
沒值或者該版本號匹配不到任何服務,則只取服務元信息
中version
值為空的實
并通過配置開關控制是否開啟自定義負載規則
@Configuration@ConditionalOnProperty(value = "zlt.ribbon.isolation.enabled", havingValue = "true")@RibbonClients(defaultConfiguration = {RuleConfigure.class})public class LbIsolationConfig { }
相關源碼
https://gitee.com/zlt2000/microservices-platform/blob/master/zlt-commons/zlt-ribbon-spring-boot-starter/src/main/java/com/central/common/ribbon/rule/CustomIsolationRule.java
上面提到的區分服務實例和自定義負載規則為整個解決思路的核心點,剩下要做的就是上游的version
怎樣指定呢?,下面我提供兩個思路
開發人員自己啟動前端工程,通過配置參數,統一在前端工程傳遞version
通過postman
調用接口的時候在header參數中添加
感謝你能夠認真閱讀完這篇文章,希望小編分享的“Spring Cloud開發人員解決服務沖突和實例亂竄的示例分析”這篇文章對大家有幫助,同時也希望大家多多支持億速云,關注億速云行業資訊頻道,更多相關知識等著你來學習!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。