互联网后台服务的协议设计
互联网后台服务的协议设计
1. 基本概念
服务（server）：“服务”可以分软件和硬件两个类别，本文提到的“服务”都是指软件，是一种程序。称之为“服务”的程序一般具备2个特点：
1) 程序启动后常驻内存，成为守护进程。
2) 能与其他进程通信，接收请求，处理请求并做出回应。
本文中的服务特指基于TCP/IP 协议通过socket进行通信的服务。
为什么互联网业务需要“服务”这种类型的程序呢？主要有2个原因
1) 有些功能可以通过一个独立的程序来完成，不用每个程序都写一套代码来实现这个功能，这样有利于程序的解耦和复用
2) 有些功能单机、单进程无法完成，需要通过多台机器、多个程序的协作完成。
比如memcache服务，它常驻内存并监听TCP端口，接收来自socket的数据包，使客户端可以以key-value的方式存取数据，是互联网后台中一种常用的cache服务。
客户端（client）:本文中的客户端指的是主动发包给服务的程序，或者说是发起请求的程序，相对的，服务就是接收请求并处理的程序。
协议：协议是一种约定，通过约定，不同的进程可以对一段数据产生相同的理解，从而可以相互协作，存在进程间通信的程序就一定需要协议。
我们为什么需要自己设计协议：
通过上面讲的我们可以看出，在互联网后台开发中，稍微复杂一些的业务，服务是必要的，进而协议也是必要的。那么我们是否可以复用已有的协议呢？主要是因为现在已有的协议都没有能完全match互联网后台开发的需求，存在这样或那样的问题。
协议设计的目标：
解析效率：互联网业务具有高并发的特点，解析效率决定了使用协议的CPU成本；
编码长度：信息编码出来的长度，编码长度决定了使用协议的网络带宽及存储成本；
易于实现：互联网业务需要一个轻量级的协议，而不是大而全的，CORBA这种重量级的协议就不太适合，易于实现决定了使用协议的开发成本和学习成本；
可读性：编码后的数据的可读性决定了使用协议的调试及维护成本
兼容性: 互联网的需求具有灵活多变的特点，协议会经常升级，使用协议的双方是否可以独立升级协议、增减协议中的字段是非常重要的。兼容性决定了持续开发时的开发成本，个人觉得这点是互联网协议中最重要的一个指标。
协议设计需要解决的问题：
1) 序列化/反序列化
2) 判断包的完整性
只要解决了这2个问题，2个不同机器的进程就能完成通信。
2. 序列化/反序列化：
序列化我们常称之为编码，或者打包，反序列化常称之为解码，或者解包。常用的序列化/反序列化方式主要有以下几种：
1) TLV编码及其变体（后面统称为TLV编码）：Protobuf/thrift/ASN BER都属于这种。
TLV编码基本原理是每个字段打一个二进制包，每个包包含tag、length、value 3个部分：
tag: 一般占用1个字节，表示数据类型，有的编码方式（Protobuf/thrift）中tag包含字段的id，有的编码方式（ASN BER）不包含字段的id。包含字段id的序列化方式，id是字段的标志，协议可以灵活的增删字段，只要保证字段id唯一，就能兼容解析，非常适合互联网开发。
length：一个整数，表示后面数据块的长度，Protobuf/thrift的序列化不包含length字段，因为大部分数据类型的长度都可以根据tag中的类型信息可以得到。
value：真正的数据内容。
举个tag包含id的序列化方式打包解包的例子（只是举个例子说明原理，实际上Protobuf等协议都做了比较巧妙的实现，比如varint、ZigZag编码来尽量减少编码长度）：
协议包括2个字段， name字段的id为0，类型为1（string）；age字段的id为1，类型为2（unsigned int ）
|
字段id |
字段类型 |
字段名 |
|
0 |
string |
name |
|
1 |
unsigned int |
age |
需要传输的数据：
name = "xxx"
age = 18
序列化之后大约是
|
字段类型（tag的一部分） |
字段id（tag的一部分） |
字段值（value） |
|
0x01 |
0x00 |
xxx |
|
0x02 |
0x01 |
0x12 |
反序列化的时候，逐步解析字节流，先解析字段类型和字段id，再根据字段类型解析出后面的数据内容，得到了一个id和值的映射关系
0 : "xxx"
1 : 18
根据协议，id=0的字段表示name，id=1的字段表示age，反序列化之后，就知道传过来的数据是
name = "xxx"，age = 18了
如果协议做了升级，增加了1个字段“gender”，删除一个已经没有意义的字段age，协议变成
0 string name
2 string gender
需要传输的数据：
name = "xxx"
gender = "male"
发送方升级了协议，序列化之后大约是
|
字段类型 |
字段id |
字段值 |
|
0x01 |
0x00 |
xxx |
|
0x01 |
0x02 |
male |
反序列化之后，得到了一个id和值的映射关系
0 : "xxx"
2 : "male"
反序列化的一方由于没有升级协议，不知道id=2的字段什么意思，直接忽略，没找到id=1的age字段，那么使用默认值，这样单方的升级，完全不影响协议的解析，协议是具有兼容性的。
举个tag不包含id的序列化方式打包解包的例子：
如果tag中没有字段id，那么字段所在的位置决定字段的含义
协议包括2个字段， 第1个字段name，类型为1（string）；第2个字段age类型为2（unsigned int ）
|
字段类型 |
字段名 |
|
string |
name |
|
unsigned int |
age |
需要传输的数据：
name = "xxx"
age = 18
序列化之后大约是
|
字段类型 |
字段值 |
|
0x01 |
xxx |
|
0x02 |
0x12 |
反序列化程序解析出第1个字段是字符串xxx，第二个字段是整数18，根据协议，第1个字段是name，第2个字段是age，这时反序列化程序就知道了name是xxx，age是18
但是相比上面有id的序列化方式，这种方式有个明显的缺陷：一方升级了协议时，另一方很可能需要升级协议才行，协议不具有兼容性。比如协议做了升级，增加了一个字段gender，删除一个已经没有意义的字段age，协议变成
string name
string gender
需要传输的数据：
name = "xxx"
gender = "male"
发送方升级了协议，序列化之后大约是
|
字段类型 |
字段值 |
|
0x01 |
xxx |
|
0x01 |
male |
这时接收方如果不升级协议就完全无法理解协议的含义
可以看出tag包含ID的序列化方式（Protobuf/thrift）兼容性和灵活性方面优于不包含ID的方式（asn-ber）
TLV编码的特点是：
解析效率高：主要是因为不需要转义字符
编码长度低：主要是因为元数据占用的空间很少
不易于实现：但是有很多开源的工具，根据IDL自动生成代码，提高开发效率
兼容性高：协议双方可以独立升级
可读性差：二进制协议，肉眼很难识别
2) 文本流编码：xml/json都属于这种。
基本原理是把每个字段打一个字符串形式的包，通过键值对（key-value）的方式存储数据，key是字段的名字，用于区分不同的字段（对比上面TLV编码采用id的方式标志一个字段），特殊字符特别是非文本字符需要做适当转义，转义为xml/json的合法字符。xml的解析效率低于json，而编码长度高于json，json作为序列化的方式一般是优于xml的。
同样是上面的协议：
序列化的结果大概是
<p><name>xxx</name><age>18</age></p>
或者
{name:xxx,age:18}
文本流编码的特点是：解析效率低，编码长度高，易于实现，可扩展性高，可读性好
3) 固定结构编码：
基本原理是，协议约定了传输字段类型和字段含义，和TLV的方式类似，但是没有了tag和len，只有value
同样是上面的协议：
序列化的结果大概是
xxx 0x00 0x12
反序列化的时候，根据协议中约定的字段位置、字段类型和字段含义，逐个解出相应的字段
固定结构编码如果协议升级了又需要保证兼容性，那么可以在协议中增加一个“版本号”字段，然后根据版本号决定如何序列化和反序列化，这样可以保证协议的兼容性。但是这样会导致代码非常混乱和让人费解
固定结构编码解析效率、编码长度、易于实现、可读性方面略微优于TLV方式，但是灵活性和兼容性非常差，如果不使用版本号判断就不能单方增删字段，不能单方修改字段数据类型，甚至，把协议中的short int字段改成int，反序列化就可能会出错，因此除了业务逻辑非常固定的场景外不推荐使用。
4) 内存dump：
基本原理是，把内存中的数据直接输出，不做任何序列化操作。反序列化的时候，直接还原内存。
一般我们声明c++的结构如下即可
#pragma pack (1) struct { char name[64]; unsigned int age; }; #pragma pack ()
这种方式适合c/c++语言，单机进程间交换数据。这是一种简单高效的协议，特别适合通过共享内存交换数据的场景。但是不具有通用性，不适合跨越语言和机器，本文不再讨论这种编码方式
如果没有特别的必要，自己发明一种序列化方式一般是费力不讨好的，有重复造轮子的嫌疑，所以我们在成熟序列化方式中选择一种即可。
综上，我们可以看出，如果我们想设计一个具有通用性，可以用于分布式环境，适合互联网后台开发，能传递复杂数据，具有很好的灵活性和兼容性的协议，常用的序列化方式是TLV编码和字符流编码2种。那么根据不重复造轮子的原则，可选的编码方式就只有Protobuf、thrift 和 json 3种了。我们对比一下这3种编码方式。
序列化方式对比
Protobuf/thrift VS json
根据google的测评结果，Protobuf/thrift 效率高于 json， 而可读性弱于json。解析效率大概比json高1倍。这个具体的倍数关系我没测试过，存疑，而且不同的程序使用的json库不一样，还是应该以实测结果为准。
参考http://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking
Protobuf VS thrift
Protobuf 效率和编码长度略有优势，文档比thrift丰富
thrift 内建的数据类型更多（有map和set）
thrift官方比Protobuf支持更多的编程语言，并有RPC框架，但是Protobuf有很多第三方的支持，同样提供了多种语言的支持和RPC框架的实现
参考http://code.google.com/p/protobuf/wiki/ThirdPartyAddOns
参考http://blog.mirthlab.com/2009/06/01/thrift-vs-protocol-bufffers-vs-json/
个人比较倾向于Protobuf，主要是考虑到文档和第三方支持多，目前使用的更广泛。
至此，我们就选定了2种序列化方式Protobuf和json，如果并发度非常高，数据量非常大，使用Protobuf，否则使用json.
3. 判断包的完整性:
一般有两种方法：
1) 在序列化后的buffer前面增加一个采用固定结构编码的头部，头部长度和结构固定，其中有个字段存储包总长度。收包时，先接收固定字节数的头部，解出这个包完整长度，按此长度接收包体。
2) 在序列化后的buffer前面增加一个字符流的头部，其中有个字段存储包总长度，根据特殊字符（比如根据\n 或者\0）判断头部的完整性。这样通常比1要麻烦一些，http、memcached和radis采用的是这种方式。收包的时候，先判断已收到的数据中是否包含结束符，收到结束符后解析包头，解出这个包完整长度，按此长度接收包体。
至此，我们已经得到了一个协议框架，采用这个协议框架，再根据业务需要约定字段含义，就可以得到一个具体的协议，可以用于把一个机器上的消息，发送到另一个机器，并让对方完全理解消息的含义。但是如果这就是这个协议框架的全部，那这个协议就太弱了，因为如果一个程序只知道协议框架而不知道协议的字段内容，那它除了可以收包和发包外，做不了任何事情，而在客户端和服务之间搭建一个代理层，来做容灾、监控、统计、路由、认证等等事情是一种常见的架构模式，这样这些公共的处理逻辑就不用每个服务都做一次了，服务可以专注于业务，而把这些逻辑交由代理层来做。换句话说，我们需要为协议框架增加一个头部，并约定一些所有业务都可以使用的公共字段。
4. 协议头部:
那么头部中可以增加哪些字段呢？这个取决于你希望代理帮你做哪些事情。通常以下字段是可以考虑的：
seq //消息序列号，可以用于排查问题，也可以用于某些IO模型中包的解析
protocol version //协议版本号，可以用于协议的兼容
request useragent //请求者机器环境，包括操作系统、客户端版本等等信息
request user ip //请求者ip
request user id //请求者id
client ip //客户端ip
client id //客户端业务id
server ip //服务ip
server id //服务id
server server cmd //服务命令字
retcode //返回码
有了这些字段，代理层就能完全监控到服务的访问情况，并生成报表
5. 我设计的协议：
有了上面的理论，我们就可以真正的设计协议了。我设计的这个协议可以应用于互联网后台服务的绝大部分场景，协议中把一个包分为3个部分：
包头的第1部分：固定8字节：协议标志（2字节） 包头长度（2字节） 包体长度（4字节）
包头的第2部分：这部分主要是前面第4点提到的公共头部，包括seq等字段，采用Protobuf序列化,包头的字段是可以增删的，即使没有任何字段，也不影响数据传递，但是可能影响你的代理做的工作；
包体：采用Protobuf序列化，具体内容取决于业务。
6. 一些常用的协议：
http协议：http协议是我们最常见的协议，我们是否可以采用http协议作为互联网后台的协议呢？这个一般是不适当的，主要是考虑到以下2个原因：
1) http协议只是一个框架，没有指定包体的序列化方式，所以还需要配合其他序列化的方式使用才能传递业务逻辑数据。
2) http协议解析效率低，而且比较复杂（不知道有没有人觉得http协议简单，其实不是http协议简单，而是http大家比较熟悉而已）
有些情况下是可以使用http协议的：
1) 对公网用户api，http协议的穿透性最好，所以最适合；
2) 效率要求没那么高的场景；
3) 希望提供更多人熟悉的接口，比如新浪微、腾讯博提供的开放接口，就是http的；
memcache的协议：
基本原理是：先发送字符流，以\r\n作为结束标志，字符流中不允许存在特殊字符。
再发送一个数据包，可以包含任何字符，数据包的长度已经在前面的字符流中指定。
memcache的协议并没有包含业务数据序列化和反序列化的部分，只有包头和一个buffer，是一种适合于业务逻辑简单场景下的协议。参考：http://www.ccvita.com/306.html
redis协议：
基本原理是：先发送一个字符串表示参数个数，然后再逐个发送参数，每个参数发送的时候，先发送一个字符串表示参数的数据长度，再发送参数的内容。
redis的协议和memcache类似，但是memcached只能带一个二进制字段，redis可以带多个
参考：http://www.redisdoc.com/en/latest/topic/protocol.html
