一般游戏开发都会设计到网络通信。包括客户端端和服务端，还哟偶服务器之间。
网络通讯多以数据包的形式发送。
最简单的格式莫过于KLV（Key，Length，Value）。在此之上还会有源地址 与目标地址的封装（添加源地址是为了方便响应回发）。一般地址信息协议包裹数据包协议，方便进行转发。
如果是巨型包，需要分包的情况当然更为复杂，这里暂不考虑。
对于这些相对底层（不涉及业务逻辑）的打包动作一般都是会封装甚至隐藏起来。
但是对于业务层的数据是否需要封装就是一个值得考虑的问题了。
由于业务层数据结构较为复杂，而且每种数据包设计的地方相对偏少（很多协议都会只在一个地方使用）。本分开发人员习惯在使用的地方直接打包。
比如直接打包一个ByteBuff，或者json，甚至是一个protobuf。我个人觉得protbuf之类的库只会用在跨语言的交互（跨语言有点复杂，自己造轮子成本比较高），并不是我们不需要protobuf的打包功能，而是我们不需要protobuf。我们应该实现自己的打包方式，这样才可以更高效的通信。这也是本文想要说的。
demo：
void f1()
{
...
//这里要调用一个外部接口了
ByteBuff buff;
buff <<cmd << arg1 << arg2 << arg3;
Server::send(buff)//底层数据发送接口，忽略地址的问题
...
}
这样做有2个问题。
一是通信协议的调用者和协议格式过于耦合。
二是很难一眼就能知道打包的代码在哪。
而如果我们对其进行封装。
当你使用一个协议的时候就好像调用一个方法一样。
demo:
void f1()
{
...
//这里要调用一个外部接口了
cmd(arg1,arg2,arg3);
...
}
void cmd(arg1,arg2,arg3){
ByteBuff buff;
buff <<cmd << arg1 << arg2 << arg3;
Server::send(buff)//底层数据发送接口，忽略地址的问题
}
封装之后我们可以很清晰的知道协议的实现在哪里。
当多个地方使用到协议时，对协议格式的变更不用影响调用者。
可以对有限的协议升级进行兼容。比如添加一个参数，并给定默认值。
另一方面，对于server端（每一个协议总是分为client端和server端）
同样也是如此
如果不封装，就像这样
void server_cmd(buff)
{//cmd已经被解析
buff >> arg1 >> arg2 >> arg3;
...
}
这里主要是有一个问题，由于业务逻辑和协议解析没有分离，这个业务没办法被本地调用。
而封装后
void server_cmd(buff)
{
buff >> arg1 >> arg2 >> arg3;
cmd_do(arg1,arg2,arg3);
}
void cmd_do(arg1,arg2,arg3)
{
...
}
封装之后协议的client和server成对的出现，放在一个地方非常方便封装和协议。由于功能很干净，也方便我们实现自动化生成协议代码的需求。
而client调用和协议逻辑格式一致，也方便理解。同时再有需要的情况下可以很方便的切换是否使用远程实现。比如我们允许两个服务存在与一个进程或者不同进程。而当我们发现client与server在同一进程中时，可以切换成直接调用。
思路来至于thrift。
