协议格式选择思考

后台服务器一般要按照功能拆分成各个独立低耦合的模块，模块之间采用协议通信；

实际中使用过各种协议：

1，http 协议

2，memcache 类协议

3，固定包头二进制协议

区别：

1，前2类协议都属于字符串协议，字符串的协议的好处是对工具的依赖最小，对使用最友好，且非常

易于和其他小工具整合；但字符串一般来说会比较冗长，不够紧凑；所以才有二进制协议，二进制协议一般

采用固定头部来做处理（比如ip，tcp协议等等）

2，http 协议解析稍显复杂，如果要自己写程序去处理 http 包，还是比较麻烦和啰嗦的；http协议

区分包头和包体；http 协议虽复杂，但有现成的解析程序，比如nginx，apache之类的通用svr，且这些svr

都是强配置的，特别是 nginx，可扩展性非常强，非常适合拿来做 http 协议处理；

3，memcache 协议，无包头，以一些标志字符(串)来做分隔符，一般此类协议非常简单，简单到极致

但此类协议很难处理比较复杂的协议（比如嵌套协议）；

4，固定包头二进制协议有独立的包头和包体，比较紧凑，这类协议解析和打包实际上都非常简单

且可以对付极其复杂的协议，且最重要的是，完全可以通过一些自动化的工具生成这些编解码解析的代码，极

大的简化了手工代码的麻烦，基本只需要写一 DSL（自定义语言，比如 thrift） 即可；但这类协议对特定

工具非常依赖，属于专有协议；通信双方都要拥有统一的编解码代码才方便；

5，http和memcache 协议都是一问一答的，所以不能并发，只能采用多连接；而二进制协议往往可以

并发的（比如tcp同一连接上可以并发n个包），对于并发大，且连接受限的内部svr来说，此类协议往往不是

非常合适；

使用感受：

1，memcache 协议用的很少，一般涉及到业务的协议都比较复杂，且变化太大，这类协议比较难以

自动化，手工code太麻烦；

2，http 协议，其实这个协议只管了包头，包体还是要协定的，一般通用的可能就是 xml 或者 json

了，xml 协议历史悠久，不过解析编码非常之恶心，虽然有一些现成的解析库之类的，但还是不方便，使用

过几次，感觉非常难受，基本排斥了；对于 json 协议倒是情有独钟，json 小巧强大，且json对于很多动态

类型语言（比如js，lua，python）都非常友好，解析后用起来基本感觉不到 json 的存在；

3，http + json 基本成了接入的首选协议，利用了 http 解析svr比如nginx的强大可配置，可以将

系统接入做的非常巧妙强大可控可改，灵活性极大；

4，对于系统内部svr通信，因为系统内部svr都是自有框架编写，可配性差了非常多，且不希望编

解码协议造成过多干扰，固首选肯定是固定二进制协议，简单且能引入自动化工具，基本能做到完全屏蔽协议

编解码的细节，开发人员面对的都是已经解析好的 struct 协议；

5，系统内部边界不易划定的地方，特别容易出问题，比如某个子系统和另外的子系统交界处，过去

一般也是采用二进制协议，现在觉得造成了很多问题；1，独立的子系统之间通信细节暴露太多；2，最麻烦的

是因为采用二进制协议，可配置型灵活性非常小，没有 http 协议一些已有的控制手段（比如反向代理），

不能屏蔽子系统内部的一些分布细节，导致系统之间的分布部署耦合在了一起，非常恶心的一个问题；

改进地方：

1，子系统之间隔离，隔离后的协议采用 http+json，每个子系统都有独立的http接入svr；