由於之前思路使用natapp對映，但是個人是個比較愛折騰的人，覺得配置域名比較麻煩，於是就大致對整個系統思考了下，準備把APP承擔的服務端職責抽離出來，大致以下倆個思路

1、APP和服務端不進行TCP連結，而是使用一種比較迂迴的方法，作為使用者端不再去請求APP拿二維碼資料，而是去請求JAVA服務端，這個服務端也並非使用TCP，可使用信鴿推送之類的，也可以自己操作，具體思路很多種看自己怎麼選方案最合適自己業務以及實現簡單，使用者請求WEB伺服器儲存資料起，APP直接不斷輪詢WEB伺服器有沒有使用者請求過來，有就去獲取資訊，可一次性拿多條，然後批量返回，最後WEB伺服器標記這些資料已處理，但是這種方式比較耗資源，好吧不考慮了。

2、APP開啟主動連線JAVA服務端，TCP協議，所有指令由伺服器下發，使用者請求服務端服務端立馬推送給到指定的APP生成資料，通過IMEI進行唯一的連線，其實也可以自定義加密key值和APP協議好就行，APP生成之後推給服務端，由服務端再返回在使用者請求的介面上，然後APP端接下來的任務就是監聽，只要監聽到了就馬上發給伺服器，伺服器就呼叫使用者提供的介面，告訴他支付完成了，間接性請求三次，直到使用者端給出了反饋將不再發起呼叫。面對較大規模併發，啥也不說了堆手機，輪詢演算法，保證分配下發到每一臺機器比較均勻就可以了

不足：為了避免掉單，應該配合PC端監控，配合APP監控，我想應該穩定性比較好了，丫的這個zfb倆分鐘不間斷重新整理讓人頭大，想放棄了，也有大佬提供了迂迴方法，利用第三方監聽不去監聽zfb了，或許可以採用，至少也是個辦法。emm把它幹入後臺管理系統

下面是個測試環境圖，頁面有點醜也不用在乎了，晚點把它美化下。

該APP可以對接遊戲，電商等網站，一律使用HOOK操作動態生成，再也不用麻煩的上傳二維碼了，配合TCP堆機器解決併發問題，有興趣可以聯絡Q：157934991，歡迎大佬一起學習討論技術，擼串閒聊吹牛逼