1. 项目背景
最近产品研发中我们设计了一个算法集成规范，定义了一个统一的算法服务API接口，并通过产品的“模型管理”模块进行算法服务的配置，从而实现外部算法服务的灵活集成与扩展。
这个模式对于新开发的算法是没有问题的，按照定义的接口规范实现就可以轻松地集成。但是对于已有的算法，或者遇到客户比较强势不愿意改自己接口的时候，就比较尴尬了。有没有什么比较好的方式能够解决这个问题呢？
另外，网上有很多开放的API服务，可以非常方便地进行调用。但是尽管大部分API都采用JSON格式作为返回数据格式但却格式不同，如何能够方便进行利用呢？
2. 需求提炼
根据场景问题，我把需求进行了提炼，问题转化为：设计一个通用的工具，以JSON数据作为输入，根据指定的规则进行数据格式转换、数据提取，从而解决上述问题。
目前仅考虑支持JSON，主要是大部分线上API服务（我司全部后台服务）使用JSON作为返回值格式，甚至采用标准restful 形式。
那么，对于规则应该如何提炼、设计呢？初步考虑也采用JSON语法，JSON本身相对简单、容易理解，对于不太了解编程开发的人来说会比较友好。关于JSON语法规范，建议大家直接看JSON官网，非常好理解。
下一步就是对JSON规则进行设计
3. 规则设计
我目前先考虑几种简单情况。
（1）样例数据设计
{
code: 20000,
msg: "abcde",
data: {
ner: {
name: "aaa",
type: "person",
start: 5,
end: 7,
info: ['abc']
},
events: [
{type, subtype, trigger}
],
ent_name: [
"a", "b", "c"
],
ent_type: [
"person", "loc", "org"
]
}
}
（2）单值规则
1. $ 代表顶层，即输入本身（当前处理的顶层）
2. x.field 表示x为JSON对象，获取x的field字段；支持特殊field：$len 表示字符串或数组长度；$keys 表示获取字典的key组成的数组
3. x[y] 表示x为JSON数组，获取x数组的第y项元素
4. 上述规则可以嵌套，从而支持任意层次的单值信息获取（除非获取元素本身为数组）
示例如下：
- $.code -> 20000
- $.data -> {ner, events }
- $.data.ner.name -> 'aaa'
- $.data.ner.info[0] -> 'abc'
- $.data.ner.$keys -> ['name', 'type', 'start', 'end', 'info']
- $.data.events.$length -> 1
- $.data.events
（3）对象规则
5. 对象规则，返回对象 { "a": "aaa" } 没有变量，返回规则本身；{ "a": "$.a[2].e"} 根据指定规则获得a的值
6. key为$root 用于指定当前访问的顶层节点
7. key为$val 用于将本规则返回值作为当前层级的值
8. key为$fun 用于提供一段脚本函数（例如js脚本，待定）进行执行，以函数返回值作为该字段的值，用于应对复杂情况
示例如下：
{
"$root": "$"
"data": {
"$root": "$.data.events",
"$val": "$"
}
}
->
{
"data": [
{type, subtype, trigger}
]
}
（4）数组规则
9. 数据规则返回数组，数组中每个元素为一个新的规则
示例如下：
["$.data.ent_name[0]", "$.data.ent_type[0]"]
->
["a", "person"]
（5）其他待考虑情况
基于目前了解到的API形式，还有以下需求上述规则未能很好覆盖：
- 对于对称的子树，如果自动进行匹配返回？例如示例数据中，需要对ent_name和ent_type进行配对返回：
[["a", "person"], ["b", "loc"], ["c", "org"] ]
这里的问题是数组长度是不定的，且横向的数量也是不定的（请大家想象一棵树，水平的多个子树）。另外对于对称的JSON对象节点又应该如何处理？
- 如何实现对获取值进行映射？比如上述NLP结果中返回的person（人物），需要转换成统一标识PER
- 如何实现根据业务逻辑进行获取？比如上述实例数据中如果
code不等于20000，就应该返回错误
这留待后续进行完善。
4. 程序设计
把规则描述清楚了，其实主要工作就结束了，因为这个问题就是树遍历+文本处理问题，类似SQL解析、模板消解或着编程课里面小儿科的“手写计算器”之类的问题。
说一下主要思想：
- 首先JSON值是一棵树，输入规则是JSON，所以也是一棵树，带着规则对树进行遍历，直到获取所有数据。由于是多叉树，所以一开始别想着用循环进行树遍历，那样太累了，直接上递归。在限定数据规划和栈层次的情况下，不会发生溢出，这一点我可以保证，信不信由你 ^^
- 根据当前规则的类型进行判断，如果是字符串，并且以$开头，那么肯定是简单规则，一撸到底
- 再看是否是对象规则，区分几种特殊key的情况：
3.1 $root 这是相当于上下文跃迁，直接把当前数据节点定位到了指定的数据节点上了，甚至可以新建一个上下文 与原来的节点可以毫无干系
3.2 $val 是指定获取的值直接作为当前对象规则的返回值，所以要直接返回
3.3 $fun 是指定用函数进行评估，这个函数具体用什么语言（JS还是python），稍微有点复杂（例如跨语言）后面再考虑，但是基本可以确定需要传递给函数的是当前节点和当前规则
3.4 其他特殊key考虑，可能涉及调整优先级，目前暂无
3.5 进行对象遍历，相当于以输入为模板对象，进入下一层
再看是否是数组规则，目前比较简单粗暴，直接遍历数组，递归进入下一层，最后返回数组值
其他情况，直接返回当前数据节点
5. 简单规则解析
在上述思想框架下，剩下一个叶子节点问题，那就是对简单规则进行解析。直接点，上状态机：
状态转移矩阵：
在此状态图指引下，很容易写出相关程序，这里不再赘述。
初步效果如下：
6. 错误处理
如果规则不符合约定规范怎么办？这个时候肯定需要进行错误处理。程序里面唯一没有问题的就是总是有问题！
目前简单的想法就是在遇到错误的时候返回错误状态，但是解析过程会尽可能继续。
主要考虑的几种错误包括（再看一下状态图）：
- 期待
.或[，但遇到了其他字符，Invalid Start - 期待其他字符，却遇到了
.或[，Invalid Token -
[开始的token，没有遇到]，Dangling [ -
"开始的token，没有遇到结束的引号，Dangling " -
]结束的token，发现不是数字 Invalid Index
7. 设计细节
- 把简单规则归纳为以$开头，包含0个或多个<操作, 参数>的列表，解析过程就是获取每一个操作及其参数，操作分为
.操作和index操作，分别对应对象和数组的访问 - 我利用了Python的生成器机制，符合条件的时候就
yield返回，从而解析函数可以被当做迭代器来遍历 - 为了支持特殊符号的key，引入引号，凡是引号括起来的内容都是一个token
- 添加一个简单的校验函数，通过调用解析函数，发现错误即失败返回
8. 工程化设计应用
目前为止只是实现了一个工具，可以单独运行，但是不能很好地提供给别人使用。那么需要考虑几个方面：
- 服务化，基于Web框架，实现Web服务，支持接收数据和规则，返回解析结果。常见的Python Flask和Java SpringBoot都可以很方便地实现。
- 持久化，规则多了之后就需要管理，由于规则相对来说不变，优先考虑把规则存储起来，并分配一个ID，使用时，只需要传递数据和规则ID即可。常用的MySQL和MongoDB都可以推荐。使用MongoDB的时候，注意MongoDB的查询语法也是JSON，因此建议对规则进行JSON序列化，保存为一个String字段
- 服务集成，不仅要保存规则，还要保存服务相关的信息，基本信息包括API地址、请求方法、请求头固定参数、请求体固定参数等。请求服务时，由客户端指定服务ID、规则ID，以及请求头和请求体中变化的参数，基于服务基本信息封装成最后的请求后执行，对返回结果应用规则获取输出并返回给客户端。这里主要涉及HTTP的知识。常用的库requests、urllib、Apache HttpClient等
- 规模化调用，系统如果涉及大量的服务集成调用或大量规则需要分别执行，可以采用多线程、多进程、消息中间件等技术，实现任务调度。推荐使用消息中间件（如Kafka），将任务写入队列中，并启用多个消费者或流处理引擎（Spark 或 Flink）进行消费执行
- 自动化，基于触发或定时进行自动化调度。crontab就很好用。
9. 下一步考虑
- 完善规则设计和解析引擎，使得规则更加强大
- 算法服务集成的demo系统，提供简单前端界面进行配置
- 线上数据服务持续集成，实现特定领域数据快速获取和持续积累