C#消息总线(ESB)的问题

问题描述

NET下的消息总线(ESB)都有什么组件,哪个更好一些?要免费的,或开源的。

解决方案

解决方案二:
ESB叫企业总线吧……
解决方案三:
你们写啥代码都靠从网上找个开源么?相信高大上的东西,你们只用十分之一。尽量先自己研发点东西吧,毕竟都是开发人员而不是搞运维的。
解决方案四:
时光倒退到3年前,这类中间件的东西还能卖40万,但是只有一些公司将此类产品卖给国营大公司,即使是只用到十分之一、但是国营单位有的是钱。我们当初要研发一个大型集团的最顶级的系统,想过要扯上这种东西,但是事实上用不着花这种力气——只要有两个好点的程序员自己按照自己适用的需求来设计研发就好了。可是最近3年,随着互联网公司全都走向正规的集群化的系统,基本上所有的大公司都有这类东西。但是这种东西卖不出价钱了,因为互联网公司都是喜欢免费使用国外的开源产品然后自己公司再给重新命名。对于大多数中小型公司,这种东西就好像是“外来的和尚会念经”,主要还是那些“博士”用来忽悠人用的。
解决方案五:
引用3楼sp1234的回复:

时光倒退到3年前,这类中间件的东西还能卖40万,但是只有一些公司将此类产品卖给国营大公司,即使是只用到十分之一、但是国营单位有的是钱。我们当初要研发一个大型集团的最顶级的系统,想过要扯上这种东西,但是事实上用不着花这种力气——只要有两个好点的程序员自己按照自己适用的需求来设计研发就好了。可是最近3年,随着互联网公司全都走向正规的集群化的系统,基本上所有的大公司都有这类东西。但是这种东西卖不出价钱了,因为互联网公司都是喜欢免费使用国外的开源产品然后自己公司再给重新命名。对于大多数中小型公司,这种东西就好像是“外来的和尚会念经”,主要还是那些“博士”用来忽悠人用的。

这也是中国特色之一啊
解决方案六:
在关注ESB,坐看大牛评论。
解决方案七:
如果你确实自己研发,可以讨论一下其核心,可以对比一下一些开源系统的性能和核心功能。这种系统的核心相当简答。如果只是要找一个开源的然后在上面改成“自己公司的”东西,那么我可能无能为力。
解决方案八:
引用6楼sp1234的回复:

如果你确实自己研发,可以讨论一下其核心,可以对比一下一些开源系统的性能和核心功能。这种系统的核心相当简答。如果只是要找一个开源的然后在上面改成“自己公司的”东西,那么我可能无能为力。

敢问,大牛认为的其核心是?
解决方案九:
引用3楼sp1234的回复:

时光倒退到3年前,这类中间件的东西还能卖40万,但是只有一些公司将此类产品卖给国营大公司,即使是只用到十分之一、但是国营单位有的是钱。我们当初要研发一个大型集团的最顶级的系统,想过要扯上这种东西,但是事实上用不着花这种力气——只要有两个好点的程序员自己按照自己适用的需求来设计研发就好了。可是最近3年,随着互联网公司全都走向正规的集群化的系统,基本上所有的大公司都有这类东西。但是这种东西卖不出价钱了,因为互联网公司都是喜欢免费使用国外的开源产品然后自己公司再给重新命名。对于大多数中小型公司,这种东西就好像是“外来的和尚会念经”,主要还是那些“博士”用来忽悠人用的。

本来就想找个研究一下,可以不说这么多不,以教导人的口气说教别人。

时间: 2024-09-12 16:25:29

C#消息总线(ESB)的问题的相关文章

消息总线扩展之面向消息的数据集成

最近一段时间,我在琢磨消息总线除了能进行受管控的消息通信之外,还有哪些可以扩展的方向.这篇文章我们来探讨一下面向消息的数据集成是否可以作为一种尝试方向. 相关技术简介 XML 谈到XML我们的第一映像就是用它来做各种配置,当然如果你是Javaer,那么可能你印象最深的就是Spring的bena配置了.其实,XML的用途远不止充当配置文件这一方面.它还被广泛应用于异构系统集成.数据集成.语义/协议转换等等方面,甚至成为构建平台非常重要的基石.虽然XML一直以来被人诟病其解析效率低下以及数据量太冗余

消息总线扩展之集成Thrift-RPC

本文主要探讨了消息总线支持Thrift RPC的实现过程.鉴于RabbitMQ官方的Java Client提供了基于RabbitMQ的JSON-RPC,消息总线也顺道提供了JSON-RPC的API.然后也尝试了为消息总线增加对Thrift-RPC的扩展支持,希望此举能让消息总线同时为SOA提供基础设施. Thrift简介 Thrift是一个跨语言的服务部署框架,最初由Facebook于2007年开发,2008年进入Apache开源项目.Thrift通过一个中间语言(IDL, 接口定义语言)来定义

消息总线扩展之主动转发

问题简述 消息总线目前为Java编程语言提供了SDK,同时针对其他语言提供了一个称之为httpBridge的http代理.这基本可以满足大部分主流编程语言对消息总线的使用需求,但这也仅仅是对技术层面上的需求的满足.在业务层面上,尤其是面对老的业务系统的适配一直都是个难题,这篇文章谈谈面对一个在线上运行的业务系统,如何使得引入消息总线的总体成本尽可能得低. 就消息总线的两种使用方式而言,无论是SDK的方式还是httpBridge的方式,都需要往第三方系统引入对消息总线的依赖,这些依赖包括但不仅限于

消息总线优化之PubSub

近段时间,暂缓了消息总线feature的开发,花了部分时间对原先的pubsub机制进行了针对性的优化与重构.这里记录一下优化的过程以及相比原来的设计有哪些改观. PubSub在消息总线内部的作用 PubSub在消息总线内部主要用于对所有在线客户端进行实时管控的作用.每个客户端在使用消息总线时,都"被迫"注册到PubSub上,并"被迫"订阅了一些Channel,以便消息总线管控台实时下发一些管控指令及时生效. 之前的设计回顾 这里有必要回顾一下之前的设计.消息总线内部

消息总线重构之EventBus

最近花了不少时间对消息总线进行了重构.重构的重点是在消息总线中加入了Guava的EventBus,并应用于以下两个场景: (1)改进广播通知 (2)业务逻辑串联,用事件驱动替代责任链模式 EventBus简介 EventBus是Google的开源项目Guava里的一个组件,有兴趣的人可以看我前不久的一篇博文解读.总得来说,EventBus是观察者模型的实现,利用它你既可以实现观察者模型的业务场景,还可以基于它的事件驱动机制来实现应用程序内组件之间的解耦与通信. 改进广播通知 广播通知是消息总线提

再谈消息总线客户端的多线程实现

上次我谈了最近在写的一个基于RabbitMQ的消息总线的客户端在面对并发问题时的一些思考以及最终的实现方案.那是一种简单并且不容易产生并发问题的方案,如果你看过那篇文章,我曾在最终的实现方案之后给出了其利弊分析. 核心的问题是Client建立的跟RabbitMQ Server的connection是共享还是独占.对于这个问题可以举一个通俗一点的例子:如果你想要租间房子,每个人会有不同的想法.比如有人喜欢简单.安静的生活并且在意个人隐私,那么这个时候你最好的选择就是去租个单室套:里面什么都有,并且

谈消息总线客户端的多线程实现

最近在实现一个基于RabbitMQ的消息总线.因为它提供了Client(客户端),这里就牵扯到凡是技术组件的client都无法回避的并发问题.本文借实现消息总线的client谈谈在实现过程中的想法以及最终的处理方式,当然这些都不仅仅适用于消息总线的client,其他通用组件的client也同样适用. 并发问题的分类 其实上面所提到的并发问题,从大的层面上可以划分为两类问题: 自身固有的并发问题:这个存在的前提条件是client自身内部使用了多线程技术,并且本身就存在线程安全的缺陷. 被动调用的并

谈消息总线的路由模型

最近在写一个基于RabbitMQ的消息总线.虽然RabbitMQ提供了plugin的机制可以实现对其进行扩展,但是由于对erlang语言不熟,考虑到上手成本高,因此放弃实现plugin,转而基于Smart client + 树形拓扑路由的模型.当然这也大大降低了我们实现功能的灵活性,后面我会找个时间开篇新文章,谈谈Smart Client的限制. 预备知识 RabbitMQ对于消息的通信只提供了几个非常简单的API:Channel#basicPublish:Channel#basicConsum

消息总线授权设计

我曾在之前的一篇文章中对比过消息队列跟消息总线.它们其中的一个不同点就是:消息总线更关注通信安全,消息总线可以管控通信双方,对通信的管控是建立在授权的基础上.因此授权模型的设计是消息总线必须考虑的问题.所谓的授权,就是校验通信双方有没有建立可信任的通信关系.这篇文章我们来谈谈消息总线的权限设计. 消息总线使用场景及RabbitMQ通信简介 在介绍授权设计之前,我们先了解一些必要信息.通常我们将消息总线应用于以下这些场景: 缓冲类--自生产自消费 解耦类.异步类--生产者消费者模型 服务调用类(R