背景：還是兩臺服務器的同步問題。以前我們使用了堅果云同步，這一次我們用網絡策略解決。
整個流程：
- 用戶上傳圖片至 aliyun 的 input 文件夾【格式：13位時間戳+media_id】，自定義風格圖片傳至 input_user 文件夾；風格圖片傳至 style 文件夾【格式：13時間戳】
- 將 aliyun 的 input 文件同步到 dnn 的 input，同時將原圖片 mv 到temp 文件夾【避免同文件夾的新文件判斷】；同步 input_user，切至 temp；同步 style，不移動【根據 input_user 圖片的前13位時間戳可以推出風格圖訪問路徑】
- dnn 服務器拿到 dnn 的 input 圖片處理，同時切至 dnn 的 temp，移動策略同 aliyun；輸出圖片到 ouput【格式：原來的基礎上加“O”前綴】；
- dnn 服務器將 dnn 的 output 圖片同步至 aliyun 的 output 文件夾，同時將原圖片 mv 到 copy 文件夾【避免同文件夾的新文件判斷】；
- aliyun 將 output 的圖片通過文件名與 MySQL 記錄找到圖片用戶發送推送，同時將原圖片切至 copy 文件夾。
線程：
根據以上流程，我們規劃為以下線程
- 微信服務相關，包括數據庫支持，token jssdk校驗請求...
由阿里云服務器的 php + MySQL + nginx 環境支持； - 阿里云 input 同步至 dnn服務器 input
dnn 服務器部署 python RESTful API：
nohup python app_get_id.py > app_get_id.out 2>&1 &
阿里云腳本每30s掃描 input 文件夾，將圖片名發往 dnn 接口：
nohup python check_input.py > check_input.out 2>&1 &
阿里云腳本每30s掃描 input_user 文件夾，將圖片名發往 dnn 接口：
nohup python check_input_user.py > check_input_user.out 2>&1 &
dnn 接口獲取圖片名稱后拼出 url 下載圖片，實現阿里云 input 同步 dnn input，input_user、style同理； - dnn 服務器的深度學習程序：
nohup ./supervise.sh & - dnn output 同步至 阿里云 output
阿里云部署 python RESTful API：
nohup python app_get_upload.py > app_get_upload.out 2>&1 &
dnn 每30s掃描 output 文件夾，將圖片上傳至阿里云 API 接口：
nohup python check_output.py > check_output.out 2>&1 & - 阿里云服務器設置 crontab 任務掃描 output，發送微信推送
->crontab -e
->* * * * * sleep 15; /usr/bin/php -f /home/webwe/www/piconline/mubanxiaoxi.php >> /home/webwe/www/piconline/mubanxiaoxi.txt
比較：
以上可以看出，整個服務由多個接口任務組成，頻繁掃描文件夾，有點多看起來很繁瑣。
另一種方案：環環相扣回調，比如用戶上傳完圖片后通過回調啟動 input 同步。dnn 完成圖片加工后通過回調啟動 output 同步，同步后再回調啟動推送。一氣呵成。
這種方案最大的缺點是邏輯過度耦合，各種服務嵌在一起，一旦某一環節掛掉，整個服務流程需要排除，十分困難。
將整個服務拆成多個任務后，各任務相互獨立互不干涉，input 同步進程只管同步 input 的事情，其他一概不管。進程掛掉的時候只需在自身小范圍解決，其他的 output 照樣同步，dnn 照樣跑圖片。
