回顾

上一节我们狠狠操练了一番oss,但我们的任务还很长久,所以我们需要继续打磨我们的功能。

那今天就让我们来思考下,如何在前置条件支持python脚本,多的不说,我们也暂时不考虑其他语言,因为光考虑支持python,已经够呛啦。

本文旨在探讨一些思路的可行性,不会实际着手编写。

究竟缺什么

因为我们只考虑Python脚本,所以我们必须认真考虑我们的需求。

  • 能够通过python脚本构建数据
    我举个例子,我可以用python脚本实现一些很复杂的功能,而这些功能在当前条件下都不大可能支持。比方说,我想获取当前月的第一天的日期,又或者我想做一些加解密/base64的运算,尽管pity可以默认帮助实现这些功能,但总会有意想不到的场景出现。为了解决这些困难,我们可以适当编写脚本完成这些工作。
  • 能够支持参数
    这里的参数指的是pity内置的参数${参数}
  • 能够获取到返回值
    这个需求大家都能理解,有时候我是想触发一个功能,比如给某些人发邮件,我不需要知道过程,我只要完成这个功能即可。而有时候呢,我需要的是执行过程,并得到确切的结果。所以这个功能是必不可少的。

思索方案

要想在python web中执行动态的python脚本,我们可以怎么做呢?

exec

exec是一个能够执行给定python代码的系统方法,可能也不是很被推荐。它接受的参数是python代码,举个例子:

  1. # 执行原生python脚本print了一条语句
  2. exec(print("你在肝什么"))

测试平台系列(94) 前置条件该怎么支持Python呢 - 图1

接着我们试试在exec中定义一个方法main,并试试能不能调用。

测试平台系列(94) 前置条件该怎么支持Python呢 - 图2

可以看到是能的,这个我只能说肥肠牛批!因为我也基本是没用过,只是知道,今天也是和大家一起尝试下。

至于为什么不被推荐,可能是因为危险性过高,毕竟你传入的啥人家都能给你执行掉。

不过好在exec的数据可以拿到方法执行的返回值,也可以通过字符串替换的方式获得对应的返回值。

自建python项目

由于代码都是python,我们完全可以用git维护一套python工具库。接着通过动态导入来执行对应的方法,这样做的好处是更灵活,但也伴随着更高的成本。

我们得去更新代码(包括监听git push钩子,或者定时拉取以及手动更新),还得提供一个编辑页面,可以让用户更改对应的代码。

但最烦人的还是有扩展包的时候,我们的web项目甚至都需要去安装扩展包

说起原理倒不难,简单的说就是内嵌了一个python文件目录,通过import导入对应的方法并执行。

http的方式(不推荐)

新启动一个服务,里面提供了一个api,通过传入method,param等信息,实现调用方法并拿到返回值的效果。

缺点就是代价比较大,起了新服务,如果服务挂掉影响较大。优点是能够跨语言,但是还是偏了。

mq

有http就可以有mq的方式,通过生产者和消费者去解耦A系统依赖B系统的逻辑,用消息队列来处理相关逻辑,可以用rabbitmq完成这样的工作。

grpc

虽然grpc很强大,但是不推荐,虽然跨语言是个非常诱人的特性,但是对于新人不太友好,有一定的学习成本,底层虽然改用rpc调用,序列化升级为protobuf会更高效,但学习成本高,官方也没有好的负载均衡/服务注册发现方案,对于不同语言甚至要实现不同的一套逻辑,开发成本也不低。

总结

上面大概列举了5种方式,我个人比较相对推荐的还是exec,内置python包和mq的形式。

方案 多语言 成本 稳定性 额外组件
exec
import
http
mq
grpc 非常高

mq的缺点就是需要实现不同语言的消费者以及需要引入额外的组件。由于我们暂时只支持python,所以我们优先选择第一种exec的方式,至于第二种,我是有计划也一并加入的。


本节内容就介绍到这里,欢迎大家给出其他想法或者建议,也可以一起讨论。

后端代码仓库: http://github.com/wuranxu/pity
前端代码仓库: http://github.com/wuranxu/pityWeb