我們通過在eureka服務註冊中心中註冊了多個實例來擴展系統中的所有服務。擴大zuul代理
此外,它們也由前面的zuul服務器代理。
我的問題是我們如何確保從客戶端訪問zuul代理的可擴展性。
我能想到的一個解決方案是在尤里卡註冊表中註冊了多個代理實例。但是如果這樣做了,我們如何決定哪些實例會暴露給客戶端。
我們通過在eureka服務註冊中心中註冊了多個實例來擴展系統中的所有服務。擴大zuul代理
此外,它們也由前面的zuul服務器代理。
我的問題是我們如何確保從客戶端訪問zuul代理的可擴展性。
我能想到的一個解決方案是在尤里卡註冊表中註冊了多個代理實例。但是如果這樣做了,我們如何決定哪些實例會暴露給客戶端。
我們在我們的應用程序中面臨同樣的問題,在我們的後端有多個類型的微服務類型應用程序的多個實例。所有在Eureka註冊的服務器。問題在於我們也配置了多個安全網關(基於此優秀教程中描述的體系結構:https://spring.io/guides/tutorials/spring-security-and-angular-js/)。
最終我們決定使用硬件http負載均衡器,以循環方式調用我們的安全網關(我們的解決方案在本地)。
我們使用Redis和@EnableHttpRedisSession註釋使Spring會話跨所有服務器同步,因此http負載均衡器不必處理粘滯會話或有狀態注意事項。它只是對所有安全網關進行循環。無論負載均衡器是否達到SG1,SG2或SG3,它們都共享來自Redis的相同會話信息(也配置爲使用Redis Sentinel進行故障切換)。
在某些時候,您將需要像BigIP或甚至Web服務器這樣的負載平衡器 - 在nginx中配置負載平衡非常容易。 – freakman