转眼距离上次博客已经快一年了-_- !，虽然krproject的开发时断时续、进展不多，但为了不让这里长草太深，还是想写点文字记录下这一年有关krproject的设计和开发情况吧，也算是对思考的一个整理和记录吧！

回归krproject的定位：基于大数据量的实时流数据分析系统，它由如下几个部分组成：

• krengine： 核心数据分析引擎，基于规则的带流程控制的处理模块，以动态库发布；
• krserver： 引擎服务器，是对krengine的包装，以tcp为传输层、自定义的协议层，以可执行程序发布；
• krcoordi： krserver的集群协调器，基于一致性hash算法的集群调度器，以可执行程序发布
• krshell： krserver的命令行终端，与krserver交互的终端管理程序，以可执行程序发布
• krweb： web管理前端，提供对引擎的输入输出数据源定义、数据项、规则的管理，以web资源发布

krweb

先前花了点时间将这个krrule规则编辑器完善了下，完全以jquery插件的方式开发，效果图如下：

想法起源

这段时间在给krproject写interface generation，因为krproject的接口是通过数据库表描述的（数据源定义表kr_tbl_datasrc，数据源域定义表kr_tbl_datasrc_field，数据源索引定义表kr_tbl_datasrc_index）。

当初这样设计的考虑是是：一方面对于前台，可以简单方便通过页面的配置接口、以及规则及其他配置时对接口字段的直接引用；另一方面对于后台，程序通过域序号的方式获取该接口某字段的名称、类型及值（目前通过数组实现，要求配置时序号要与数组下标一致，换成哈希表就不会有此限制了，甚至可以通过字段名来访问该域了，但也多了个hash查找的时间）；

当我前段时间在写krclient的时，我发现原来这两张表实际就是一种简单的不带服务接口，暂时没有复杂数据类型的IDL（Interface description language，接口描述语言），那它带来的好处就在于我可以通过写个小工具，根据接口定义，可生成固定长度的C struct接口文件；生成格式灵活一些的json或者xml样例文件；生成不同序列化框架的描述文件（比如：google protobuf的.proto文件、apache thrift的.thrift文件、apache avro的.avsc文件）。

个人理解

于是我便花了些时间学习了下一些主流的序列化框架，接下来就谈谈我对于接口interface、远端过程调用RPC及序列化serialization的一些理解：

这个月最主要的工作就是将krproject的客户端krclient和命令行接口（command line interface）krshell大致写完了，并新建了一个github项目，将他们放上去发布了。

其实之前的krclient并不是真正的客户端，充其量算一个krserver测试程序罢了，在我想写一个命令行管理终端时，我意识到这一点，然后看了些redis和mysql的源码，原来他们都是基于client的，在此基础上，封装对命令行的解析处理，然后便是客户端接口调用。

意识到这点后，便开始了客户端krclient的开发，然而我发现之前krengine提供的接口太少了，而且格式并不友好，所以想到将接口api统一为方便易读的json格式，便有了对krengine以及内部各个模块的接口函数编写。当然，krengine暴露的接口依然还是kr_engine_run，只不过在内部构建了一个msgtype – handle_func的映射表，目前提供的接口大概也有近20个吧，后面也会继续完善的。