随笔 - 16, 文章 - 0, 评论 - 55, 引用 - 0
数据加载中……

多进程的构架方法

  做了4、5年的开发,大大小小的项目也做了不少,但以前都有一个致命的问题,不知不觉就会写出一个巨大的主程序出来,层次复杂,编码痛苦,调试困难。但似乎大家都认同这样的开发方式,虽然都知道界面和功能分离是好事情,但就是做不到。我自己也曾痛苦的思考过,但没有什么收效,似乎在Windows下的开发只能是这么痛苦。

  一星期前买了<<unix编程艺术>>,这一周可谓改天换地,每天都在阅读和思考中度过,想必武侠小说中的武功大进也就是这个意思了。虽然书还没看完,但是有些话实在是不吐不快。

   什么是界面?界面就是功能的子集。没有哪个界面能反映所有的功能,但是若没有界面,对于最终用户来说又是不可忍受的,无论如何都不能指望让一个门卫学会输入复杂的命令来完成工作,虽然最终用户也包括专业人士,但这世界上终究普通人更多。在这样的前提下,可以认为功能永远比界面更宽泛,更有适应性,而GUI更狭窄,更具有特殊性,所以将界面和功能进行分拆也就成为一种必然趋势。

  但是如何分拆?在Windows的世界里,一个普遍观点就是DLL。DLL很好,但是还不够好,因为无法直接使用、调试以及升级,带来的问题远比好处多。另一种方法就是在代码级进行分层,比如GUI一层,功能一层,再用胶合层将二者整合。且不论胶合层的不可复用和调试困难,就一条,如何能做到GUI崩溃的时候却不影响功能的实现?以前我做过的项目都是这样处理的,直接的后果就是项目越到后期问题越多,代码越不接受变化。调试花费了大量的人力物力,收效却未必好,功能的一点点小修改就会造成代码里出现意大利面条。你可以说只要前期的小心规划和仔细架构就能避免这些问题,但是谁能准确预测未来?无论做怎样的努力,你也不能保证现在的功能永远不变,永远不变的恰恰就是变。如果不能保持实现的稳定性和较好的移植性,这样的项目下场一般都不太好。

  说了这么多废话,还是赶紧进入正题。谈谈这一周来的心得体会!

  首先,变化是渐进的,非突变式的。如果能将变化的所在约束在一个比较小的代码范围内,修改就不会成为噩梦。怎么约束?就一个要求:在保证完整性的条件下让每个模块包含的功能尽量单一和足够小。首先是保证完整性,不是代码足够短,包含的实现足够少就是完整,要达到完整,就要让模块的各个部分做到不可分割和无需添加,按照古人的说法,就是增一分则太多,减一分则太少。这个要求虽然看起来很好理解,其实并没有什么标准答案,每个人心里都有自己的回答,正所谓仁者见仁,智者见智。其次是单一化和小型化,一般来说,范围太大的东西会造成人脑覆盖不全,比如一个功能,如果牵扯的部分过多,就会造成从底层到中间层,再到上层,全部都要思考到,估计没有几个人能做到,即使做到了,将来的维护和修改也会变成噩梦。相反,只要功能的涉及面够窄,就很容易进行思考和修改,这个道理应该没有什么问题。

  既然要保证模块单一、小型化和保证完整,也就意味着这个模块可以认为是一个完整而单独的程序,无需外围程序的支持就可以单独运行和测试。从而引出我的最重要的观点:尽量用多进程来分拆程序。在Windows的世界里,多进程似乎是天生被忽略和鄙视的,从unix的观点看,其主要原因是Windows的设计中对进程的快速创建支持不够,造成对多进程的天然排斥和害怕。但是换一个思路看,多进程也许是目前最好的架构方式。底层的功能分拆成各个进程单独运行,通过ipc和上层的GUI进行交互,胶合层薄了,移植性增强了,调试容易了,功能演进也不再成为噩梦。需求永远是渐变的,所以进程的渐变也就成为可控的行为。

   多进程间的传递方式一般有这么几种:共享内存,管道(pipe),信号,消息, socket。其中共享内存适宜于大量数据的即时传递,速度快,容量大。但使用共享内存时需要仔细考虑读写冲突问题,一般的解决办法是用全局锁,但是锁的存在必然会造成效率的下降,所以能不用锁就尽量不要用。pipe的速度和容量都没有共享内存好,但是用来传递命令和返回值还是很适合的。信号和消息的方式一般会和操作系统联系紧密,个人不太喜欢。最后是socket,对于异地交互而言,socket是目前很常用的手段,甚至本地进程间通讯也可以使用。但是由于和网络有关,所以同步性不好保证,需要辩证的使用。

  说了这么多,举个例子说明一下。假设现在要做一套点菜软件供酒店使用,其基本功能包括人员管理,桌台管理,点菜管理,结账以及后台管理五个功能模块。按照单进程的方式就是将所有功能整合在一起,系统启动时加载所有的功能,一旦某个模块出现问题,则必须重新启动程序,而且各个模块之间很容易发生资源冲突和请求冲突。如果换成多进程方式,让我们看看有什么不同。首先是所有的功能最终目的地都是数据库,那么可以开发一个后台进程专门所有负责针对数据库的请求,通过pipe或者共享内存来接收命令和返回结果,那么程序或者说具体代码块之间的接口就是单一的pipe或共享内存了。同时,即使某一个程序运行错误也不会造成整体失败,只需要重起失败的部分即可。当然了,这种方式下存在一个问题,就是效率的降低,但是对于大多数的应用来说,稳定性的提高远比效率的降低要重要,而且随着硬件水平的不断提高,效率总是可以达标的。

  数据库处理分拆出去后,剩下的就很好处理了,人员、点菜、桌台等管理模块都作为单独的后台程序出现,最后GUI部分只需要和各个共享内存和pipe打交道即可,无需只要具体的逻辑处理和功能实现,而且各个后台程序还可以复用,比如人员管理可以挪到客房服务系统中,甚至是其他系统。GUI随时可以替换,实现了功能和界面的分离,同时系统崩溃的几率大大降低,升级和售后也方便很多,永远不要把最终用户想的太愚蠢,很多时候人们还是蛮有求知欲的。

  更多的细节需要自己整理,这里只是给出了一个框架,起码我现在的项目已经开始这样做,效果嘛,半年后就知道了。 

2006-04-05 21:38 

修改于2006-04-07 18:56

再次修改于2006-04-13 21:55

posted on 2006-04-14 01:10 cyantree 阅读(2900) 评论(12)  编辑 收藏 引用

评论

# re: 多进程的构架方法  回复  更多评论   

好文章,顶了,
我也去找本unix编程艺术看看,这本书被评价得非常高.
2006-04-14 09:39 | Stone Jiang

# re: 多进程的构架方法  回复  更多评论   

嗯,楼主的点菜系统的架构貌似多层滴胖客户端应用。其实很多java的项目里面都是这样的,应用服务器负责链接到数据库,ejb完成业务,struts 来控制逻辑,jsp来展现。
2006-04-14 14:42 | ZiDing

# re: 多进程的构架方法  回复  更多评论   

对于windows程序,我觉得还是多线程比较好,而不是多进程?
2006-04-14 23:31 | flyingxu

# re: 多进程的构架方法  回复  更多评论   

感觉是不错,不过有问题调试的时候可能会麻烦点
2006-04-15 08:57 | 我是阿牛

# re: 多进程的构架方法  回复  更多评论   

关于线程,请看unix编程艺术中的一段话:
“线程成为滋生bug温床源于它们太容易知道过多彼此的内部状态。与有着独立地址空间、必须通过明确IPC进行通讯的进程不同,线程没有自动封装。这样,基于线程的程序不仅产生普通的竞争问题,而且产生了新一类bug:时序依赖,要重现这些问题极其困难,遑论修复。”
起码在我之前进行的项目中,线程在后期造成的问题远多过其带来的好处

关于调试,你认为是调试一个小的单进程容易,还是调试一个复合的大程序容易?
2006-04-15 12:12 | cyantree

# re: 多进程的构架方法  回复  更多评论   

这不典型的COM+
2006-04-16 17:40 | wy_rover

# re: 多进程的构架方法  回复  更多评论   

If you're in uncomfortable position and have got no money to get out from that, you would need to receive the credit loans. Just because it will help you definitely. I take financial loan every time I need and feel OK just because of that.
2010-05-05 20:44 | loans

# re: 多进程的构架方法  回复  更多评论   

Yeah indeed very
helpful for the elocutionists it was pleasant to read about this good post! If you need to get a great job firstofall you need
<a href="http://www.prime-resume.com">resume writers</a>. Study and don't forget - if you have to work and study at the same time, there areold pros who are ready to aid you with your resume when you under time compression and looking for a great job.
2010-08-02 15:01 | Guthrie24Lori

# re: 多进程的构架方法  回复  更多评论   

You feel yourself irritated because of your PR? You should not feel so, because company to buy link and optimization issues can rescue your internet business very fast. No crisis will impact on your internet business!
2011-12-12 16:14 | buy links

# re: 多进程的构架方法  回复  更多评论   

Tutors have got really negative outlook about plagiarizing. So, be extra careful when buy cheap term papers, just because you don't want to be accused in plagiarism.
2012-05-28 22:31 | writing custom papers

只有注册用户登录后才能发表评论。
【推荐】超50万行VC++源码: 大型组态工控、电力仿真CAD与GIS源码库
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理