code学习

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

回顾

上一节我们狠狠

操练

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

那今天就让我们来思考下,如何在

前置条件

支持python脚本,多的不说,我们也暂时不考虑其他语言,因为光考虑支持python,已经够呛啦。

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

究竟缺什么

因为我们只考虑Python脚本,所以我们必须

认真考虑

我们的需求。

  • 能够通过python脚本构建数据

    我举个例子,我可以用python脚本实现一些很复杂的功能,而这些功能在当前条件下都不大可能支持。比方说,我想获取当前月的第一天的日期,又或者我想做一些加解密/base64的运算,尽管

    pity

    可以默认帮助实现这些功能,但总会有意想不到的场景出现。为了解决这些困难,我们可以适当编写脚本完成这些工作。
  • 能够支持参数

    这里的参数指的是

    pity

    内置的参数${参数}
  • 能够获取到

    返回值

    这个需求大家都能理解,有时候我是想触发一个功能,比如给某些人发邮件,我不需要知道过程,我只要完成这个功能即可。而有时候呢,我需要的是执行过程,并得到

    确切的结果

    。所以这个功能是必不可少的。

思索方案

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

exec

exec是一个能够

执行给定python代码

的系统方法,可能也不是很被推荐。它接受的参数是

python代码

,举个例子:

# 执行原生python脚本print了一条语句
exec(print("你在肝什么"))
           
测试平台系列(94) 前置条件该怎么支持Python呢

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

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

可以看到是能的,这个我只能说

肥肠牛批

!因为我也基本是没用过,只是知道,今天也是和大家一起尝试下。

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

不过好在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

继续阅读