现在用Delphi的人越来越少了,不过没关系,编程的经验应该是可以相通的,并不限于某种语言工具。我最开始也只是用C/C++,但后来我发现Delphi也挺好,在日常的信息系统开发中更具优势,因此就更偏向于用Delphi了。
相信很多人跟我一样,有这么一种感觉:Delphi只适合开发前端界面程序,开发后台服务则会不稳定,后台还是用Java或VC比较好。这种感觉一定程度上是有道理的,毕竟Delphi容易入门,其编程模式又使得入门后的程序员偏向于以界面为中心,重UI而轻结构,这些显然都不适用于后台服务开发。
但其实这些都是程序员的问题。Delphi只是一个编程工具,不能因为它的界面功能强就否定它生成的程序稳定性。其实用它来写无界面的程序也是完全OK的,只是需要注意一些细节。这里我按自己的经验做个小结,如下:
1.最重要的,是要自己接管内存分配,开辟内存缓冲池。
原因很简单,WIN32下一个进程只有2G内存空间,服务程序要长期运行,就会不断地申请和释放内存,而且不但会申请小块的零碎内存,经常也会需要申请连续的大片内存,如果任由系统无限制的循环分配释放内存,那么很快你的程序空间就会充满零碎的内存,这时再要申请连续的大片内存就会失败,导致程序崩溃了。这些都是我们有过的惨痛经历得来的教训,服务死掉的最常见原因,就是猛占内存,直到系统资源不足。
所以,除非你能自己搞一个内存碎片整理功能,否则你一定要接管内存分配,把所分配的内存记下来,重复使用。不然的话,想要长时间运行,除非你的服务线程什么都不干。
从这一点来看,Java适合做后台服务也是有道理的,最起码它的垃圾回收机制,为我们解决了内存的问题。
2.对象缓冲池,对于经常要重复创建、释放的对象,一律用缓冲池管理。
原因类似上面,但不限于内存。如线程对象、位图对象、数据连接、查询组件等等,只要服务中经常用到的东西,一律放入缓冲池中。缓冲池一般都会设置最大值,达到上限时就需要排队等待了;不然的话,连接用户一多,再多的资源也顶不住。
3.日志功能。
对于没有界面的后台服务来说,日志的重要性是不言而喻的。日志需要记录服务的运行状态、用户操作、错误异常堆栈、内存性能警报等。服务程序中的CPU内存资源非常宝贵,因此日志中需要对占用CPU和内存资源多的操作进行重点记录。开发阶段如果有出现运行时间长的情况,应在代码中加上运行时间的检测日志,供分析排查。
4.负载均衡与容错处理。
服务程序要想长时间运行,就得支持多实例分摊负载。当其中一个服务出现问题时,可转到其它服务,这样最多只影响当时未保存的少量操作,不影响整体使用。
5.拷机测试。
服务上线前,一般都需要进行长时间的大负荷运行测试,这时一般都需要有客户端请求来配合。可用现成的测试工具,如LoadRunner、QTP之类的。我比较倾向于自己写随机模拟测试程序,比较接近现实情况。
6.运行监控。
需要另外再有一个程序对服务进行监控,一旦发现异常,立即发送邮件和短信通知相关负责人。这种程序不难,可自己写一个;不想写的话也有现成的,网上搜索一下就能找到。
7.远程管理,可对异常进行处理。
人力毕竟有限,谁也难以保证永远不出问题。因此远程管理是非常必要的。如对于异常的侍服线程,可远程强制结束;可远程查看日志,采取相应措施;实在不行,还可以远程控制服务重启。
8.其它没想到的...(此处略去128K个字,呵呵)
写了这么多,发现似乎跟Delphi没什么关系。其实,只要是写服务程序,都会遇到类似的问题。使用的工具不同,但做事的方式和结果是一样的。只要能注意这些细节,用什么写都一样,都可以放心地7x24小时长时间稳定运行。只是...呃...要全做到太不容易了,估计只有大公司才行吧,我自己也只能做到其中一部分而已。