楼主可以再深入描述一下，业务的细节，这样其他人可以给更好的建议。 另外，想请教一下 "一致性哈希以达到 对于特定的 URL 的请求，固定转发到唯一的副本。" 这个需求，在扩容或缩容之后，如何保证之前的请求，依然分流到之前的副本？

@ser3w 是的这个我也有查到，但是这个只针对单个 url 生效（即 wx_upstream 是一个 url ），无法对 upstream 生效，根据 nginx 的说法的话 https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass

@justdoit123 > 业务的细节，这样其他人可以给更好的建议 这个说来话长了，关键词是 协同编辑、websocket 之类的。最开始制定技术方案的时候定下来的这个需求。 > 如何保证之前的请求，依然分流到之前的副本 我们目前也在考虑这块问题

反正都 hardcode 的 nginx config, 即是 3 個副本是固定數量的。 1 的 504 問題很簡單, 三個副本獨立各自有 ClusterIP 的 service 即可解決問題, ClusterIP 是固定 IP 不會跟隨 Pod IP 變動。 2 的 hash 問題, 我是用 Istio 解決的, Istio 有自己的 resolving 機制不跟隨 k8s services 做法, 它會自行更新 Pod IP 比較有彈性。

@eephee 大部分网关都提供 url 对下游服务器的配置，kong 还提供 route by header 功能，我们一般都是用 service 作下游服务，lz 这种指定 pod 方式比较少见，但是依然可以通过 ip 的方式配置。 @eephee 自己配 nginx 有点难以维护，用现成的网关服务还能通过 API 动态配置

@eephee 要是需要 url 亲和性的话我建议你上网关 apisix 之类的，nginx 不好维护， 但如果你把 有状态的 3 副本应用调整为 3 个单副本的 deployment + 3 个 svc 就可以实现你这种，不过有点麻烦了

@eephee 按你的描述，感觉应该先解决这个分布式有状态扩缩容问题。 然后你这个问题可能就不是什么问题。