json - 在微服务中使用 json Web token 进行 session 管理

Question

我正在尝试弄清楚如何在微服务架构中使用 json Web token 来管理 session 。

看看这个 article 中的设计我目前的想法是客户端将发送一个首先通过防火墙的请求。该请求将包含防火墙发送到授权服务器的不透明/引用 token 。授权服务器使用包含用户所有 session 信息的值 token 进行响应。然后，防火墙将请求与值 token 一起传递给 API，然后值 token 将传播到满足请求所需的所有不同微服务。

我有 2 个问题:

1. 应如何处理值(value) token 中 session 信息的更新？详细来说，当 token 中的 session 信息更新时，需要在授权服务器中更新它。每个更改 token 的服务都应该与授权服务器通信吗？
2. 所有微服务都应该使用这个单一 token 来存储其 session 信息吗？或者每个服务都有一个个性化的 token 会更好吗？如果是后者，请说明如何调整设计。

Answer 1

这种设计的一个非常(!)重要的“美中不足”...这需要您提前仔细思考...是:“准确地什么意味着' session 的信息。”在这种架构中，“每个人都在与其他人赛跑。”如果 session 信息被更新，您不会并且基本上无法(!)知道哪些代理知道该更改，哪些代理不知道。更复杂的是，新请求异步到达，并且会以不可预测的方式与其他请求重叠。

因此，授权服务器必须是这样的……仅此而已。它验证不透明 token (验证...)，并提供请求授权执行的操作的可信描述。但是，它所蕴含的信息基本上是无法改变的。具体来说，它无法保存该术语的网络服务器意义上的“ session 状态”数据。

每个微服务提供商都必须维护自己的“托管板”*(我的术语......“Web 服务器中自己的特定子集将是“ session 池””)，这是可取的但其董事会独立于其他人并不总是可行。几乎可以肯定，它必须使用中央数据库(带有事务)来与其他类似情况的服务提供商进行协调。尽管如此，如果事实是这些“手提包”中的任何一个的内容与其他任何一个“手提包”都存在因果关系，那么它们之间现在就存在不同步的问题。

尽管微服务架构具有一定的学术吸引力，但恕我直言，必须仔细研究设计，以确保它们实际上与这种方法兼容。