测试平台系列(94) 前置条件该怎么支持Python呢
回顾
上一节我们狠狠操练
了一番oss,但我们的任务还很长久,所以我们需要继续打磨我们的功能。
那今天就让我们来思考下,如何在前置条件
支持python脚本,多的不说,我们也暂时不考虑其他语言,因为光考虑支持python,已经够呛啦。
本文旨在探讨一些思路的可行性,不会实际着手编写。
究竟缺什么
因为我们只考虑Python脚本,所以我们必须认真考虑
我们的需求。
-
能够通过python脚本构建数据
我举个例子,我可以用python脚本实现一些很复杂的功能,而这些功能在当前条件下都不大可能支持。比方说,我想获取当前月的第一天的日期,又或者我想做一些加解密/base64的运算,尽管
pity
可以默认帮助实现这些功能,但总会有意想不到的场景出现。为了解决这些困难,我们可以适当编写脚本完成这些工作。 -
能够支持参数
这里的参数指的是
pity
内置的参数${参数} -
能够获取到
返回值
这个需求大家都能理解,有时候我是想触发一个功能,比如给某些人发邮件,我不需要知道过程,我只要完成这个功能即可。而有时候呢,我需要的是执行过程,并得到
确切的结果
。所以这个功能是必不可少的。
思索方案
要想在python web中执行动态的python脚本,我们可以怎么做呢?
exec
exec是一个能够执行给定python代码
的系统方法,可能也不是很被推荐。它接受的参数是python代码
,举个例子:
# 执行原生python脚本print了一条语句
exec(print("你在肝什么"))
接着我们试试在exec中定义一个方法main,并试试能不能调用。
可以看到是能的,这个我只能说肥肠牛批
!因为我也基本是没用过,只是知道,今天也是和大家一起尝试下。
至于为什么不被推荐,可能是因为危险性过高,毕竟你传入的啥人家都能给你执行掉。
不过好在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的方式,至于第二种,我是有计划也一并加入的。
本节内容就介绍到这里,欢迎大家给出其他想法或者建议,也可以一起讨论。
后端代码仓库: //github.com/wuranxu/pity
前端代码仓库: //github.com/wuranxu/pityWeb