MPU: 消息处理单元的设计与实现（01）

Why MPU？

复杂的系统，越往Server端走越单纯，把各种验证、解析、搜索等等流程走完以后，往往到了头就是一个非常单纯的判断和处理。 以大家熟悉的炒股为例，我们苦逼的开户存钱下载安装下单亏本，到了交易所其实只有一件事：买单和卖单的匹配，称之为撮合。当然，在这之前券商和交易所都做了些收税费啊，收税费啊，收税费啊之类的工作。

扯远了，想说的是，假如有一天，我们要开发一个或者一组服务器，其实我们需要的是一个面向消息处理的平台加上我们自己的消息处理过程。这样的平台能够隐藏通信、部署、监控等等功能，我们所需要做的就是定义自己的消息格式，并在合适的地方处理它们。

考虑WCF，实际上做的就是上面的这些工作。你定义数据结构和操作，并在合适的地方实现，通过配置文件或者坑爹的硬编码部署它们。 WCF不同的地方在于它做的更多，隐藏的细节更多。不过这玩意有点慢，可能水平有限，反正我玩不出每秒万笔的流量。

考虑ActiveMQ这样的中间件，做的事情也差不多。简单的接口和配置，隐藏细节，直接面向消息。缺点也同上，Broker的存在导致速度上不去。当然，这只是个人感觉。

如果我们要做一个坑钱的交易服务器，上面这些都不合适，us级别的延时和200K msg/s的流量，要求更快更宽（流量）的平台。如果不是特别有钱买死贵的商业软件的话，只哟自己动手了。

所以有了MPU。

 

PS，实际上是被坑了许久，写了许多重复的代码后才醒悟过来，才有了MPU的，上述内容纯属倒推。。。 

 

 What‘s MPU？

 MPU: Message Process Unit。实际工作中消息处理的过程都差不多，抽象出来以后使用配置文件来管理，就成了MPU。MPU的设计目标是简化消息处理程式的开发。

 一个Unit，就是一个相对独立的消息处理模块，在目前的实现中，一个MPU就是一个Thread。对应MPU的概念是MPC：Message Process Center。多个MPU联合起来完成一个复杂的功能，就是一个MPC。

 考虑一个简单的Web服务器，其工作过程也可以简化为等待-收到请求-发送应答的过程。将其消息处理过程的复杂性剥离掉的话，他的工作过程和一个简单的消息应答器一致，伪码如下：

 Socket S;

S.Binding(EndpointAddress);

While(true)

{

Message msg = s.recv();

Message response = OnMessage(msg);

s.send(response);

}

 不断的接受请求，处理请求，发送应答。

 在MPU中，上述的内容对应的概念如下：

Socket：Endpoint。Endpoint是一个链接的一端。Endpoint可以是不同的东西，只要能够收发消息的对象（不一定通过网络）都可以看成Endpoint。实际上，MPC的协调工作中就需要Inproc方式收发消息的Endpoint。 

While（True）：Looper。Looper是循环处理对象。为了提高效率，在MPU中实现了基于Poll的Looper。

 OnMessage：Meson。Meson是需要MPU用户自己定义的消息处理对象。

Endpoint、Looper、Meson组合起来，就是一个完整的MPU。