我有一个工作的单体应用程序(部署在容器中)，我想为它添加通知功能作为一个单独的微服务。
我计划让单体将事件发送到消息总线(RabbitMQ)，在那里它们将被新服务接收，并将通知发送给用户。为了编写通知，它将需要来自monolit的关于用户的其他信息，因此它将调用monolit的REST API来获取它。
问题是，访问单体的API需要以令牌的形式进行身份验证。我在想:- 使用来自单体的秘密来发出一个永不过期的令牌——从安全的角度来看，我认为这不是一个好主意，而且我也知道有时密钥会旋转，在这种情况下，令牌最终会失效
- 使用消息总线来检索信息——这似乎也不是一个好主意，因为异步将使它非常复杂
- 在事件中提供通知服务所需的所有信息——这将使它们更加耦合在一起，而且，我还计划根据未被事件 触发的单体上的状态发送通知。
- 从单体中删除身份验证并以不同的方式实现它(尚不确定如何实现)
我的问题是，有哪些好的方法可以解决这类问题，而且，刚刚开始学习微服务，我首先要做的是什么?
在处理内部安全性时，您应该始终考虑部署以及API如何暴露给外部世界，可以使用API网关来简单地使访问内部API成为不可能。在这种情况下，固定令牌可能足以确保客户端被授权。
一般来说，我建议考虑OAuth2或基于jwt的解决方案，因为它有助于验证调用系统的身份以及它们的访问授权。
对于您的架构疑问，您需要在构建解决方案时考虑以下场景:
- 远程调用可能在任何时候因未知原因失败，因此在确定通知已被成功处理之前，不应该确认通知事件。
- 正如你提到的RabbitMQ，你的目标应该是保持通知队列尽可能小，为了达到这个效果，一个包含用户详细信息的缓存可能有助于加快事情的进行(并帮助你减少由于外部系统不可用而导致的失败的机会)。
- 如果您的应用程序向潜在的数百万不同的用户发送大量通知，您可以考虑拥有一个用户的只读数据库副本，该副本可以被通知服务访问，并直接从数据库集群批量读取。这减少了单体上的负载，并将其转移到数据库层