软件目录(www.cnosoft.com)5月13号讯:
模块分离：许多开发者所维护的多执行绪模式的工程，或多或少都会遇到以下问题：在不同的模块之间进行直接呼叫，不信任的话，那么，您的专案肯定是一个模组的。我想大多数时候，都会有一些函数被调用，或者是没有全局变量的时候，这些都是很好的例子。
因为多线程天生的优点，可以看到彼此的地址，这就使得直接的呼叫变得非常简单，许多新手都是如此。可以轻松地编写出一个简单而又粗糙的界面，如果有 static的功能，为了省事，可以省略 static，直接使用。这样一来，随着项目的增加，各个模块之间的交叉越来越多，耦合也越来越强。
我支持多进程，是因为多个过程可以屏蔽掉这些“方便”的交流，让我们在做一个模块的时候，会不会考虑到有没有必要。然后再考虑界面的定义（由于处理之间的通信比较复杂，所以开发者会更多地考虑界面和协议的概念，以尽可能地降低界面的影响。这就像是生活一样，一帆风顺，谁也不会去多想。想的东西多了，路也多了，也就不一样了。
因此，我的观点是，多处理模式迫使你更多地考虑如何设计，并在实际中降低了模块间的耦合。
将多个多线程模式转换成多处理模式时，往往会在多个处理模式中出现一些重复的界面，这是由于界面函数是在一个进程中，所有人都可以调用的。例如， A通过 A、 B被呼叫， A和 B被分成两个不同的过程。界面 A要在 A和 B中单独地完成，不做任何说明，因为在软件工程学中，重复的代码是最忌讳的。一定要清除掉。方法也非常的容易，就是将多个不同的模块所呼叫的界面分开，形成一个 lib，让其它的程序可以进行呼叫。您找到了哪些，是否可以将其分离出来，成为一个整体的公共部件，非常好。在 lib下面，是一个公共的基本部件，在每个部件中都有一个单独的商业流程。
容易找到：在多执行绪模式下，如果另一个执行绪出现了故障，则会造成一个完整的处理结束，当然，根据 crash的讯息，可以判断该线程已经死亡。但是，如果这个线程的组件是多个团队和人来维持的，那么在这个过程发生故障之后，团队会做出怎样的决定。这个问题很大，有时候也会发生在一个线程上，但实际上是其他的线程的问题（连接的麻烦），这样的话，团队之间不可避免的会发生争执和互相推卸责任。（那些信心满满的程序员，都觉得我的程式没有任何问题）
而如果使用多个过程模式，那么，您的服务流程就会中断，您可以自行寻找其中的理由。无话可说。
简单的性能检测：在多行程中，单一的线程并不容易被发现（或者说，在某些嵌入式系统中，并没有一个完整的指令），在处理过程中，在处理过程中，需要大量的资源来进行处理。但如果是一个多进程的模式，那么就可以查看哪个线程占用了多少的资源，这是一个很小的问题。相同的体系，被分割为多个过程，单一的过程要比单一的过程要简单的多，从而减少了复杂程度。这样的话，想要找到自己想要的东西，就更简单了。
分布：网络产业一向注重分布，云计算，嵌入式产业，都是一件很麻烦的事情，似乎并不是必须要有分布的。这倒也是，大多数时候，都是一个单独的芯片，可以单独工作。分散的情况很少见。但是，如果你把一块原本可以做的事情，分成两块，那么多个系统的扩展就会变得更加简单。
这只是一个很好的例子，嵌入式系统本身就是一个分散的产业，只不过它并没有从一个中心向一个分散的方向发展。
便利公司的密码授权分离：事实上，我非常讨厌这样的行为，公司应该信任自己的雇员，但是考虑到中国的诚实…所以，他必须要把自己的身体孤立起来。
在多执行绪模式下，之前说过，删除一个模组，您就不会 build了，这是要让所有的程式设计师都知道么。当然不行，每个模块都要提供一个类库，但我认为很常见，就是将一个公共的函数界面划分为一个公共的类库，而将一个与商业有关的组件也作为一个类库来使用。只是……
最后，我要说的是，这些都不是最重要的，没有一个可以让多个进程占据绝对的上风。就我的观点来看，多进程模式可以让工程师们去考虑如何去做。（任何一个有过这种问题的工程师都会考虑到任何一个模式）
既然已经说到这里，那就应该考虑一下，将以前的研究成果转化为多个过程，不然就是空中楼阁了。
首先要解决的问题，就是多个进程之间的交流，而多个线程之间的交流无法进行，所以，要怎么才能找到多个处理的通信模式？
linux下有许多 ipc方法，这里就不一一列出了，用于处理大量的数据，通信信息。最好的办法是套接，而在这个机器里，更多的是 unix socket,（这个方法有哪些优点？如果你想将一个单独的体系变成一个分散的体系，那么它的好处就会很大）
但如果只使用套接字来完成上述示例中的函数，就会出现以下问题：
同样的，第一个问题就是，我们之前的第二个解决办法，现在不能再在多个过程中使用了，这就很好理解了，不用再多说了。
最好的办法，就是在第一种情况下，将 Socket通讯改为 Socket通讯（通过 Socket通讯），不过，了解 Socket的工程师都知道，在进行 socket通讯之前，需要进行一系列的准备工作（主要是将两个组件联系在一起）。若加上 F组件，则 A也会与 F组件建立联系。在这种情形下，我们在脑海中绘制一幅联系图，就会发现我们编织了一幅由许多不同的网络组成的网络，这些网络中的每一个都有着复杂的联系。要对 A模块进行修改，这可比多线程模式要麻烦的多。这样的行为简直就是一场恶梦。
好了，怎么处理，我认为许多人都会考虑使用巴士分配。懂 android开发的人会想起 binder，懂 openwrt的人会想起 ubus，而懂电脑的人会想起 dbus，网络产业的开发者肯定也会知道 redis里面的 sub/pub模块。
以上的 binder, ubus之类的原则非常的简单，即创建一个信息中心，并构造一个转发路径。其它的模块没有进行直接的互动，取而代之的是信息中心的转送、路由，以及路由的确定。那么，使用预订/发行的观察模式来进行规则的界定。（C和嵌入式开发人员往往会认为，这种设计方式和 OOP相关，是唯一的，尽管现在已经有不少专家在这一领域推广了。但考虑到某些开发商的消息来源相对封闭，所以这个观点依然很流行）
根据此模式，我们可以很容易地满足上述示例的要求：增加一个信息核心，使所有的通讯组件都与此信息中心组件相关联。之后，您可以订购您所关心的活动，并且在事件出现时，您可以根据您的需求进行适当的操作。
因此，上述的模组 B、 C会在模组 a侦测到某个活动时，向外公布模组 a的活动。这个活动首先会被传送至信息中心，然后被信息中心传送至组件 b、 c，而新添加的组件 f。也仅需订购此模块，无需在更改至 A模块的程式码，即可扩充功能。
