面对成百上千的生产系统用户操作数据接入落地，你是否厌倦了每次机械编写打包解包的代码？对一次性接入多个数据的时候，还要对不同人联调，费时费力，你是否还会手忙脚乱，忙中不断出错？是否当数据出问题了，用的时候才发现，数据已经损失大半，产品/领导压力巨大，费一天劲才能定位问题，关键是下次还是不能实时发现，快速定位。
怎么办？GAS（通用解析服务）就是为了解决上述问题，结合即通多年数据方案实践，提出的一个数据接入的组件。一杯清茶，轻点鼠标，轻松面对大批数据接入问题。
GAS在ADs中的位置
图 1 ADs整体框架
GAS（General Analyses Service）通用数据解析服务，用协议描述语言（Protocol Description Language – PDL）去描述数据，动态解析数据，实时按规则去除脏数据，实时整理数据，实时告警（需结合网管系统monitor使用）。即可作为分布式，也可作为单机版使用。解析引擎是插件式的，针对不同的协议，只需要开发相应插件即可。
GAS实现原理
GAS的整体框架
图 2 GAS整体框架
GAS master负责数据服务描述文件的管理，所有数据服务描述文件的添加、修改都在GAS master管理。
GAS框架的主要优点：
1） interface主要分发不同数据到不同GAS broker、分发相同数据到不同GAS broker、分发不同协议的数据到运行不同解析插件的broker，分发数据到不同的对外应用，interface只是一个逻辑层。
2）GAS slaves分成不同的broker，每个broker接收不同的数据，或者一个数据可以在不同的broker接收多份，broker之间完全独立。分broker可以分等级运营数据，方便运营，并且不同broker可以运行不同的解析插件，还可以减少路由表的下发包。
3）GAS slaves是去中心化的，GAS master死机只会影响服务描述文件的更新，不会影响已有数据的接收。
4）数据之间是相互独立的，一个数据协议的错误，不会影响到其它数据。
GAS master
图 3 GAS Master框架
1）master机器上的配置模块，负责生成新数据的注册信息，可以登录ads.server.com，填写相关协议描述，就可以自动生成协议描述语言的配置文件。
图 4 服务描述配置页面
2）检查配置文件模块，负责将新的配置读到内存，生成数据解析状态机，以检查是否能正常生成，可以测试协议是否正确。
图 5 协议抓包实时调试页面
3）将正确的数据注册信息更新在测试环境，如果用户确认正确，那么我们可以一键发布到正式环境。
4）slaves每分钟访问一次master，检查是否有新的注册信息，如果有更新，则拉取服务描述文件到本地。
GAS Slave
图 6 GAS Slave框架
slave服务器主要分为两部分：agent进程和数据处理进程，两个模块主要通过共享内存head_mem进行交互，详情如下：
1）agent进程负责每分钟检查一次配置文件是否有更新，如果有更新，则拉取新的服务描述文件到本地磁盘，将更新信息写入共享内存head_mem中，然后修改共享内存中head_mem的版本号。
2）先说明一下，我们每个数据都有一个唯一的标识，我们称为topic_id。每个数据的组包格式必须是Stx+topic_id+stBody+Etx，stBody是用户信息。这样我们收到一个包，就可以判断这个包是那个数据。
服务描述文件大致可分为3部分：基础信息配置，解析字段配置，导入信息配置。基础信息配置中包括日志相关、本地ip、端口、项目负责人等一些全局的配置信息。解析字段配置是收到一个包后，按什么顺序解析、以及按什么格式解析字段。由import_opt_name配置项关联导入信息配置。当在解析过程中，遇到某个字段有import_opt_name配置项时，触发该配置项对应的写共享内存操作。
数据处理主要做以下两个工作：
A）每次接收数据后都检查head_mem中的版本号是否与已知版本号相同，如果版本号不同，则可以判断是那个topic_id的服务描述文件更新了，如果这个topic_id的服务描述文件是新增，那么根据该topic_id服务描述文件生成对应的数据解析状态机。如果是修改，则根据该topic_id配置文件生成对应的数据解析状态机。加载成功，那么释放该topic_id对应的原有数据解析状态机。
B）收到一个数据包，根据topic_id判断调用哪个数据解析状态机，解析生成结构化数据，然后调用COW的接口进行存储。
状态机生成和数据解析实例
一个数据的协议为Stx+topic_id+dwIP+cFlag+wCount+stUin+Etx；stUin=ddwUin+dwID。wCount是stUin的大小，stUin为一个UIN、ID的结构体，假设wCount=2，那么stUin包含ddwUin1、dwID1和ddwUin2、dwID2。解析字段列表为dwIP（short）、cFlag（char）、stUin（数组），stUin后面是导出字段列表dwIP、cFlag、ddwUin、dwID。
Stx、Etx是协议的开始、结束标志，topic_id是协议的唯一标识。
状态机生成过程
图 7 状态机生成过程
状态机生成的过程是：（1）读取服务描述文件，动态生成Config对象，根据服务描述文件中的基础信息配置，填充Config的属性，包括Socket属性。（2）根据服务描述文件中的解析字段配置，动态生成Socket中Field列表IP对象、Flag对象、Count对象、stUin对象；stUin对象依赖Count对象，包含Uin对象、ID对象。（3）根据stUin对象后的import配置，生成stUin对象的Import列表信息。
数据解析过程
数据解析过程与状态机生成过程类似，通过topic_id找到对应的Config对象；然后根据IP对象解析出IP的值，根据Flag对象解析出Flag的值，根据Count对象解析出Count的值为2，根据stUin对象，stUin对象包含Uin对象、ID对象，那么解析出Uin的值、ID的值。stUin对象有import列表，重新组包IP、Flag、Uin、ID的值写出。因为Count为2，再解析出Uin、ID的值，重新组包IP、Flag、Uin、ID的值写出。数据解析状态机是预先生成的，不是动态生成的，这样可以提高数据解析性能。
性能测试
使用部门平均包长度进行测试，测试结果如表1。
表 1 协议解析性能测试
机器类型
cpu 70%解包量
最大解包量
B1老机器（Intel(R) Xeon(R) CPU E5405 @ 2.00GHz cache size: 6144 KB 4核）
8w/s
14w/s
C1新机器（Cpu:Intel(R) Xeon(R) CPU X3440 @ 2.53GHz cache size : 8192 KB 8核）
18w/s
30w/s
展望
从上面介绍，我们还有一些工作需要做：
*protobuf协议插件，已经在测试中。
*txt协议插件，正在开发中。
*增强协议修改前后的兼容性。