网络通讯服务设计的几个原则

9. 目前业务处理线程里面需要包含重的 Work_Socket 对象，网络处理和业务混合在一
起，耦合比较强；按网络是网络，网络是数据通道；业务是业务，业务利用数据通道的
一般原则,这样，业务开发人员基本不需要知道网络怎么通讯，开发难道可以降低，
业务开发人员也就无法直接去和客户端交互,可以有效屏蔽错误；建议业务处理层只是
保留一个轻量级别的连接ID结构,而不是一个完整的 socket 对象，否则业务处理层可
以任意的发送数据，不好控制；网络处理层提供发送数据的借口： send(char *buff,
struct connectid);把数据送到网络层后，网络层负责发送。这个是走读代码的一点
建议，对以后设计做参考。现在这个模型成熟度比较高，稳定先用好。

10. 还有一个原则，就是通讯是通讯，协议是协议。这个目前我们框架里面有比较好的表现。
大致就说说通讯只是负责传送数据，传送什么数据是由协议来控制的，数据完整不完整也是
由协议来控制。比如一个 TCP 连接，是一个通讯，上面传什么数据是由协议来控制，协议
包里面组装什么数据就是什么数据。一次收到的数据,数据是不是完整，是一个完整包，还
是多个完整包，由协议来控制。如果有多余的半个数据包，下次收完整后合并数据。一般
是收一批数据，把数据送到指定协议解析，解析成功，进行拆包，把拆好的一个一个数据
包送到业务层去处理。这样，通讯和协议有联系，有区分，他们可以分开分层设计了。

11. socket 是否可以重用,一个连接上是否可以发送多个业务数据包;避免短连接，
特别是移动互联网或者大并发业务，建立一个网络连接的成本是很高(慢)的。

12. 网络数据收发是否支持异步收发,收和发分开设计和实现，收的时候可以发,因为
网络通道是双通道的(TCP,UDP)。

13. 协议解析可配置,一个进程支持多份协议，灵活加载。

14.  服务发现;故障迁移，节点摘除;配置中心化，更新自动化;接口调用耗时；业务接口错误统计