阿里工程师教你 3 分钟实现数据源编排和接入( 二 ) _数据源编排

文章插图
如图所示，其中先按层次遍历ROOT，但这是一个虚拟的节点不处理，之后调处理A和B，这里可以并发调用，也可以顺序调用，交给数据源调用层来处理。A和B处理完成后，处理A的子节点和B的子节点C、D、F 。直到所有节点都处理完毕。

第三：如何映射结果

引擎调用数据源后，需要根据表达式来进行结果映射。如果是需要自定义返回的每一个key，比如调用视频查询，默认返回的key为id，而需要向业务方返回的是vid，可配置key的值表达式。设计时希望表达式尽量简单，于是设计出了这样一种表达式，比如vid，可配置为datasource.video.response.id 。
3）动态脚本的执行与优化

第一：为什么选择Groovy

因为整体技术栈是Java，因此首选的脚本语言就是基于JVM，而选择Groovy一是因为成熟，同时语法比Java简洁，二是因为接入简单（只需一个jar包），三是因为本身兼容Java的大部分语法，学习成本较低。

第二：Groovy遇到的问题和解决办法

主要是安全问题和性能问题。安全的问题非常严重，因为脚本是交给用户输入的，所以很容易出现风险代码。系统对Groovy的编译器进行了一系列自定义，同时使用沙箱，将代码进行拦截，过滤掉敏感操作，最大化避免风险代码的执行。
性能上，Groovy的性能远比Java慢，于是进行了一番优化，比如将Groovy的代码进行预编译和缓存，保证执行时不会发生编译动作，保证执行一个Groovy单条脚本不会有太大的性能问题。

第三：最终解决方案

经过测试，发现Groovy本身的执行效率还是要低，因为一次请求可能需要执行成百上千次的脚本，一次执行的性能问题不明显，但是多次执行问题很容易就暴露出来，比原生的Java执行仍然有百倍的差距。
这个既然是Groovy的问题，并且无解，就想到了是否可以用其它的方式替换Groovy，于是研究了各种表达式引擎包括Aviator、FEL、MVEL、JSONPath、Java动态编译。并且对这些代码进行测试，使用两条语义相同的代码，分别编写了不同脚本的版本，与Java原生的代码进行比对。长时间运行后结果如下：

文章插图
上图为两个脚本执行1000次的耗时，发现使用Java动态编译和JSON-Path，性能比Groovy提升了约150倍。但是缺点也非常明显：JSON-Path是能写单行的取值语句，而Java语法复杂、不方便写内部类和方法等。考虑到使用场景，Java和JSON-Path满足95%以上的场景，可再用Groovy写更复杂的脚本。

文章插图
稳定性
稳定大于一切，接口调用稳定性是重要一环，如何保证稳定性呢？1）有问题时要能及时的报警，2）为了整个应用的稳定性，需要自动熔断。
1、监控报警

文章插图
因为元数据中心SDK是去中心化的，接口的调用逻辑发生在业务应用本地，SDK利用logback的Appender扩展将日志异步发送到日志服务中，再用监控平台采集日志服务的日志，在监控平台中完成监控报警的搭建。元数据中心SDK还集成了调用链监控平台，不但可以在业务应用对应的调用链监控平台上看到接口调用情况，还利用了logback的ClassicConverter扩展，在日志中统一加入调用链唯一ID,方便通过该ID查看全链路日志，以达到快速定位问题的目的。
2、熔断降级
如果你的应用有外部依赖，那么保证系统稳定性，熔断是必不可缺的手段。想象一下，某个依赖的RT突然变高，如果没有及时熔断，那么你应用的线程池资源很快会被该依赖消耗完，且整个应用将无法响应，造成雪崩，所以熔断的重要性是不言而喻的。元数据中心目前支持三种熔断策略：RT、秒级异常比例、分钟异常数。

文章插图
实践提效
说了这么多，究竟能否为业务开发提效呢。实践是检验真理的唯一标准，接下来让我们一起来看下元数据中心如何与业务结合，为业务开发提效。
1、与内容分发开发框架集成
目前优酷主APP业务基本上是统一的内容分发开发框架开发的，那么与内容分发开发框架集成，是为业务开发提效最好的切入点。内容分发开发框架虽然具有强大的配置能力，但是它的数据源开发还是面临到处找接口，学习怎么调用，然后引入二方包，hard code，提测，aone发布一系列漫长而重复的操作。另外一旦有接口需要切换或者业务需要增加字段等变更操作，还需要通过hard code方式改动，这样不但开发效率比较低，频繁的发布还增加了系统不稳定性。结合元数据中心的目标，内容分发开发框架集成元数据中心就可以完美解决它的痛点：