一个服务作为Rabbitmq的生产者和消费者是错误的吗？
Is it wrong for a service to be producer and consumer of Rabbit MQ?
我想创建一个“通知微服务”来处理不同类型的通知（Google 聊天、电子邮件等）。
对于此任务，我们将创建一个微服务，其中包含有关如何处理这些消息的逻辑，并且我们将使用 Rabbit MQ 来管理队列。
现在，我的问题是，是否可以（或者这是一种不好的做法）像这样在微服务中公开两个端点：
registerNotification('channel', $data)
processNotification(Rabbit Message)
所以我只需要在一个服务中实现与 RabbitMQ 的通信，其他服务将只使用相同的服务注册消息，而不是直接与 RabbitMQ 通信。
这样对于每个通道，我都可以在服务中验证我在排队消息之前拥有我需要的一切。
这是个好方法吗？
我建议将您的问题分成两个单独的问题。像往常一样，这取决于……两者各有利弊。低于我的观点而不要求完整性。最终评估这些确实取决于您的具体需求。
1) 在消息队列（此处为 RabbitMQ）之前使用通知/事件网关是一种好习惯吗？
优点：
- 对消息结构/正确性实施强有力的保证
- 如果需要，提供高级身份验证/授权机制
- 如果您的技术栈中的语言缺乏 first-class 客户端支持，请提供便利
- 从服务（发布者）中抽象/封装技术选择和部署注意事项
- 消除来自各个服务的消息的路由逻辑（尽管，使用 RabbitMQ 中可用的路由拓扑，这里很难看到任何附加值）
缺点：
- 可用性成为您网关的一个关键问题，例如假设您可以保证每个服务的正常运行时间为四个九，那么通过添加此依赖项，您已经将组合系统的正常运行时间降低到三个九
- 增加了操作复杂性
- 增加延迟
这里的另一种考虑可能是使用库来实现上述一些优点。不过，这种方法也有其缺点。
2) 运行 消息发布者和消费者在一项服务中是一种好的做法吗？
优点：
- 快速（快捷方式？）
- 最初部署的实例较少（直到您必须扩大规模）
缺点：
- 生产者和消费者（工人！）的操作要求通常非常不同
- 更难（也更昂贵）以充分和细粒度地扩展系统
- （性能）指标变得难以解释
- 消费者可能会对生产者延迟产生负面影响，因为一切都在争夺相同的资源
- 消费者方面失去灵活性（快速、低风险部署）
- 更难保证生产者的可用性
我希望这有助于根据您自己的需求/优先级更好地评估您的架构。
我想创建一个“通知微服务”来处理不同类型的通知（Google 聊天、电子邮件等）。
对于此任务，我们将创建一个微服务，其中包含有关如何处理这些消息的逻辑，并且我们将使用 Rabbit MQ 来管理队列。
现在，我的问题是，是否可以（或者这是一种不好的做法）像这样在微服务中公开两个端点：
registerNotification('channel', $data)
processNotification(Rabbit Message)
所以我只需要在一个服务中实现与 RabbitMQ 的通信，其他服务将只使用相同的服务注册消息，而不是直接与 RabbitMQ 通信。 这样对于每个通道，我都可以在服务中验证我在排队消息之前拥有我需要的一切。
这是个好方法吗？
我建议将您的问题分成两个单独的问题。像往常一样，这取决于……两者各有利弊。低于我的观点而不要求完整性。最终评估这些确实取决于您的具体需求。
1) 在消息队列（此处为 RabbitMQ）之前使用通知/事件网关是一种好习惯吗？
优点：
- 对消息结构/正确性实施强有力的保证
- 如果需要，提供高级身份验证/授权机制
- 如果您的技术栈中的语言缺乏 first-class 客户端支持，请提供便利
- 从服务（发布者）中抽象/封装技术选择和部署注意事项
- 消除来自各个服务的消息的路由逻辑（尽管，使用 RabbitMQ 中可用的路由拓扑，这里很难看到任何附加值）
缺点：
- 可用性成为您网关的一个关键问题，例如假设您可以保证每个服务的正常运行时间为四个九，那么通过添加此依赖项，您已经将组合系统的正常运行时间降低到三个九
- 增加了操作复杂性
- 增加延迟
这里的另一种考虑可能是使用库来实现上述一些优点。不过，这种方法也有其缺点。
2) 运行 消息发布者和消费者在一项服务中是一种好的做法吗？
优点：
- 快速（快捷方式？）
- 最初部署的实例较少（直到您必须扩大规模）
缺点：
- 生产者和消费者（工人！）的操作要求通常非常不同
- 更难（也更昂贵）以充分和细粒度地扩展系统
- （性能）指标变得难以解释
- 消费者可能会对生产者延迟产生负面影响，因为一切都在争夺相同的资源
- 消费者方面失去灵活性（快速、低风险部署）
- 更难保证生产者的可用性
我希望这有助于根据您自己的需求/优先级更好地评估您的架构。