ADs系列之通用数据解析服务GAS(即将开源)

 

    面对成百上千的生产系统用户操作数据接入落地,你是否厌倦了每次机械编写打包解包的代码?对一次性接入多个数据的时候,还要对不同人联调,费时费力,你是否还会手忙脚乱,忙中不断出错?是否当数据出问题了,用的时候才发现,数据已经损失大半,产品/领导压力巨大,费一天劲才能定位问题,关键是下次还是不能实时发现,快速定位。

    怎么办?GAS(通用解析服务)就是为了解决上述问题,结合即通多年数据方案实践,提出的一个数据接入的组件。一杯清茶,轻点鼠标,轻松面对大批数据接入问题。

GAS在ADs中的位置

wps_clip_image-2473

图 1  ADs整体框架

    GAS(General Analyses Service)通用数据解析服务,用协议描述语言(Protocol Description Language – PDL)去描述数据,动态解析数据,实时按规则去除脏数据,实时整理数据,实时告警(需结合网管系统monitor使用)。即可作为分布式,也可作为单机版使用。解析引擎是插件式的,针对不同的协议,只需要开发相应插件即可。

GAS实现原理

GAS的整体框架

wps_clip_image-17187

图 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

wps_clip_image-2147

图 3  GAS Master框架

    1)master机器上的配置模块,负责生成新数据的注册信息,可以登录ads.server.com,填写相关协议描述,就可以自动生成协议描述语言的配置文件。

wps_clip_image-336

图 4  服务描述配置页面

    2)检查配置文件模块,负责将新的配置读到内存,生成数据解析状态机,以检查是否能正常生成,可以测试协议是否正确。

wps_clip_image-9073

图 5  协议抓包实时调试页面

    3)将正确的数据注册信息更新在测试环境,如果用户确认正确,那么我们可以一键发布到正式环境。

    4)slaves每分钟访问一次master,检查是否有新的注册信息,如果有更新,则拉取服务描述文件到本地。

GAS Slave

wps_clip_image-8578

图 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是协议的唯一标识。

状态机生成过程

wps_clip_image-6242

图 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协议插件,正在开发中。

    *增强协议修改前后的兼容性。

posted @ 2014-01-17 17:22 TheBug 阅读(...) 评论(...) 编辑 收藏