回顾
上一节我们狠狠操练了一番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
