[转贴]对Borland 和 N-TIER的牢骚

本贴原处http://borland.mblogger.cn/catchbug/posts/2927.aspx

对Borland 和 N-TIER的牢骚

对Borland 和 N-TIER的牢骚

昨天我转贴了我的好友SMARTKID 同学的一篇抨击 瘦客户的文章，SMARTKID同学从是否具有实际应用价值
和合理性的角度分析了瘦客户在企业应用上的合理性和可行性
今天我再次发表我对BORLAND MIDAS中间层的严重不满.
我们都知道DELPHI 有开发N-TIER 程序的本事,但是我想没有几位系统分析人员去仔细考虑这种架构在实际应用上的利弊和限制
现在浮躁的系统分析员太多了。众多高手都去跟踪各种趋势，忙于将自己的应用程序升级为各种最新的架构。却很少去深入探讨最新
架构的本质。众多高手都在探讨各种模式，研究如何编程方便，却很少去分析自己辛苦作出来的程序之寿命.
难道我们写程序,研究各种技术潮流仅仅是为了做出来没有应用价值的程序?
返回正题,继续说 N-TIER  和Midas
李维大师的 DELPHI5 多层开发.... 一书中，曾做过一项对比DCOM 和 SOCKET CONNECTION的
书中写到， DCOM 的连接速度较SOCKET CONNECTION 慢， 但是连接完成后， 传输数据较SOCKET
CONNECTION 要快。 并做了一些测试数据比较时间快慢。 在这里，我不得不说的是， 上面的比较
是完全没有意义的， 测试出来的数据也是没有意义的。
why?  下面是本人的观点.
DCOM Connection的缺点是网络穿透性， DCOM Connection 是针对 Windows 工作组开发的小型连接方式
 并不支持tcp/ip 网络, 不支持网关. 考虑到未来的网络应用将走向远程, 大型应用的趋势,DCom Connection
是一种被淘汰中的产品(也许已经被淘汰了, 我很少见到有人用这种连接方式开发 n-tier程序)
 
MS 这两年也没有再去发展 DCom ， 从这个角度来说, DCom  被MS 淘汰了, 2000年以后 MS就投身 web service
的炒做去了
Web Connection 好产品吗?  我们为什么要用 WebConnection 呢?  难道就是为了穿透各种网关?
我们都知道, Web Connection 通过80端口的http传输躲过了网关， 但是其带来的负面影响就是
企业应用程序执行效率的大幅度下降,  您的应用程序在客户那里刚刚运行时， 也许效果不错，您
是否考虑过1，2年后， 客户服务器中的数据巨增， 查询出来的数据结果集动辄数M大小， 而我们还不得不
用HTTP流而不是节约带宽的二进制流来传输， 想到此， 您是否还要考虑被热炒的先进的XML格式传送数据结果
我不敢， 我那尊贵的客户的服务器里现在已经有10G 数据了， 未来的3-5年里， 估计要增加到30－40G.
我可不想3，5年后， 客户给我打电话要我去改程序.
Socket Connection 是一种好产品吗?  从以往的应用需求和未来的应用前景来说, 是的.
tuxedo 就是这么做的，至今还在赚大钱.
但是BORLAND 在设计 Socket Connection 架构上设计的过于草率和马虎. 直接造成了 socket connection 的
先天不足.   分析Borland 为 socket connection 提供的 socket server 源码后， 你会发现,这个要求高性能
的产品竟然用的是 异步select 网络模型.  这个模型的最大缺陷是为每一个客户机连接都要建立一个线程,
更为恐怖的是, 客户机与服务器之间交流的消息是通过 ms windows上最不可靠的消息来传递的.
我做一个简单的流程图也许能更形象的表达这种架构.
客户端发起连接请求 - > 服务器 ------------------------------------------------------------->
                                服务器建立连接线程,为这个客户连接创建专有的RemoteModule 服务器

客户端要求服务器执行一个方法，查询一个数据 -> 服务器socket -> 发送windows消息到 socketserver主线程->
服务器上客户连接线程分拣消息 - > 分析数据包,找出客户要求执行的接口方法 -> com服务器,执行方法->
传回第一个数据包到客户端-> 客户端发送响应给服务器 ->  服务器socket -> 发送 windows 消息到 socketserver主线程
.............................
这个模式有两大弊端:
1: 连接数限制
在这个运行模式下,如果windows 系统连接线程数超过200， 效率将大幅度下降, windows将大量工作时间应付连接线程的上下文
切换. 随着连接的增加，cpu占用率将快速增长.
2: 数据包传输的性能和可靠性
一般来说,windows 网络的上， tcp/ip协议最佳传输数据包的大小是 4k(与winnt 的4k 内存分页有关)
那就是说如果从服务器上查询4M的数据结果，下传到客户端， 客户机要向服务器抛出 4M / 4K ＝1000个数据请求消息
这1000个消息通过SOCKET SERVER 消息队列再被连接线程分拣。 我们知道， WINDOWS 消息具有响应慢，可能丢失,不可靠的特点
应用程序消息队列中的消息响应速度受CPU占用率影响。 这些不利特点直接影响到了SOCKET SERVER工作的稳定性和数据可靠性.
写到这里， 想必你的心里也对SOCKET CONNECTION 的应用产生了恐惧, 我们写出的可靠代码是有可能被这个不可靠的SOCKET SERVER
糟蹋掉的.
如果你用的是SOCKET SERVER， 建议你不要最好将这个程序放在一个性能比较好些的服务器上， 千万不要认为数据库服务器好就可以了
这个中间层服务器的性能也是极其重要的。
总结：诚然，我们可以用SOCKET CONNECTION 模式并要求客户提供性能强大的服务器来实现我们的MIDAS应用.
但是我不得不说的是:对于客户来说， 他们并不知道自己需要性能强大到何种地步的服务器。 最有可能的是，
客户很可能是一家小公司，根本没有足够的资金和预算去满足你提出的购买清单。
你也许可以用变通的方法， 在项目进入使用的初期，让客户使用便宜的服务器，等到应用系统
运行一段时间后再要客户去购买更好的服务器， 我想这种工作态度对客户来说， 是客户最不希望发生的
客户那里的网络运行维护工程师最怕的是服务器性能不够造成网络上跑丢数据，一旦发生数据错乱，
想必受影响的不只是客户的数据， 还有客户对贵公司软件产品的信任。
对于我们开发人员来说， 做出这种程序是很不负责的，你也许根本不希望看到自己的辛苦CODING 做出来
的是这样的应用程序, 也许有一天你会看到， 你自己做出来的程序让你头疼不止.我想起了中国有句古话，
搬起石头砸了自己的脚.
从这个项目中，真正得到好处的， 也许只有推销MIDAS的borland销售人员
 
纯属个人看法, 观者请勿转贴到其他处,谢谢
wanghs
2004年6月20日 8:00