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

Question

我正在构建一个 Spring Boot 微服务，我有一些问题

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

我现在所做的是创建一个用于邮件的微服务、一个用于发送短信的微服务和一个用于推送通知的微服务。

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

在在 stackoverflow 上创建这个问题之前，我自己搞砸了，为什么我不会将发送短信的代码放在库中，发送电子邮件和推送通知并将它们添加到微服务中也是如此。当微服务需要使用这些 api 之一我添加了所需的库.. 例如，我创建了一个推送通知库，并将它添加到需要执行推送通知的每个微服务中..

将这些邮件、短信和通知服务集成到我的微服务项目中并通过禁止用户直接使用来尊重安全性的最佳方法是什么

我不知道该怎么做，谁能给我建议？

Answer 1

好吧，我不太清楚“禁止用户直接使用它们”是什么意思，但通常正如@kavhakaran 的回答所指出的那样，您应该采取安全措施来防止您的服务被滥用。

据我所知，在该答案中，仅关注与网络相关的部分。还应该有一个关于用户授权的第二级。这意味着您可以/应该为您想要保护的服务拥有适当的角色和授权定义。根据提供的角色，您可以授权客户端使用服务。 这就是它通常也适用于云服务的方式。您将获得一个 api-key 以使用某些云服务，他们将检查 api-key 是否被授权用于请求的服务等。

Answer 2

• 您不必担心其他微服务调用应用程序代码中的mailing microservice 或sms microservice。如果您考虑这个问题，这将适用于任何内部微服务。可以在基础架构级别处理此问题

• 让我给你举个例子，你有一个数据库在某个地方运行，你的微服务是否做任何事情来确保它是唯一与该数据库对话的。答案是不。在基础架构级别，无论您使用什么云基础架构，它们都允许定义安全规则/网络策略，从而让您定义谁可以与谁交谈。 IE。传入流量规则和传出流量规则

• 如果它们是面向公众的微服务，那就另当别论了。这些是内部服务

• 一些基于基础设施的例子

  • AWS SecurityGroups
  • AWS subnets
  • Kubernetes Network Policy

• 我还想补充一点，这可能与您的问题没有直接关系。有问题的服务似乎非常适合作为异步服务。然后没有服务直接与它们对话，发送服务将通知放在queue 或kafka topic 中，这些服务从主题中消费。所以现在它确保只有相关服务将其发送到网络级别的队列或主题

Answer 3

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

关于您的问题的架构问题： 根据我的经验，使用单独的服务来处理通知（例如短信、电子邮件等）是个好主意，因为这样您在微服务和具体的通知基础架构之间创建抽象，例如第三方短信、电子邮件或推送通知服务。

通常，例如，发送电子邮件的核心要求会随着时间的推移或多或少相同。但是您可能会遇到一种情况，即出于成本考虑、性能考虑或其他原因，您希望将一种第三方服务换成另一种。

如果您选择直接与需要发送电子邮件的每个微服务的通知基础架构进行通信，那么当您从一种电子邮件服务切换到另一种电子邮件服务时，无论您使用共享库还是每个微服务都必须调整所有这些微服务自行实现与该服务的通信。

但是，如果您有一个单独的电子邮件微服务供所有需要发送电子邮件通知的微服务使用，您只需更改电子邮件微服务本身即可与之通信，例如 SendGrid 而不是 MailJet（仅举三分之二）方电子邮件服务）。您的其他微服务甚至不关心这种变化。

关于安全方面： 正如已经提到的，如果您选择与通知服务异步通信，则安全方面将在基础设施级别通过允许微服务访问基于相应消息服务提供的身份验证和访问控制机制的消息基础设施（是它是 RabbitMQ、Azure 服务总线、Kafka、AWS SQS 等）

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

需要考虑的另一件事：

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