【问题标题】:Container to Container Networking and Sticky Session容器到容器网络和粘性会话
【发布时间】:2021-03-29 20:48:24
【问题描述】:

我有一个在 Cloud Foundry 上运行的两个应用程序的设置。应用程序 G 用作公共路由的反向代理。具有内部路由的应用程序 A 在 G 之后运行。容器到容器网络已在 G 和 A 之间设置。现在由于扩展,A 有多个实例。我需要 A 的粘性会话。但问题是 C2C 网络不通过 Go 路由器,所以让 A 设置 JSessionID cookie 在这里不起作用。如何使粘性会话发生?

【问题讨论】:

    标签: cloud-foundry


    【解决方案1】:

    您的应用程序的流量将如下所示:

    Browser -> load balancer -> Gorouter -> App G (reverse proxy) -> App A
    
    1. 如果 App A 将 cookie JSESSIONID 设置为它的 session cookie,那仍然会触发 Gorouter 的粘性会话支持,但是,它只会应用于 App G,在这种情况下并没有真正的帮助。

      如果您将来横向扩展 App G,这也是您需要考虑的事情,因为您可能不希望或不需要它,因为您的反向代理不会在会话中存储状态。您可以通过使用 JSESSIONID 以外的其他内容作为会话 cookie 或让反向代理重写会话 cookie 名称来更改此行为。

    2. 就应用 A 的粘性会话支持而言,您需要配置反向代理,即应用 G 来执行此操作。你如何做到这一点取决于你的反向代理,你没有在原始帖子中指定。查看有关您的反向代理的文档,了解有关启用“会话持久性”或“粘性会话”支持的说明。

    【讨论】:

    • App G 基于 Spring Cloud Gateway。问题是如何让 Spring Cloud 网关知道将请求转发到 App G 的哪个实例。
    • 同样对于 App A,一个请求登录并在实例 A1 上创建会话,但下一个请求可能会发送到不与 A1 共享会话的实例 A2,因此将 cookie JSESSIONID 更改为不同的 cookie 名称在这里没有帮助。
    • 最好的情况是使用共享会话状态(Redis/Geode/etc..)。然后你就不必担心粘性会话了。我相信您可以使用 Gateway 进行粘性会话,尽管我自己没有这样做。查看github.com/spring-cloud/spring-cloud-commons/issues/689docs.spring.io/spring-cloud-commons/docs/current/reference/html/…
    猜你喜欢
    • 2020-06-05
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2016-02-27
    • 1970-01-01
    • 2019-03-07
    • 2022-01-04
    相关资源
    最近更新 更多