intro

互联网时代，服务型企业将自己的功能服务封装成一系列API（Application Programming Interface，应用编程接口）开放出去，供第三方开发者使用，正成为一种趋势，所开放的API也就是大家熟悉的OpenAPI。

之前有写过一篇关于接口的文章，接口的定义其实就是：软件接口是用于两个模块间交互的共享数据边界，它提供：常量定义，数据类型及结构定义，方法描述及异常指定。

进程内部接口调用和机构内部跨系统的调用，因为基本在一个局域网内，相对是安全的，一般不太会考虑到安全方面的内容。

而开放平台则属于跨机构的接口调用了，这里我们主要探讨下在开放平台下的接口调用安全性问题。而关于开放平台本身的接口设计与建设过程不在本文中阐述了！

转眼距离上次博客已经快一年了-_- !，虽然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的一些理解：