关于接口程序的思索:如何设计一个通用的接口服务器(200分)

  • 主题发起人 主题发起人 pxlei
  • 开始时间 开始时间
P

pxlei

Unregistered / Unconfirmed
GUEST, unregistred user!
大家晚上好!我现在在寻思设计一个通用的接口服务器,功能就是:
(1):接受socket数据包,进行处理,之后答复。
(2):要求接口服务器能承受很大的压力测试(最多可能一分钟上千笔交易)
(3):要求当服务器压力太大,转其他服务器处理----交易转发,负载平衡。
我现在的思路: 利用socket 和 corba 来实现,但我对corba不了解,到底C++Builder
的Corba还是Delphi的Corba还是JBuilder的Corba编程方便,正统。而且,希望大家对
我的接口提出意见,谢谢!
 
俺也在作类似的东西,不过没有你的那么复杂,你的业务量是来自大量的连接还是来自少量的连接?
 
可以使用 DCOM + MTS 、 MSMQ , 不必对TCP/IP协议编写程序, DCOM 完全可以
实现远程接口的调用,而且与协议无关。 MSMQ可以解决消息队列问题,其处理
肯定要比自己针对 IP 编程要好的多 ....
 
战鹰:如果我没猜错的话,你的客户主要是电信行业的用户.我的接口有两种:
(1):少数连接,但业务量巨大,一分钟上千笔。
(2):大量连接,但每笔业务量相对少,一分钟大约10笔。

OopsWare:DCOM我可能不会采用,考虑到需要的情况下,我需要在UNIX下开发服务,可
能我的客户端使用Corba(基于Windos),但服务端利用Corba(基于UNIX)
MSMQ我会考虑,但哪儿能找到免费的呢?或许你能提供好的线索。
如果我不使用TCP/IP的话,对方发送的Socket包我该如何处理呢。



 
我想是采用硬件实现,比如交换机一样,分离到2台server上,然后再对每个server就象代理一样,
进行处理,处理是另外的server,
连接-----------------{硬件}------server1--------{处理器一,处理器2}
|
server2---------------{处理器3,处理器4}
 
负载平衡:可以采用 SCO UnixWare7.1 + NonStop Cluster 的集群方案。
MQ: 可以使用 IBM 的 MessageQueue


世上没有免费的“午餐”!(Linux下就不一定了)
 
通用的结果就是效率不高,
 
以前电信在处理话费计费时是采用磁带机做记录,次日再用另一台计算机读带
将通话记录记入数据库的,以解决业务量较大时,数据库不能实时处理的问题。
现在的计费好像是实时的了。
 
你说的东西正是我现在正在作的,不过我希望用JAVA来实现!
希望能够实现你说的两种模式!企图用DELPHI搞一个原型具体应用用JAVA来做!
是不是有点本么倒置?没办法这年月JAVA的产品比较吃香!
 
>(3):要求当服务器压力太大,转其他服务器处理----交易转发,负载平衡。
>我现在的思路: 利用socket 和 corba 来实现,但我对corba不了解,到底C++Builder
>的Corba还是Delphi的Corba还是JBuilder的Corba编程方便,正统。而且,希望大家对
>我的接口提出意见,谢谢!

我的想法是通知客户端服务器压力过大,请他连接其他的服务器!然后返回一个服务器
地址列表,然后切断连接!
 
to pxlei :
我觉得你这个想法非常的好,我也有类似的想法。你的意思是建立
分布式的服务器系统作为一个大服务器对外运行,以保证服务器的可靠性
是吧?然后内部服务器间交互采用CORBA而对外部应用还是采用普通的
socket通信?
在这点上我的想法是,不采用CORBA开发,因为我觉得
CORBA在思想上比在工具上有着更重要的意义。而且CORBA
的使用必定是以牺牲效率为代价的,我觉得完全可以使用SOCKET实现
内部的分布式服务吧,也许这样性能会好点?
这是我的一点点看法而已:)
 
我也曾经想过SOCKET来实现,而且也做过一些,但在大数据量下很容易系统出错,导致服务器崩溃.
我觉得corba是很好的一门东东.
我的思想是这样: 对于多用户的连接,采用corba技术,客户端是基于corba技术的客户,
服务器是一个corba服务器.
 
说说我的具体想法,大家看看有什么意见?
前端是一个负载均衡服务器,
根据来源的IP地址和访问的端口来以及现有的连接状况来判别将连接连的后台的哪个服务器上,
实际上是一个相对智能化的端口映射,我认为这个在技术上比较容易实现。
后台有若干台应用服务器,服务程序采用一个通用的SOCKET服务程序,根据不同的服务需求使
用不同的IP和端口,类似现有的WEB虚拟主机!也比较容易实现!

数据包的处理采用另外调用的插件形式,一种方式采用可执行文件,数据的传输采用输入输出的
重定向,速度比较快开发也比较简单,但是对于频繁产生的数据库调用似乎比较讨厌!另外一
种方式采用类似ISAPI的方式一次装入内存长时间运行,数据传输的方式还没有想好!

由于俺的应用领域里经常遇到专用的通讯协议,和很多应用所以我希望能够建议一个通用的平台
从而减轻应用产品的开发时间!

大家多提意见!
 
to 站鹰:
有关负载均衡是在多处理器服务器上实现的,操作系统会依据各处理器的IDLE情况
协调CPU处理事务,靠用户的应用去分析有些多此一举[:(!]
目前的网络速度越来越快,百兆、千兆以不再希奇,所以IP的通讯不是需要考虑的
重点。关键是随数据库尺寸的剧增,需要重点考虑数据库中表的容量超过百万行的数
量级时,数据库的效率问题。正因为此,分布式数据库、数据库仓库的概念才被提出。
数据库也由一开始的分散渐渐集中,现在又开始分散....
有关“通用性”也早有相应的概念和现行的软件,例如“中间件”,ODBC,BDE就是
雏形,ADO更加明显,Unix下开发中使用到的 Tuxedo 也是级好的例子。
我从开始就不建议使用Socket的方法编程,没有RFC的支持,“通用”根本不可能。
我是建议大家先研究使用一段时间成型的产品,再在这方面下功夫。否则只是闭门造车。
 
有关 Tuxedo 的信息可参考 BEA 的本产品主页
http://www.bea.com/products/tuxedo/index.shtml
 
to OopsWare,
这是一个应用领域的问题!可能是pxlei和我有相同的处境,我的情况是有两个客户使用不同的通讯协议,
而且通讯协议的细节还有可能根据用户的地区性而有所变化,但是往往需要做相同的应用产品,而且都可以
提供从互联网的接入方式,为了后期应用产品开发上的方便,所以我才有了这种想法,至于数据库你说
的没错,但是那已经是数据库是应用开发的内容了!
因为客户提供的接入服务器暂时还没有负载均衡的能力,所以目前只能自己提供!
通用的SOCKET服务程序只是负责根据不同的通讯协议对数据进行解包和打包,

如果我的那两个水火不容的客户可以共同制定一个协议,我想提交给RFC也是没有问题的,但是怎么可能
呢?不然我费这个事干什么?
 
我曾经见过的一个产品是这样的:多个基于socket通信的服务器,相互间通过发布信息来达到负载
平衡。而且交易不是很大的情况下,没有问题(这个交易大约是每分钟50笔),没有任何问题。
后来交易达到每分钟100多笔了,服务器经常响应不过来(日常交易3秒钟能响应,现在有时需要10秒)
而且负载平衡不太好。
 
我认为通过不是通过专门的负载均衡服务器来实现负载均衡是没有实际意义的!
因为如果某台服务器因为工作超载而导致死机同样会导致客户端软件的连接失败!
如果客户端软件能够提供自动的负载均衡那么最好!如果不能最好有一台负责协调
的服务器,如果不能计算每台服务器的实际业务负载,可以先考虑采用连接负载,
也就是说均衡服务器始终将新近输入的连接分配给连接数量最小的服务器!
 
后退
顶部