回顧
上一節我們狠狠操練了一番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