前言

由于笔者业团队的业务对即时通讯服务有很大的依赖，春节结束后的第一天，红包没到，产品同学先到了，产品同学和我说要做一款IM，看到需求文档后和设计图后笔者大吃一斤

这不就是一个翻版的web qq吗？

可以可以

联想到最最近美团的大象，头条的Lark，用户与用户，商家与用户，企业同事的沟通，及其衍生的配套增值服务，真是需求旺盛的强需求啊

如果我要做一个WebIM应用

现在的Web应用通常会考虑ajax轮询或者是long polling的方式来实现，但是频繁的建立https连接，会带来多余请求和消息精准性的问题，本质上是TCP，消息边界不清晰，会有黏包的情况

类似我司ios和andorid客户端，采用socket+PB协议来解决及时通讯问题，采用socket服务，依赖google的oc PB协议包来实现，socket是基于TCP协议，由通信协议和编程API组成的，原理一次HTTP协议握手成功后，与服务器建立双向连接，数据就可以直接从TCP 通道传输基于事件的方式，二级制传输，反编译为json或者xml

笔者在查阅翻google PB开发者文档时，看到17年下半年google发布了官方的js的版本，配合websocket，可以与PB协议进行配合，在实现原理上，优于现有的ajax轮询或者是long polling的实现方式

So，Let's rock !

Protocol Buffer是个什么东东？

Protocol Buffer是Google提供的一种数据序列化协议，下面是我从网上找到的Google官方对protobuf的定义：

Protocol Buffers 是一种轻便高效的结构化数据存储格式，可以用于结构化数据序列化，很适合做数据存储或 RPC 数据交换格式。它可用于通讯协议、数据存储等领域的语言无关、平台无关、可扩展的序列化结构数据格式。

为什么是Node，为何要和Protocol Buffer打交道？

做为javascript开发者，对我们最好的数据序列化协议当然是JSON，pb协议相较于之前流行的XML更加的简洁高效

pb属于二进制协议，更容易解析，解析速度比文本协议有二向箔级别的压制，so，在聊天场景下，udp传输明显是优于tcp的

后台通信基本是基于二进制的，以往我们开发中用到的纯文本协议是后台同学在封装一层实现的，例如我司的服务，就维护了两套，一套二进制的，一套http接口的，如果可以用Node打通了pb，可以将维护成本降到最低，理论上只有一套底层二级制服务

ps. 类似PB这样的东西，还有MessagePack和Apache Thrift

说的这么热闹，老夫已经迫不及待了！

想必你已经说，别逼逼，show me the code，怎么好的开发都么上进呢？

好吧，Let's Rock & Roll!

官方案例

我们来操作一下

安装google-protobuf

2017年4月开始官方支持javascript

github

develops

npm install google

-protobuf

定义.proto文件

proto文件 messages.proto

package zxwj;
syntax = "proto3";
message helloworld 
{ 
   string zzuid = 123;  
   string zzstatus = 0;
}

编译.proto文件

使用protobuf.js命令行工具编译

protoc --js_out=import_style=commonjs,binary:. messages.proto

protoc会编译输入文件，并且构建messages_pb，在sever中，可以以以下方式引用

var messages = require('./messages_pb');
var message = new messages.MyMessage();

编写server.js

var basepb = require('./messages_pb');
console.log(basepb);
var message = new basepb.SearchRequest();
console.log(message);
message.setName("TS");
message.setPassword("123456");
var bytes = message.serializeBinary(); //对象序列化
console.log(bytes);
var message2 = basepb.SearchRequest.deserializeBinary(bytes); //进制序列化
console.log(message2);

运行

node sever.js

总结一下

上个案例并不具备线上产品能力，但是还可以能看出PB协议的优势所在

快，从官方的测试结果来看，整体比較起來，ProtoBuf.js 則是比纯JSON 的处理快上一倍以上，附官方Github测试结果（机器配置：i7-2600K。Node.js 版本：6.9.1）

benchmarking encoding performance ...
Type.encode to buffer x 547,361 ops/sec ±0.27% (94 runs sampled)
JSON.stringify to string x 310,848 ops/sec ±0.73% (92 runs sampled)
JSON.stringify to buffer x 173,608 ops/sec ±1.51% (86 runs sampled)
      Type.encode to buffer was fastest
   JSON.stringify to string was 43.5% slower
   JSON.stringify to buffer was 68.7% slower
benchmarking decoding performance ...
Type.decode from buffer x 1,294,378 ops/sec ±0.86% (90 runs sampled)
JSON.parse from string x 291,944 ops/sec ±0.72% (92 runs sampled)
JSON.parse from buffer x 256,325 ops/sec ±1.50% (90 runs sampled)
    Type.decode from buffer was fastest
     JSON.parse from string was 77.4% slower
     JSON.parse from buffer was 80.3% slower
benchmarking combined performance ...
Type to/from buffer x 254,126 ops/sec ±1.13% (91 runs sampled)
JSON to/from string x 122,896 ops/sec ±1.29% (90 runs sampled)
JSON to/from buffer x 88,005 ops/sec ±0.87% (89 runs sampled)
        Type to/from buffer was fastest
        JSON to/from string was 51.7% slower
        JSON to/from buffer was 65.3% slower
benchmarking verifying performance ...
Type.verify x 6,246,765 ops/sec ±2.00% (87 runs sampled)
benchmarking message from object performance ...
Type.fromObject x 2,892,973 ops/sec ±0.70% (92 runs sampled)
benchmarking message to object performance ...
Type.toObject x 3,601,738 ops/sec ±0.72% (93 runs sampled)

接下来要做的事情

PB的优势场景是IM中的数据存储和交互，如果要实现一个高品质的IM，信息流的稳定和边界很重要，我们还需要完善以下几个部分

稳定可维护的Node socket.io服务（socket篇）
PB的动态编译的特性和嵌套message，数据结构简单化（数据篇）
前端对于二级制的的处理，例如ArrayBuffer，序列化与反序列化，MD5加密（加密篇）