测试平台系列(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的方式，至于第二种，我是有计划也一并加入的。

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

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

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