我正在使用 Ribbon/Eureka/Hystrix 和 Zuul 開發(fā)微服務(wù)架構(gòu)，一切正常。但是當我們使用微服務(wù)時，我們可以根據(jù)需要擴展我們的微服務(wù)，并擁有相同微服務(wù)的不同實例。目前，負載均衡在一個 Zuul 實例、不同的 Eureka 實例作為集群以及不同的 μservices 實例上運行良好。問題是：我可以定義多個 Zuul 實例嗎？如果是的話，Zuul 是不是可以使用不同的端口訪問，并且正在失去發(fā)揮其優(yōu)勢的反向代理角色？因為現(xiàn)在，我認為它是單點故障和潛在瓶頸。有人可以解釋一下如何避免這個問題嗎？
2 回答
蝴蝶不菲
TA貢獻1810條經(jīng)驗 獲得超4個贊
上面的答案是有效的。您還可以Zuul通過注冊多個實例并將它們放在cloud-based load-balancer諸如 之AWS ALB后來避免成為瓶頸，這將擴展以滿足流量需求。
一只名叫tom的貓
TA貢獻1906條經(jīng)驗 獲得超3個贊
我可以定義多個 Zuul 實例嗎？
在我看來，您可以而且實際上應(yīng)該為使用 spring-cloud 構(gòu)建的復雜微服務(wù)系統(tǒng)定義多個實例。
Zuul 不能使用不同的端口訪問并且正在失去發(fā)揮其優(yōu)勢的反向代理角色嗎？
分布式系統(tǒng)中的多個實例可能會增加容錯能力，并且可以在你的微服務(wù)器系統(tǒng)中處理更復雜的路由，如果你設(shè)計的話，它的強度沒有太多關(guān)聯(lián)。（可能我只是誤解了 OP 的意思？）
我認為zuul的角色就像是一個軟件API網(wǎng)關(guān)的微服務(wù)，不僅代理，但身份驗證，動態(tài)路由，安全......在春季云起動，Netflix的-zuul，它擁有Ribbon和Hystrix依賴于負載均衡和斷路器. Zuul 是 spring-cloud 的 mircoservice 解決方案的一部分，交易網(wǎng)關(guān)的工作就像普通網(wǎng)絡(luò)網(wǎng)關(guān)一樣。
認為很難回答說 Zuul 是（或不是）瓶頸。問題的重點是How to avoid network-gateway becoming a bottleneck什么？
添加回答
舉報
0/150
提交
取消