安全服务是微服务架构中的单点故障吗？答案

【问题标题】：Is a security service a single point of failure in a microservice architecture?安全服务是微服务架构中的单点故障吗？
【发布时间】：2016-12-07 21:11:34
【问题描述】：

我正在开发一个具有微服务架构的应用程序。每个微服务都可以为自己而活，与系统中的其他微服务没有直接依赖关系。在每个微服务中，我们都使用 CQRS 和事件溯源来通知服务中的状态变化。如果其他服务有兴趣并能够更新其数据，则其他服务会收到这些事件的通知。

到目前为止，该系统运行良好。如果一个微服务出现故障，其他微服务仍在工作。被中断的服务重新启动后，它会接收在它不在时发生的所有事件，并根据这些事件更新自己的状态。

现在我们需要保护我们的服务，为此我们使用 IdentityServer。我们还有一个服务，我们的安全服务，它将被其他微服务调用以获取令牌。这是微服务第一次必须直接与另一个微服务通信。

我对这种方法的问题是，如果安全服务器宕机，整个系统就会宕机。

我正在考虑以下解决方案：

每个微服务都应该将用户数据保存在自己的数据库中。如果用户访问微服务，则用户在服务内部进行身份验证，而无需远程调用安全服务。我仍然应该有一个安全服务来管理用户。对用户的更改将再次引发事件，其他微服务可以更新其用户数据。当然，一切都使用 https。也许为了减少冗余代码以确保安全，我可以使用 nuget 包。

你认为这是一个合理的方法吗？

感谢您的建议

【问题讨论】：

标签： security event-sourcing

【解决方案1】：

您的解决方案将引入用户数据可供攻击者使用的风险，该攻击者破坏了任何微服务，而不是一个特定的安全服务。我认为这是一个显着的差异，也是您可能不想接受的风险。

请注意，虽然使用类似于 OAuth2 / OpenID Connect 的 SSO 解决方案，但不需要每个微服务（Service Povider，SSO 中的 SP）为每个请求连接到安全服务（身份提供者，IP）。一旦客户端（作为微服务消费者的客户端）从 IP 获得令牌，就可以在独立于 IP 的 SP 上验证令牌（例如通过公钥加密）。这意味着如果 IP 关闭，将不会发布新的访问令牌，但已经发布的访问令牌将继续工作，并且微服务不一定直接相互通信，只能通过它们的消费者。

【讨论】：

我明白你的意思。出于性能原因，很高兴知道这一点。但是我最初的整个系统都依赖于一项服务的问题仍未解决。所以你告诉我，使用这种架构的每个人都必须承受这种风险？甚至Netflix？
显然@Illiakaill 我打败了我，但他是对的（赞成！:)），您仍然可以将身份提供者分发到任意数量的节点，并创建适当的高可用性任何其他情况。因此，当谈到“一个特定的”安全服务时，这就是它的逻辑级别，它可以（并且应该）仍然是 HA 中的多台物理计算机。
我同意，但是这些服务不应该共享一个数据库吗（因为它们是同一个安全服务的实例）？那不还是单点故障吗？
数据库也有HA。 :) SQL Server 的镜像、日志传送、Always On，但其他（严重的）数据库也支持高可用性。

【解决方案2】：

您的解决方案建议跨多个微服务复制 IdentityServer 的逻辑和状态。您可以通过在多个地理分布的地方创建多个 IdentityServer 实例以将故障风险（HA 集群）降至最低，从而以更优雅的方式实现基本相同的目标。您将通过在多个服务中复制此逻辑（甚至通过重用 NuGet 包）引入更多风险。您仍然必须将那个 nuget 东西连接到每个微服务中，对吗？这是一种可能的错误来源。

正如Gabor 在他的回答中提到的那样，这将增加危及用户数据库的风险。

如果您担心在部署新版本的 IdentityServer 后会发生错误，您可以通过在部署到生产之前在暂存环境中对其进行更彻底的测试来解决这个问题。

【讨论】：