我无法理解Tibco的特别之处.
他们的营销材料强调TCP是一种悲观的传输协议,不需要客户确认收据.这怎么可能是真的？
对我来说,Tibco基本上是一个由队列支持的TCP协议.
有人可以帮我理解Tibco的主要卖点吗？我即将对我的经理咆哮,告诉他我们在这里完全被扯掉了.
我假设您将使用RV(Rendezvous),因为这是他们的主要消息传递协议.
这是一种基于UDP的类似广播的协议,它比TCP更快,但仍然不一定具有客户端确认.
它有支持它的配置(认证消息),所以无论是TCP还是UDP,它都取决于你想要用它做什么.
Tibco(BusinessWorks)增加的价值在于它提供了一个简单,直接的中间件应用程序设计器,使得在负载平衡和容错环境中部署应用程序变得简单.它为您提供各种连接器(soap,http,jdbc,jms等)以连接您需要的东西并吐出许多不同的格式.
如果我们有更多关于你将使用它的东西的信息会有所帮助.
PS.而不是RV,请使用EMS(JMS实现).
RV与EMS:
RV是UDP,EMS是TCP
RV是分散的:每个主机上都有一个rv客户端.非常适合有多个收件人的广播消息.除非你使用'远程守护进程',否则你的消息包含在你的class-c子网中,没有单点故障或瓶颈,
EMS在特定服务器上集中(中心和辐射),并且可以遍历子网没有问题.
EMS受SPOF限制,但您可以成对集群服务器以消除此问题.
对于1-1或1-2,EMS更好,但RV对于1-many更好
增加的值应该是"可靠的多播"和平台独立性.整个架构与rvd在一切的中间是有点愚蠢,所以在我看来你被扯掉,就像我们在这里,以及其他人付钱:)
好问题 - 但你有没有试过通过TCP套接字连接500个消费者？
如果您的消息速率也很高(> 10k msgs/sec),您最终将使用UDP(一条消息发送给所有消费者,而不是副本!).但是你没有TCP的可靠性,这是PGM或TRDP的用武之地.有了这样的要求,我发现TIBCO RV非常有用/我所知道的最好.C API非常快(如果你的速度超过10k msgs/sec,请忘记Java).
当然,您可以使用自己可靠的多播,但RV API使用起来非常简单,并且可以移植到许多不同的平台上.我想简单的使用是反对TCP的主要论据.教一个初级程序员如何编写稳定且有效的RV pub/sub应用程序需要一天的时间,用TCP做一个月也需要一个月.
rvd本身只是坐在那里看不见,所以你为什么要担心呢？
如果扇出不是问题(1-1甚至1-5场景),请查看TIBCO EMS(或其他JMS提供商)或者AMQP.
与TCP相比的另一个真正优势是主题(或JMS主题).如果要集成20个不同的应用程序,这会有很大帮助.
这取决于你是谁以及你的目标是什么.我对TIBCO的熟悉之处在于,它是我们金融服务行业的许多竞争对手使用的消息传递系统,可以将来自基于Web的前端的消息安全地发送回大型机进行处理,并向我们的前端提供股票报价等内容.
我们有自己的消息传递产品与消息传递产品有着奇怪的相似之处,我们公司以前的一位高层人员曾在这里工作过:)
我们有3亿技术预算,但请记住,我们还有2个大型数据中心和几个生产中心,以及3个开发办公室.
现在,在我们的情况下,一家公司可能会发现开箱即用TIBCO这样的东西是很划算的(我们可能已经节省了大量的3亿美元).
如果你没有那种预算而且你的要求要少得多,那么对你来说它可能确实是一个"扯掉".但是,为了自己开发这种系统,对于像我工作过的那样的组织......我敢肯定它会占用这3亿的大部分.
京公网安备 11010802040832号 | 京ICP备19059560号-6 