多进程的架构方法(转)

       做了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随时可以替换，实现了功能和界面的分离，同时系统崩溃的几率大大降低，升级和售后也方便很多，永远不要把最终用户想的太愚蠢，很多时候人们还是蛮有求知欲的。 　　

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

.