微服务：内部服务的安全和架构问题

Question

我正在构建一个Spring Boot微服务，有一些问题需要解决。

我有一个账户微服务，一个支付微服务，一个产品微服务...在这些微服务中，有时某些请求需要使用邮件API、短信发送API或推送通知API。

目前我做的是为邮件、短信和推送通知各创建了一个微服务。

我无法解决的问题是如何让这些微服务仅在内部使用。例如，禁止用户直接调用邮件微服务。

在将这个问题发布到stackoverflow之前，我自己思考了一下：为什么不将发送短信的代码放入库中，同样地，将发送邮件和推送通知的代码放入库中，并将它们添加到微服务中。当微服务需要使用其中之一时，我只需添加所需的库。例如，我创建一个推送通知库，并将其添加到每个需要执行推送通知的微服务中。

最好的方法是什么？如何将邮件、短信和通知服务集成到我的微服务项目中，并通过禁止用户直接使用它们来确保安全性？

我不知道该怎么办，请有人给予建议。

- user13548798

---

我认为你已经得到了答案。如果你不想让任何人使用它，为什么要创建服务呢？创建库并在你的应用程序中使用它。 - want2learn

Answer 1

• 您不必担心应用程序代码中其他微服务调用邮件微服务或sms微服务。如果您考虑这个问题，那么这适用于任何内部微服务。这个问题可以在基础设施层面处理。

• 让我举个例子，您有一个数据库在某个地方运行，您的微服务是否做了任何事情来确保它是唯一与该数据库通信的服务？答案是否定的。在基础设施层面上，无论您使用什么云基础架构，它们都允许定义安全规则/网络策略，让您定义谁可以与谁通信。即入站流量和出站流量的规则。

• 如果它们是公共面向的微服务，那就是另外一个问题了。这些是内部服务。

• 以下是一些基于基础设施的示例：

  • AWS SecurityGroups
  • AWS subnets
  • Kubernetes Network Policy

• 我还想补充一点，这可能与您的问题没有直接关系。所涉及的服务似乎是非常好的异步服务候选项。然后，没有服务直接与它们交谈，发送服务将通知放入队列或kafka主题，而这些服务从主题中消费。现在，它正在确保只有相关服务在网络级别将其发送到队列或主题。

- Kavithakaran Kanapathippillai

Answer 2

我不太清楚您所说的“禁止用户直接使用它们”的确切含义，但通常情况下，正如@kavhakaran的答案所指出的那样，您应该采取安全措施来防止服务被滥用。

在那个答案中，只关注了与网络相关的部分。还应该有第二个级别，即用户授权。这意味着您可以/应该为要保护的服务定义适当的角色和授权定义。并且根据提供的角色，您可以授权客户端使用服务。 这也是云服务通常的工作方式。您将获得一个API密钥以便使用某些云服务，他们将检查API密钥是否被授权请求的服务等。

- cool

Answer 3

我不建议在微服务中使用库来发送短信、电子邮件和推送通知。这会导致源代码级别的依赖关系，如果可能的话，我会尽量避免在微服务架构中出现这种情况。

关于您提出的架构问题： 根据我的经验，为处理诸如短信、电子邮件等通知而设置单独的服务是一个好主意，因为这样可以在微服务和第三方短信、电子邮件或推送通知服务之间创建一个抽象层。

通常，例如发送电子邮件的核心要求随着时间的推移会更多或更少保持不变。但是，您可能会遇到一种情况，即您想要将一个第三方服务替换为另一个服务——例如由于成本问题、性能问题或其他原因。

如果您选择直接与每个需要发送电子邮件的微服务通信，则在切换从一个电子邮件服务到另一个服务时，您必须适应所有这些微服务，无论您使用共享库还是每个微服务自己实现与该服务的通信。

但是，如果您有一个单独的电子邮件微服务，所有需要发送电子邮件通知的微服务都使用它，那么您只需更改电子邮件微服务本身与第三方电子邮件服务（例如 SendGrid 或 MailJet）通信即可。您的其他微服务甚至不用考虑这种变化。

关于安全方面：

正如之前提到的，如果您选择异步通信通知服务，则基础架构层面将通过允许微服务访问基于相应消息服务提供的身份验证和访问控制机制的消息传递基础设施来解决安全问题（无论是 RabbitMQ、Azure Service Bus、Kafka 还是 AWS SQS 等）。

或者，如果您选择通过 REST API 从微服务调用通知服务，您可以通过 OpenID Connect 进行基于令牌的身份验证（例如通过客户端凭据流进行机器对机器安全）。

还有一件事要考虑：

我也会考虑其他共享功能，这些功能可能适用于短信、电子邮件和推送通知服务，例如用户偏好设置 - 例如，用户想要接收哪种类型的通知。这也可能是您不希望所有微服务都了解的某些功能。因此，您可以考虑一个通知服务，该服务关注此类责任，并负责根据用户偏好通过不同类型的渠道（电子邮件、短信、推送）传递通知。或者，您可以为用户偏好设置单独创建微服务，然后由您的短信、电子邮件和推送通知微服务访问。但是，哪种选项更好并没有明显的答案，因为这在很大程度上取决于您需要处理的用例。

- Andreas Hütter