通过 IIS ARR 的客户端关联/粘性会话是不是适用于 ASP.NET Core 3+/.NET 5？

Posted 2023-02-19

【中文标题】通过 IIS ARR 的客户端关联/粘性会话是不是适用于 ASP.NET Core 3+/.NET 5？

【英文标题】：Does Client Affinity / Sticky Session via IIS ARR work with ASP.NET Core 3+ / .NET 5?通过 IIS ARR 的客户端关联/粘性会话是否适用于 ASP.NET Core 3+/.NET 5？

【发布时间】：2021-10-19 20:02:39

【问题描述】：

有一个 ASP.NET MVC 5 应用程序（它使用 Entity Framework 6.0、.NET 4.6.1 依赖项，它同时利用 MVC 控制器和 API 控制器，最重要的是）它依赖于 IIS 通过 ARR 提供会话粘性的能力。有时这也称为客户端关联，如果我没记错的话，IIS ARR 会使用 cookie 来实现它。 ARR 功能对于该应用来说是必不可少的，没有它就无法使用。

如果这样的项目升级到 ASP.NET Core 3.1+（甚至 .NET 5），我还没有找到任何具体证据，那么 ARR 还能像以前一样工作吗？ .NET Core 在架构上与 .NET MVC 5 非常不同，并且希望提前为任何意外做好准备。除了 Azure 之外，是否有任何云平台可以提供 Azure WebApps 可以通过 IIS + ARR 提供的同等功能？

---

顺便说一句，我高度不建议任何人开发任何依赖粘性会话或客户亲和力的解决方案。理想情况下，webapp 请求/响应代码应该是无状态的，因为在水平扩展的情况下，请求应该能够随机路由到任何服务器。

粘性会话路由也可能很昂贵（我的意思是金钱），具体取决于提供者（幸运的是 IIS ARR 是免费的），而且它还会损害负载分配。

【参考方案1】：

Client Affinity in IIS 用于负载平衡/流量路由，因此这就是您的服务器场将路由重定向到节点的方式。这意味着您在后端拥有什么并不重要，因为一旦启用，带有这些 cookie 的请求将始终命中同一个节点。

比如Kubernetes有类似的概念

如果您想确保来自特定客户端的连接是 每次传给同一个Pod，可以选择会话亲和性 基于客户端的IP地址通过设置 service.spec.sessionAffinity 到“ClientIP”（默认为“None”）。 您还可以通过设置来设置最大会话粘性时间 service.spec.sessionAffinityConfig.clientIP.timeoutSeconds 适当地。 （默认值为 10800，结果为 3 小时）。

你也可以对AWS做同样的事情

     
    "Attributes": [
       ...
        
             "Key": "stickiness.enabled",
             "Value": "true"
          ,           
          
              "Key": "stickiness.lb_cookie.duration_seconds",
              "Value": "86500"
          
          ,
       ...
      ]
   

所以再一次，会话关联性用于将请求路由到您的节点，与后端技术无关，但老实说，我会避免使用它，因为您可能会遇到一些可扩展性问题，或者至少将这些会话配置为较短。

【讨论】：

哦，是的，我有点含糊，因为 ARR 是 IIS 配置的一部分。一般来说，客户端亲和性是一种请求路由功能。我在受您影响的问题中添加了一些免责声明。感谢您提供有关 AWS 客户端关联的指针。基于 IP 与基于 cookie 的亲和力略有不同 (***.com/a/1040063/292502)。您知道 ARR 在 .NET Core 3.1+ 上是否可以正常工作吗？

@CsabaToth 再次与 .net 无关。 .net 处理请求它并不关心。

@CsabaToth 所以正在做的就是假设我是你的应用程序用户，如果我得到那个 cookie 并且我的请求是从 node1 提供的，那么所有其他请求都将提供给同一个 node1（一段时间) 所以你 node1 可以拥有 .net, php 重要的是它总是去 nodeX

好吧，所以答案是它应该可以工作

@CsabaToth 是的