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