如果一个三层系统有几千客户端连接，那这个系统用什么技术好，要注意一些什么，请高手帮忙指教,分不够再加

Question

如题!

Answer 1

你看看李维的《Delphi5.X分布式多层应用》系统篇
这本书写的不错
对你应该有用

Answer 2

三层架构的特点本来就可以看作是对网络传输的一种优化
采用com或dcom就是减少了连接，而且连接是动态生成和删除的

Answer 3

我们现在用的一个三层结构应用,是完全自己开发的,以前用midas好惨啊.现在的有经过上千用户的考验,但是上万的还没有.有什么需要沟通的可以联系我:[email protected].

Answer 4

www.wyx2008.com/mxj
www.wyx2008.com.mxj/system/comm/scheme.zip中间层做负责均衡 肯定没有问题

Answer 5

你最好还是不要用delphi来做这种用户多的三层程序，特别是在互联网上的。我是深受其害的。

Answer 6

互联网上DCOM都不能用。
只能用Socket直接连接。当然Delphi有个Socket连接，做了个代理，不过性能据说不行。如果搂主恶劣一点，反正都已经作了BS版本的了，客户端？很简单啊，一个form上面放个WebBrowser，他们知道个屁。界面还完全一致呢。哈哈。要安全？用https好了。客户端上面把WebBrowser搞一下，别出提示对话框就可以了。服务器那边的IIS设定一下，遇到错误或者网页不可访问，把错误页面重定向。认真一点，又不想用webservice。那就用ASP+xml，这个方式起始和webService有啥区别呢？提交ASP页面附带查询参数，查询参数同样可以XML化的。ASP页面生成XML数据表，发送到客户端，客户端用ClientDataSet接收XML表示的数据表。其实Delphi里面本来就有XMLPrivader的。ASP+xml的这种方式还是很不错的，号称负载能力超强，CSDN就是一个例子，当然他的客户端是IE，其实没多少区别。

Answer 7

webService其实还是不错的，在公共网上面，算得上一个有超强负载能力的东西了。corba这类只能用在内部网上面，这些分布对象模型都太复杂了，而且都是面向连接的，在不稳定的公共网上面很难用。负载均衡？说起来很高深，其实也不会很高深吧，Delphi的那个负载均衡的组件其实原理十分的简单，我不知道这里有几个人认认真真地看过这些数据组件的源代码的！他怎么实现负载均衡的呢？就是有一个服务器列表，每次连接的时候，都随机抽取一个服务器连接，这样用最简单的方式又是最有效的。他在客户端实现负载均衡的。在服务器端实现负载均衡，如果你想自己写程序，原理，通常是一个代理，说到代理好像又很高深啊，其实呢，狗屁啊。用wenservice举例，你在一个前端服务器上实现一个webservice，但是这个wenservice什么都不作，仅仅转发访问，这就是一个狗屁代理了。完了你还可以吹，我这个在服务器端实现负载均衡什么的，做得好一点还可以吹啊，我这个可以热装载服务器。数据库服务器或者文件服务器的数据同步，这就不是我们可以搞定的了。还需要高速线路连接镜像服务器，要不然分开负载还不如不分呢。

Answer 8

还有所谓的对象缓冲池，象com+这样的能够在缓冲池里面游泳的对象，通常都是无状态的，他需要其他对象提供上下文支持。什么叫做无状态？说明白了，这种对象没有私有数据的，说到底根本就是一个DLL函数集合。哦，原来就是一个函数集啊，那么为什么不直接用DLL啊？原因？很简单，是VB和服务器端Script的需要，因为解释脚本的程序不能太复杂，他要用到操作系统的服务的时候，不可能让人家在脚本里面写API调用，那样就不叫做script了，他要用到系统服务怎么办？只能通过com对象（windows标准环境下）。同时，写脚本的人都比较懒散和弱智，或者说关注点不同，我们真正的程序员关心的是程序结构，他们关心的是界面和用户的需求。用起com对象都是不假思索的。所以系统颠簸的利害啊，一个对象没用到0.002秒就成了垃圾了，不搞个缓冲池的确受不了。搞个缓冲池也付出代价，这个代价就是com对象跨越进城边界的代价。所以，没有特别的必要不需要用com的时候，就别用，不管他有没有缓冲，她的缓冲永远比DLL的页面映射差很多档次的。如果，纯粹的自己开发的应用，不妨直接使用socket连接。效率肯定高，复杂性，我的感觉比用dcom和wenbservice要低得多。如果QQ也用webservice，你会不会觉得他们的程序员在犯病？当然在犯病，因为根本没必要。

Answer 9

所以，没有特别的必要不需要用com的时候，就别用，不管他有没有缓冲，她的缓冲永远比DLL的页面映射差很多档次的。如果，纯粹的自己开发的应用，不妨直接使用socket连接。效率肯定高，复杂性，我的感觉比用dcom和wenbservice要低得多。如果QQ也用webservice，你会不会觉得他们的程序员在犯病？当然在犯病，因为根本没必要。是的,现在银行,证券,网络游戏等等需要高效率的地方基本上都是 直接使用socket连接的.

Answer 10

>>>你最好还是不要用delphi来做这种用户多的三层程序，特别是在互联网上的。我是深受其害的。说说都害成啥样了???正在犹豫该怎么做....

Answer 11

dephi自带的那个Socket性能太弱了，据说问题还比较多

Answer 12

怎么我用D7自带的Socket Server就没出过问题呢，不过我现在的客户端不多，通常120个左右，最多也不超过200个  个人感觉用Delphi开发三层的C/S还是很不错的

Answer 13

请问：为什么千万不能用MIDAS呢？给个理由，你曾经做过想过的工程吗？

Answer 14

>>>你最好还是不要用delphi来做这种用户多的三层程序，特别是在互联网上的。我是深受其害的。
我们delphi做一直都好好的，没受其害啊。

Answer 15

<>其实李维的系统开发篇有问题，如果在服务器上下手，有可能达到上万客户段。
具体kan自己怎么实施了

Answer 16

我一个朋友说他们公司中间层用的是JAVA，客户端用DELPHI写的，用的是XML传输数据。
具体的我也不好多问了，现在正在研究呢。

Answer 17

我也非常想知道为什么千万不能用MIDAS呢？给个理由，你曾经做过想过的工程吗？

Answer 18

就搞webservice ，用.net 写webmethod ，delphi 访问接口调用就是了，别当作普通的c/s软件调用数据太频繁，保证读出，确认更新即可，webservice的方式还可以做成分布式的，多台webserver提供服务。

Answer 19

另外补充一点；你们原来的那套b/s的程序就可以把功能通过webservice的形式发布出来，这样server端只需要维护一套系统，client 部分只是两套UI,一个是delphi做的，一个是web。案例可以参考.net sdk 提供的Enterprise Samples 中的 Duwamish 7.0；或是倒微软msdn看看.NET PetShop（ms用.net和j2ee做比较的一个例子）。

Answer 20

你们原来的那套b/s的程序就可以把功能通过webservice的形式发布出来，这样server端只需要维护一套系统，client 部分只是两套UI,一个是delphi做的，一个是web============
我目前也是这么弄得，不过要求原来的bs程序分层要清楚，复杂的逻辑都封装，不然得重新写服务端的WebService了，不过我现在担心的是这种形式的效率如何，没经过大的压力测试。

Answer 21

压力和网站的压力差不多，看数据量和处理量了，你搞多台服务器撒；用webload测试测试不就行了；
vs.net自己都带了个Microsoft Application Center Test自己先动手才知道我们讲的对不对；

Answer 22

我目前也是这么弄得，不过要求原来的bs程序分层要清楚，复杂的逻辑都封装，不然得重新写服务端的WebService了，不过我现在担心的是这种形式的效率如何，没经过大的压力测试。///就算重写了webservice对今后的工作也是大大的有好处，原来的bs程序可以不改不升级，要升级只需要很少的程序员根据现有的webmethod做升级工作，包括今后的功能升级都好解决。

Answer 23

为什么不能用midas ？？？各位说说看？

Answer 24

千万不要用midas！严重同意。你没有发现borland没有出官方的for delphi的中间件产品吗？他自己都不用。

Answer 25

我也在用socket做三层的东西，不过还没有什么问题，不知道要注意那些东东
希望有经验的大侠指点一下

Answer 26

>>>你最好还是不要用delphi来做这种用户多的三层程序，特别是在互联网上的。我是深受其害的。
还没有能说明的材料。
没准是在欺骗民众啊

Answer 27

最好别用midas我们公司在找它的替代品。我们是做MIS系统的数据量一大起来就出现一下莫明其妙的问题，稳定性也不高。

Answer 28

很久以前用D6自带的SOCKET+Access做的三层,让access成了网络数据库, 其实在客户端也用了Midas.dll,本人觉得性能还可以, 连接数不多,20多个.

Answer 29

不知你是在什么网络环境
如果是局域网就是SOCKET:
数据库服务器->应用服务器(用SOCKET连接数据库+dbExpress,当然要做负载平衡)->客户端(用SQLConnection + ClientDataSet).一个应用服务器连接几百个客户没问题,客户端增加时就增加应用服务器的数量,非常方便.
如果是INTENET,就一定要开发WEB的B/S结构了,与上面一样,只是客户端改为Web Application Server连接至应用服务器即可,用户用IE浏览器调用.这样实际上是比上面多一层.

Answer 30

2 BlueTrees(蜗牛)
  将这些道理讲的这么简单明了，强。:D

Answer 31

midas?看你怎么用了,如果你直接用client的cds直接连接server的dataprovider,来做程序,当然不行,
但是如果你在只在服务器上公开方法,接受和返回cds的midas封包,也就是可序列化的数据,根本就不会有什么问题,李维的书上讲过这种方法(不过不是重点),看你怎么理解它,并应用它了,我甚至在一个系统中,保存了客户端传来的所有做更新的delta,相当于可以用这些delta序列重建整个数据库性能超过k级,没有过万.后台不是用的midas module,而是com+ 和Webservice(因为要在公网上跑)

Answer 32

学习.
正在将以前的C/S改成B/S,由于JSP/ASP什么的不懂,只好用INTRAWEB,基本还行,1台WEBSERV,
200-300同时在线.就是页面操作总是刷新,性能和安全性还可以.

Answer 33

用Socket作千来个连接是没什么问题的。我现在的公网服务器就是用的socket，感觉还好。不过处理上有点麻烦罢了。

Answer 34

如果直接用SOCKET连接的话,DELPHI不见得象上面所说的很差吧.可能在用INDY的时间大家都很不爽.如果只是用TCP或UDP连接,TSocketServer TSocketClient 我觉得都可以了.
在应付大用户量的时候,比如说QQ的用户,现在假设它的所有都是用TCP方式连接,每个用户都是连接到QQ服务器上,每个用户发的信息都先到服务器,然后让服务器中转.这样的系统如何设计呢?首先我声明我没有做过大用户量的,只是说说自己的想法.
假设现在只有一台服务器首先,用户列表肯定是要有的了,所有的用户信息先都是在数据库中保存,当连接上来的时候根据QQ号进行验证,如是通过则创建一个用户对象,将它的SOCKET连接保存起来,将它的在线好友在列表中的索引值也保存起来.用户发信息的时候就在它的在线好友中查找,找到则调用它的SOCKET连接将数据转过去.现在最大的问题在于当很多人同时发信息的时候数据处理的问题.当然用IO端口映射是最好的办法了,SOCKET.Read可只管将收到的包放到一个缓冲区中去,有其它的线程用先进先出的方式处理这些包.
现在最大的问题可能是数据来的非常快,系统内存一会就没有了,这现在好象没有办法解决,只能是用更大的内存和多CPU.处理包的线程将包中的目标QQ号找到后将数据发出去.
不管怎么样都没有办法解决单机1万个用户在线时系统创建1万个SOCKET连接所带来的压力和问题.只能是分而治之. 
比如一台服务器只同时最大维护5000人在线(不知WINDOWS系统的单机SOCKET连接最大支持多少个)
一台服务器只运行数据库进行验证工作,一台只管理收发数据.对数据包类型进行编号,只检查编号就完全可以确定包的内容格式,不进行字符串分解的工作.对每个客户端的说话速度进行限制.客户端做的复杂一些,可以让好友之间直接连接不用通过服务器,每个人都是一个小型的服务器,等等等等.设计的时候主要是要将网络通信,缓冲区管理,数据包分析,上层的数据库服务这几个分离开.好好优化代码.不过最后的结果是如果你稍微懂一点C的话,发现将它改动成C版本的很容易,差不多只要按句翻译就可以了.说了半天拐到C上了,其实也是,除了做有大量窗体,MDI窗体,数据库连接的程序的时候,在做后台服务程序的时候DELPHI和C没有什么差别.怎么感觉等于没说.

Answer 35

欢迎大家加入DELPHI程序员群1805366 ，一起交流技术！

Answer 36

BlueTrees(蜗牛) 强啊！

Answer 37

用 corba + 服务器服务器。
corba 跨平台的

Answer 38

corba+ unix 服务器
corba 在 internet 是没有问题的。
甚至从 internet 到你的内网也没问题。