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

Question

我正在构建一个spring引导微服务，我有一些问题。

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

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

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

在提出这个关于堆栈溢出的问题之前，我自欺欺人，为什么我不把发送sms的代码放在库中，而把发送电子邮件和推送通知的代码添加到微服务中。当一个微服务需要使用这些apis之一时，我会添加所需的库。例如，我创建了一个推送通知库，并将其添加到每个需要执行推送通知的微服务中。

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

我不知道该怎么办，有人能告诉我吗？

Answer 1

我不建议使用图书馆发送短信，电子邮件和推送通知跨越您的微服务。这将导致对源代码级别的依赖，如果可能的话，我将在Microservices体系结构中尽量避免这种依赖。

关于您问题的体系结构问题，：根据我的经验，有单独的服务来处理诸如sms、email等通知是个好主意，因为这样您的就可以在您的和具体的通知基础结构(如第三方sms、电子邮件或推送通知服务)之间创建一个抽象。

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

如果您选择直接与需要发送电子邮件的每个Microservice的通知基础设施进行通信，则无论您是使用共享库还是每个Microservices都单独实现与该服务的通信，当您从一个电子邮件服务切换到另一个邮件服务时，您将不得不调整所有这些Microservices。

但是，如果您有一个单独的电子邮件微服务，用于所有需要发送电子邮件通知的Microservices，您只需更改电子邮件微服务本身以与之通信，例如SendGrid而不是MailJet (只需列出两个第三方电子邮件服务)。您的其他Microservices甚至都不关心这种变化。

关于安全方面()：如前所述，如果您选择与通知服务异步通信，则将在基础设施级别解决安全性问题，允许微服务基于相应消息传递服务(无论是RabbitMQ、Azure Service Bus、Kafka、AWS等)提供的身份验证和访问控制机制访问消息传递基础设施。

或者，如果您选择通过Microservices中的REST调用通知服务，则可以通过OpenID连接查看基于令牌的身份验证(例如，通过客户端凭据流进行机器对机器安全)。

还有一件事要考虑

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

Answer 2

• 您不应该担心其他微服务在应用程序代码中调用mailing microservice或sms microservice。如果您考虑到这个问题，这将适用于任何内部镜像服务。这个问题可以在基础设施级别处理。
• 让我举个例子，你有一个运行在某个地方的数据库，你的微服务做了什么来确保，它是唯一一个和那个数据库交谈的人。答案是否定的。在基础设施级别，无论您使用什么云基础设施，它们都允许定义安全规则/网络策略，这允许您定义谁可以与谁交谈。即。输入流量规则和传出流量规则
• 如果他们是面向微观服务的公众，那就是另一个问题了。这些都是内部服务
• 基于基础设施的一些示例

- [ AWS SecurityGroups ](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)
- [ AWS subnets ](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html)
- [ Kubernetes Network Policy ](https://kubernetes.io/docs/concepts/services-networking/network-policies/)

• 另外，我想补充一点，这一点可能与你的问题没有直接关系。所讨论的服务作为异步服务似乎是非常好的候选对象。然后，没有服务直接与他们交谈，发送服务将通知放在queue或kafka topic中，这些服务从主题中消耗。因此，现在它正在确保只有相关的服务才能将其发送到网络级别的队列或主题。

Answer 3

我不太清楚你所说的“禁止用户直接使用”是什么意思，但正如人们所指出的那样，通常情况下，你应该采取安全措施来防止你的服务被滥用。

在那个答案中，据我所见，只有网络相关的部分是集中的。还应该有关于用户授权的第二个级别。这意味着您可以/应该对您想要保护的服务具有正确的角色和授权定义。根据提供的角色，您可以授权客户端使用这些服务。这通常也适用于云服务。您将获得一个api密钥，以便使用一些云服务，并且他们将检查api密钥是否被授权用于所请求的服务等。