摘要:生產環境可以借助集合來實現灰度發布代碼請參考微服務權限框架的灰度發布功能,已經全部開源關于基于開發基于前后分離的開發平臺,支持賬號短信等多種登錄,提供配套視頻開發教程。
分析下目前遇到的痛點
你在開發工作的是否遇到這個問題,微服務模塊劃分過細,基礎模塊依賴的比較多?
比如你要進行微服務開發則需要啟動以下基礎模塊
注冊中心(eureka)
配置中心(spring cloud config)
網關(zuul)
認證中心(oauth)
...
如上圖紅色標注的服務模塊,而你需要編碼或者需要的只有那么一個業務微服務模塊,本地啟動這么微服務模塊對開發機器的要求性能較高,并且影響開發效率。
為了解決這種問題,團隊一般都會把通用的基礎模塊部,提供統一的開發環境,方便大家開發,如上圖 只需要考慮你的業務模塊(serviceA、serviceB) 即可,提高開發效率。
這種統一開發基礎環境問題存在小小的問題,比如當開發A維護serviceA,開發B維護serviceB 不會出現沖突;如果開發A、B同時維護一個模塊時候,就會出現沖突如下圖所示:A的本地請求會被路由到B正在開發的biz-service,而不是目標的A的biz-service,因為zuul 是更具服務名稱進行路由的
重寫網關的轉發規則,其實就是重寫ribbon的路由規則,根據客戶端不同的用戶請求(可以根據入參不同區分)路由到對應的微服務上,所以對應的微服務上要打上標簽。biz-service A開發版本,biz-service B開發版本
eureka: instance: metadata-map: version: v1.0 # A的開發版本
/** * @author lengleng * @date 2018/10/16 *3. 版本上下文TTL* 路由微服務斷言 *
* 1. eureka metadata 存在版本定義時候進行判斷 * 2. 不存在 metadata 直接返回true */ @Slf4j public class MetadataCanaryRuleHandler extends ZoneAvoidanceRule { @Override public AbstractServerPredicate getPredicate() { return new AbstractServerPredicate() { @Override public boolean apply(PredicateKey predicateKey) { String targetVersion = RibbonVersionHolder.getContext(); RibbonVersionHolder.clearContext(); if (StrUtil.isBlank(targetVersion)) { log.debug("客戶端未配置目標版本直接路由"); return true; } DiscoveryEnabledServer server = (DiscoveryEnabledServer) predicateKey.getServer(); final Map
metadata = server.getInstanceInfo().getMetadata(); if (StrUtil.isBlank(metadata.get(SecurityConstants.VERSION))) { log.debug("當前微服務{} 未配置版本直接路由"); return true; } if (metadata.get(SecurityConstants.VERSION).equals(targetVersion)) { return true; } else { log.debug("當前微服務{} 版本為{},目標版本{} 匹配失敗", server.getInstanceInfo().getAppName() , metadata.get(SecurityConstants.VERSION), targetVersion); return false; } } }; } }
public class RibbonVersionHolder { private static final ThreadLocalcontext = new TransmittableThreadLocal<>(); public static String getContext() { return context.get(); } public static void setContext(String value) { context.set(value); } public static void clearContext() { context.remove(); } }
@Configuration @ConditionalOnClass(DiscoveryEnabledNIWSServerList.class) @AutoConfigureBefore(RibbonClientConfiguration.class) @ConditionalOnProperty(value = "zuul.ribbon.metadata.enabled") public class RibbonMetaFilterAutoConfiguration { @Bean @ConditionalOnMissingBean @Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE) public ZoneAvoidanceRule metadataAwareRule() { return new MetadataCanaryRuleHandler(); } }
axios.interceptors.request.use(config => { NProgress.start() // start progress bar if (store.getters.access_token) { config.headers["Authorization"] = "Bearer " + token config.headers["version"] = "v1.0" // 開發人員自己的版本標志,對應eureka metadata 配置 } return config }總結
擴展ribbon 的路由規則,根據客戶端來去不同版本的服務,也可以理解為灰度發布。
生產環境可以借助Kong、Traefik 集合zuul 來實現灰度發布
代碼請參考微服務權限框架pig的灰度發布功能,已經全部開源
關于pig:
基于Spring Cloud、oAuth2.0開發基于Vue前后分離的開發平臺,支持賬號、短信、SSO等多種登錄,提供配套視頻開發教程。
https://gitee.com/log4j/pig
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/71879.html
摘要:生產環境可以借助集合來實現灰度發布代碼請參考微服務權限框架的灰度發布功能,已經全部開源關于基于開發基于前后分離的開發平臺,支持賬號短信等多種登錄,提供配套視頻開發教程。 showImg(https://segmentfault.com/img/remote/1460000016809362); 分析下目前遇到的痛點 你在開發工作的是否遇到這個問題,微服務模塊劃分過細,基礎模塊依賴的比較...
摘要:無論如何,單元測試一直是一中非常重要卻常常被忽視的技能。在實踐中,重構的要求是很高的它需要有足夠詳盡的單元測試,需要有持續集成的環境,需要隨時隨地在小步伐地永遠讓代碼處于可工作狀態下去進行改善。 showImg(https://segmentfault.com/img/bVbttWF?w=1000&h=528); 五月初的時候朋友和我說《重構》出第 2 版了,我才興沖沖地下單,花了一個...
摘要:我不聽,我就是這么命名。任何服務啟動以后,都會把自己注冊到的注冊表中當服務死亡的時候,也會通知。服務拿到結果后,會把結果緩存在本地的注冊表里。根據負載均衡策略,從注冊表中選擇一個真正的實例地址。 原創:小姐姐味道(微信公眾號ID:xjjdog),歡迎分享,轉載請保留出處。 這幾天可真是熱啊,泡個海澡是再好不過了。玩的正起勁,突然腳底絆上一股暗流,然后我就一直在水里旋轉旋轉旋轉...終于...
摘要:洞察和監控在邊緣跟蹤有意義的數據和統計數據,以便為我們提供準確的生產視圖。壓力測試逐步增加集群的流量,以評估性能。減少負載為每種類型的請求分配容量,并刪除超過限制的請求。在路由到源之前執行,可以用于身份驗證路由和裝飾請求。 showImg(https://segmentfault.com/img/remote/1460000018826272); 簡介 Zuul是所有從設備和web站點...
閱讀 786·2019-08-30 15:55
閱讀 1529·2019-08-30 15:52
閱讀 2694·2019-08-30 15:44
閱讀 2104·2019-08-30 11:14
閱讀 2620·2019-08-29 13:59
閱讀 1816·2019-08-29 13:45
閱讀 1011·2019-08-29 13:21
閱讀 3373·2019-08-26 13:31