Ben*_*Ben 5 messaging soa http rabbitmq redis
我们正在研究使用面向服务的体系结构(SOA)来拆分我们的体系结构(以及添加新组件).将有一些外部API将由第三方使用,我们将使用REST HTTP接口,但我想知道什么是最好在内部使用,因为所有组件都在我们的控制中,并将在相同的网络,但可能是不同的技术(主要是.net和ruby on rails).
使用消息传递系统(redis,rabbitmq,EMS,其他值得注意的例外,我没有听说过......)而不是HTTP(REST,SOAP等)会有很大的性能/功能提升.
我很难找到关于这个主题的好信息(正如你可能会说的)我对这个方面很新,所以任何建议或好资源都会受到赞赏!
Thnaks
消息传递往往会为您提供更松散耦合的体系结构.它也可能更强大,因为单个组件可能会在不破坏整个基础架构的情况下发生故障.
缺点是复杂性,范式转向异步模型,以及可能的性能(特别是如果你在每个地方都持久化消息).
您还需要确保您的邮件系统特别健壮.逻辑的一个方面可以在不影响所有内容的情况下关闭并重新启动,但如果丢失了核心消息库,那么所有逻辑都将停止等待消息传递备份.
幸运的是,消息总线可以长时间运行而无需人类摆弄和触摸它,这是任何系统中最大的错误和不稳定来源.
除了@Will Hartung所提到的,我还会说这取决于你将如何处理你的系统.如果您主要拥有客户端 - 服务器类型的应用程序,而您的服务器/服务很少,而且它们往往是完全独立的,那么通过REST over HTTP实现服务合同可能会更容易.
另一方面,如果您的整个系统正在进行双向通信,或者有许多进程间调用(特别是如果系统中的每个参与者在某个时刻都将成为客户端和服务器),然后发消息是你最好的选择.在消息传递选项中,我发现AMQP/RabbitMQ是功能最丰富且易于使用的所有这些选项.它为您提供了一个真正的异步编码平台.
使用消息传递的关键好处是您可以为每种类型的消息设置队列,因此当您的系统扩展和更改时,队列/消息可以是相同的,但处理它们的服务可以在下面更改.它促进了层的分离.
最后,在我看来,这是一个巨大的事情,正确使用消息传递促进了小的,独立的代码片段.它们更易于测试且更易于维护,并且通常可以简化您的企业架构.如果您尝试从HTTP端点处理太多服务,您最终(在一两年内)最终将得到(1)太多端点以跟踪或(2)不可维护的意大利面条代码.
我的公司开始使用基于消息的框架,它对我们来说非常有效.RabbitMQ服务器很容易成为最可靠的组件.如果您对消息传递或SOA有任何疑问,请随时询问.
| 归档时间： |
|
| 查看次数： |
1900 次 |
| 最近记录： |