我正试图弄清楚我将如何在微服务架构中使用json web令牌管理会话。
查看本文中的设计，我目前想到的是客户端将发送一个首先通过防火墙的请求。此请求将包含防火墙发送给授权服务器的不透明/引用令牌。授权服务器使用一个值令牌响应，其中包含用户的所有会话信息。然后防火墙将请求与值令牌一起传递给API，然后将值令牌传播到满足请求所需的所有不同微服务。
我有两个问题:- 如何处理值令牌中会话信息的更新?更详细地说，当令牌中的会话信息更新时，它需要在授权服务器中更新。每个更改令牌的服务都应该与授权服务器通信吗? 所有的微服务都应该使用这个令牌来存储他们的会话信息吗?或者每个服务都有一个个性化的令牌会更好吗?如果是后者，请说明如何调整设计。
这种设计的一个非常(!)重要的"美中不足"…这需要你事先仔细考虑……正是在‘session’信息.”在这个体系结构中，每个人都在与其他所有人竞争。如果会话信息是更新的，那么您不会也基本上无法知道哪个代理知道该更改，哪个代理不知道。更复杂的是，新的请求是异步到达的，并且会以不可预测的方式与其他请求重叠。
因此，授权服务器必须完全是…再也没有了。它验证(authenticates…)不透明令牌，并提供关于授权执行的请求的可信描述。但是，它所包含的信息基本上不会改变。具体来说，它不能保存会话状态web服务器意义上的数据。
每个微服务提供商必须维护自己的“tote板”*(我的任期……它自己在web服务器中的特定子集(会话池)，并且它的董事会将独立于其他董事会是理想的但并不总是可行的。几乎可以肯定的是，它必须使用一个中央数据库(带有事务)来与其他类似位置的服务提供者进行协调。然而，如果事实是，这些内容中的任何一个都是;如果它们之间存在因果关系，那么它们之间就会出现不同步的问题。
虽然微服务架构有一定的学术吸引力，但IMHO设计必须仔细研究，以确保它们实际上与这种方法兼容。