我正在使用微服务架构开发应用程序。每个微服务都可以独立存在，与系统中的其他微服务没有直接的依赖关系。在每个微服务中，我们使用CQRS和事件源来通知服务中的状态变化。如果感兴趣并且能够更新他们的数据，其他服务会被告知这些事件。
到目前为止，该系统运行良好。如果一个微服务中断，其他微服务仍在工作。在中断的服务将再次启动后，它将接收在其缺席时发生的所有事件，并将根据这些事件更新其自己的状态。
现在我们需要保护我们的服务，我们正在使用IdentityServer。我们还有一项服务，我们的安全服务，其他微服务将调用它来获取令牌。这是微服务第一次直接与另一个微服务器通信。
我的问题是，如果安全服务器关闭，整个系统都会关闭。
我正在考虑以下解决方案：
每个微服务都应该将用户数据保存在自己的数据库中。如果用户访问微服务，则在服务内部对用户进行身份验证，而无需远程调用安全服务。我仍然应该只为管理用户提供安全服务。对用户的更改将再次引发事件，其他微服务可以更新其用户数据。当然一切都用https。也许为了减少冗余代码的安全性，我可以使用nuget包。
你认为这是一种合理的方法吗？
感谢您的建议
答案 0 :(得分：1)
您的解决方案会为攻击者提供用户数据的风险，这些攻击者会破坏任何微服务，而不是一个特定的安全服务。我认为这是一个重大差异，也是您可能不想接受的风险。
请注意，虽然使用类似于OAuth2 / OpenID Connect的SSO解决方案，但每个微服务（SSO中的Service Povider，SP）都不需要为每个请求连接到安全服务（身份提供商，IP）。一旦客户端（作为微服务的消费者的客户端）从IP获得令牌，就可以在SP上独立于IP验证令牌（例如，通过公钥加密）。这意味着如果IP已关闭，将不会发布新的访问令牌，但已发布的令牌将继续有效，并且微服务不一定只能通过其消费者直接相互通话。
答案 1 :(得分：1)
您的解决方案建议跨多个微服务复制IdentityServer的逻辑和状态。您可以通过在几个地理位置分散的位置创建IdentityServer的多个实例来以更优雅的方式实现相同的功能，以最大程度地降低故障风险（HA群集）。 通过在多个服务中复制此逻辑（即使重用NuGet包），您将引入更多风险。你仍然需要将这个nuget东西连接到每个微服务中，对吧？这是一个可能的错误来源。
同样在他的回答中提及Gabor，这将增加危害用户数据库的风险。
如果您担心在部署新版本的IdentityServer后可能发生错误，您可以在部署到生产之前通过在临时环境中对其进行更全面的测试来解决此问题。