Rabbitmq .net 实施的架构指南
我正在寻找一些实施指南。使用 wcf 绑定或使用普通 .netrabbitmq api 的优点和缺点是什么。是我们不受限制使用的时刻。我是rabbitmq的新手，但是做了一堆wcf。
我们有一个产品可以从每台设备上的发布商那里收集信息。该产品位于防火墙后面（目前）。发布商将需要 3-4 个渠道。
- 请求/响应发布指标以通过服务器的确认在服务器上发布/订阅。
- 更新通道，以更新发布者规则库以从服务器发现指标。
- 用于检查服务器是否启动并响应服务器心跳的心跳通道。
- 可能的死信通道。
发布者将是跨平台的。考虑在 Mono、Linux、BSD、Solaris、Android、MacOs、iOS 以及可能的 Aix/HP-UX 上托管。不知道 wcf 端点在这些情况下有多有效。
服务器将有多个工作人员，每个工作人员都从自己那里接收相同的消息？排队、确认并根据自己的规则库处理它。我希望工作人员是事件驱动的。服务器需要高性能，每分钟 10k 到 100k+ 消息。从发布者到服务器的消息不会丢失。
我倾向于使用普通 api，因为它在线程/序列化/会话管理/安全/压缩等方面提供了更大的灵活性，但该产品可能会转移到 Azure 并作为 SaaS 或 PaaS 提供，并且拥有 wcf 端点是有意义的在开/关窗口上与出版商交谈，但这将是从长远来看。
I'm looking for some implementation guidance. What are the pro and cons of using the wcf bindings or using the plain vanilla .net rabbitmq api. Are the moment we are not constrained to use either. I new to rabbitmq, but done a bundle of wcf.
We have a product which collects info from publishers on each device. The product is behind the firewall (at the moment). The publisher will need 3-4 channels.
- Request/Response to publish the metric to publish/subscribe on server with ack from server.
- Update channel, to update publisher rulebase for metric discovery from server.
- Heartbeat channel to check server is up and respond to server heartbeat.
- Possible dead letter channel.
Publisher will be cross platform. Thinking of hosting on Mono, on Linux, BSD, Solaris, Android, MacOs, iOS, and possibly Aix/HP-UX. Don’t know how effective wcf endpoints would be in these instances.
Server will have multiple workers, each receive same message from own? queue, ack it and process it against their own rulebase. I would like the workers to be event driven. Server needs to be high performance, 10k to 100k+ messages per minute. No messages can be lost from publisher to server.
I’m swinging towards using the plain api as it offers more flexibility as regarding stuff like threading/serialization/session management/security/compression but the product may be moved to Azure and offered as SaaS or PaaS, and having wcf endpoint would make sense to talk to publishers on both on/off windows, but that would be in the longer term.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
软件架构的目的是推迟决策，而不是提前做出决策。
随着项目的进展，您使用的绑定应该相对容易更改。由于它们是实现细节，因此在代码中定义清晰、简洁和简单的接口非常重要，因此您自己的这些服务代码取决于它的抽象（您定义的接口），而不是具体实现（代码使用绑定，并且代理使用 amqp 的事实）。
选择现在最有意义的实现（记住您迁移到 Azure 的计划），但不要与它结合。
Software Architecture is about deferring decisions, not making them upfront.
The bindings you use should be relatively easy to change as your project progresses. Since they are an implementation detail, it's important that you define clear, concise and simple interfaces in your code, so your own code for these services depend on an abstraction of it (the interface you define), not on the concrete implementation (the code that uses the bindings, and the fact that the broker speaks amqp).
Choose the implementation that makes most sense now (keeping in mind your plans on moving to Azure) but do not marry to it.