0%

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的一些理解:

阅读全文 »