c# - Rabbitmq .net 实现的架构指南

Question

我正在寻找一些实现指南。使用 wcf 绑定(bind)或使用普通的 vanilla .net rabbitmq api 的优缺点是什么。是我们不被限制使用的那一刻。我是rabbitmq的新手，但是做了一堆wcf。

我们有一个产品可以从每台设备上的发布者那里收集信息。该产品位于防火墙后面(目前)。发布者将需要 3-4 个 channel 。

请求/响应发布指标以在服务器上发布/订阅，并使用来自服务器的 ack。

更新 channel ，以更新发布者规则库以从服务器发现度量标准。

用于检查服务器的心跳 channel 已启动并响应服务器心跳。

可能的死信 channel 。

发布者将是跨平台的。考虑在 Mono、Linux、BSD、Solaris、Android、MacOs、iOS 以及可能的 Aix/HP-UX 上托管。不知道 wcf 端点在这些情况下的效果如何。

服务器将有多个 worker ，每个 worker 都从自己那里收到相同的消息？排队，确认并根据自己的规则库进行处理。我希望 worker 是事件驱动的。服务器需要高性能，每分钟 10k 到 100k+ 条消息。从发布者到服务器不会丢失任何消息。

我倾向于使用普通 api，因为它在线程/序列化/ session 管理/安全/压缩等方面提供了更大的灵 active ，但产品可能会转移到 Azure 并作为 SaaS 或 PaaS 提供，并且拥有 wcf 端点会很有意义在开/关窗口上与出版商交谈，但这将是长期的。

Answer 1

软件架构是关于推迟决策，而不是提前做出决定。
随着项目的进展，您使用的绑定(bind)应该相对容易更改。由于它们是实现细节，因此在代码中定义清晰、简洁和简单的接口(interface)很重要，因此您自己的这些服务代码依赖于它的抽象(您定义的接口(interface))，而不是具体的实现(代码使用绑定(bind)，以及经纪人说 amqp 的事实)。
选择现在最有意义的实现(牢记迁移到 Azure 的计划)，但不要与之结合。