我正在构建一个Spring Boot微服务，我有一些疑问
我有一个帐户微服务，一个支付微服务，一个产品微服务...在这些微服务中，某些请求有时需要使用邮件api，短信发送api或推送通知api。
我现在要做的是创建一个用于邮寄的微服务，一个用于发送短信的微服务和一个用于推送通知的微服务。
我似乎无法解决的是如何使这些微服务仅在内部使用。例如，禁止用户直接调用邮件微服务。
在对stackoverflow创建此问题之前，我不明白自己的原因，为什么我不将用于发送短信的代码放在库中，而将电子邮件和推送通知发送到微服务的代码也是如此。需要使用这些api之一，我添加了所需的库..例如，我创建了一个推送通知库，然后将其添加到每个需要进行推送通知的微服务中。.
将这些邮件，短信和通知服务集成到我的微服务项目中，并通过禁止用户直接使用它们来尊重安全性是什么？
我不知道该怎么办，有人可以建议我吗？
答案 0 :(得分：2)
您不必担心其他微服务会在应用程序代码中调用mailing microservice或sms microservice。如果您考虑到此问题，则这将适用于任何内部微服务。这种担忧可以在基础架构级别得到解决
让我举个例子，您有一个数据库正在某个地方运行，微服务是否可以做任何事情来确保它，这是唯一与该数据库进行通信的数据库。答案是不。在基础架构级别，无论您使用什么云基础架构，它们都可以定义安全规则/网络策略，从而使您可以定义可以与谁对话的人。即。传入流量规则和传出流量规则
如果它们是面向公众的微服务，那就是另一个问题。这些是内部服务
一些基于基础架构的示例
我也想补充一点，可能与您的问题没有直接关系。所讨论的服务似乎是异步服务的很好候选者。然后，没有服务直接与他们对话，发送服务将通知放在queue或kafka topic中，这些服务从主题中消耗。因此，现在可以确保只有相关服务将其发送到网络级别的队列或主题
答案 1 :(得分：2)
对我来说，“禁止用户直接使用它们”是什么意思，但这并不是很清楚，但是通常，正如@kavhakaran的回答指出的那样，您应该采取安全措施来防止服务受到滥用。
在该答案中，据我所知，仅与网络相关的部分被关注。还应该有一个关于用户授权的第二层。这意味着您可以/应该为要保护的服务具有适当的角色和授权定义。根据提供的角色，您可以授权客户端使用服务。 这通常也适用于云服务。将向您提供一个api-key以便使用某些云服务，他们将检查api-key是否被授权用于所请求的服务等。
答案 2 :(得分：1)
我不建议使用库在您的微服务之间发送短信，电子邮件和推送通知。这将导致对源代码级别的依赖，如果可能，我会尽量避免在微服务体系结构中使用。
关于您问题的建筑问题： 根据我的经验，最好有单独的服务来处理短信，电子邮件等通知，因为这样，您在微服务和具体的通知基础架构之间创建了抽象，例如第三方短信，电子邮件或推送通知服务。
通常，随着时间的推移，例如发送电子邮件的核心要求或多或少是相同的。但是您可能会遇到想要将第三方服务换成另一种服务的情况-例如由于成本问题，性能问题或其他原因。
如果您选择从每个需要发送电子邮件的微服务直接与通知基础结构通信，则无论您使用共享库还是每个微服务，当您从一种电子邮件服务切换到另一种电子邮件服务时，都必须适应所有这些微服务。自行实现与该服务的通信。
但是，如果您有需要发送电子邮件通知的所有微服务使用的单独的电子邮件微服务，则只需更改电子邮件微服务本身即可与之通信，例如SendGrid而不是MailJet（仅三分之二）电子邮件服务）。您的其他微服务甚至都不关心该更改。
关于安全方面： 如前所述，如果您选择与通知服务异步通信，则将允许微服务基于相应消息服务提供的身份验证和访问控制机制访问消息基础结构，从而在基础结构级别解决安全方面的问题。它RabbitMQ，Azure服务总线，Kafka，AWS SQS等）
或者，如果您选择通过微服务中的REST API调用通知服务，则可以通过OpenID Connect（例如，用于机器对机器安全性的客户端凭据流）研究基于令牌的身份验证。
要考虑的另一件事：
我还会考虑其他共享功能，这些共享功能可能是短信，电子邮件和推送通知服务所共有的功能，例如用户首选项-例如用户想要接收哪种通知。这也可能是您不希望所有微服务都知道的某些功能。因此，您可以想到一个与这种责任有关的通知服务，并负责根据用户的喜好通过各种渠道（电子邮件，短信，推送）传递通知。或者，您可以为用户首选项设置单独的微服务，然后通过短信，电子邮件和推送通知微服务进行访问。但是，对于哪个选项更好，没有明显的答案，因为这在很大程度上取决于您必须处理的用例。