我有一个微服务架构，现在我需要引入一个通知中心。要求是：任何服务都能够发送通知，任何服务都能够订阅任何类型的通知，UI(web(能够订阅通知(首选websockets(。当然，我可以自己编写这样的服务，但也许有现成的强大解决方案。
UPD：我不是在寻找发布/订阅消息传递系统，因为它对于通知中心来说太低级了
您正在寻找的是发布订阅者消息传递。如果您使用的是 AWS 堆栈，那么我可以推荐 Amazon SNS 或 Amazon SQS。我认为Amazon SNS更合适，因为它是基于推送的。
Amazon SNS允许应用程序通过"推送"机制向多个订阅者发送时间关键型消息，无需 定期检查或"轮询"更新。
Amazon SQS是分布式应用程序用于通过轮询模型交换消息的消息队列服务，并且可以 用于分离发送和接收组件，无需 每个组件要同时可用。
在亚马逊网络服务堆栈之外，有一堆免费的消息传递解决方案：
RabbitMQ是AMQP协议(与Apache Qpid一起(的主要实现之一。因此，它实现了代理 体系结构，这意味着消息在中心节点上排队 在发送给客户之前。这种方法使 RabbitMQ 变得非常容易 使用和部署，因为路由、加载等高级方案 只有少数几个支持平衡或持久消息队列 代码行。但是，这也使其可扩展性降低且"速度较慢" 因为中心节点增加了延迟并且消息信封相当 大。
ZeroMq是一个非常轻量级的消息传递系统，专为高吞吐量/低延迟方案而设计，例如您可以在 金融界。Zmq 支持许多高级消息传递方案 但与 RabbitMQ 相反，您必须实现其中的大部分 通过组合框架的各个部分(例如：套接字( 和设备(。
ActiveMQ处于中间地带。与 Zmq 一样，它可以与代理和 P2P 拓扑一起部署。像 RabbitMQ 一样，更容易 实现高级方案，但通常以原始数据为代价 性能。
现在您知道自己需要什么，我建议您通读每种技术一段时间，并确定哪一种更准确地满足您的目标。如果这不值得我们花时间，并且您的要求更具体且相对较小，那么您可以自己编写一些东西。