為什麼要對接改造？ 我們公司是做增值稅管理系統的，增值稅系統涉及到開發票的業務，需要與不同的供應商對接開票介面，供應商提供的開票介面，包括四種：A1供應商有兩種，第一種是開票伺服器，第二種是稅盒 A2供應商也是一種是開票伺服器，一種稅盒。 客戶有用稅盒開票的，也有用開票伺服器的，各種情況都有 我們的 ...
為什麼要對接改造？
我們公司是做增值稅管理系統的，增值稅系統涉及到開發票的業務，需要與不同的供應商對接開票介面，供應商提供的開票介面，包括四種：A1供應商有兩種，第一種是開票伺服器，第二種是稅盒 A2供應商也是一種是開票伺服器，一種稅盒。
客戶有用稅盒開票的，也有用開票伺服器的，各種情況都有
我們的產品有兩個開票歷史版本，一個歷史版本是 有一個WEB和一個開票客戶端
如圖：
每一次要開票的數據，都要先經過web端處理完之後，存到資料庫裡面，然後再打開開票軟體，進行開票
這樣的缺點：1.操作繁瑣，2.客戶要裝很多額外的軟體
後來我們進行了第一次改造，就是藉助Active 控制項與本地機器通信，如圖：
這樣的話，客戶不用再像歷史一一樣，需要安裝一個客戶端軟體進行複雜的操作，但是active控制項是有缺點的：一個是只有IE用，一個是配置複雜，測試人員因經常配置不好active控制項，導致測試效率問題
現在的話，公司專門針對於這個問題，開發了一個穩定，不受瀏覽器限制，可以共用，集群開票的基礎服務性軟體，簡單結構圖如下：
這樣的話，調用端不用，再像歷史二那樣，安裝activce，不受瀏覽器限制，可以共用開票機器
- 調用者請求業務服務，WEBService接受到請求會先對要傳遞的數據進行校驗
- 校驗成功，給調用者一個受理信號，然後將要處理的業務請求，發送到MQ消息對列裡面去，等待任務被處理
- WebSocket會根據登錄的開票機客戶端，查找到要請求的開票機器號，並將數據發送到開票客戶端
- 待開票客戶端完成，開票的操作之後，將結果返回到調用方
- 最後，調用方，將處理完的結果，回寫給調用方
基於歷史版本，我要做的就是把原來歷史二的開票方式，給替換成遠程消息隊列的模式。
要考慮到的一些點如下：
- 原來有本地，調用active開票的，也有遠程開票
- 有A1廠家開票模式，也有A2廠家開票模式
- 要提供回調服務，要考慮非同步回寫
- 要方便以後的修改
- 要可以執行不同的開票動作
設計瞭如下的改造結構：
用戶可以針對於不同的業務進行回寫服務的擴展和開票服務的擴展
可以添加不同的廠商開票方式
相容原來的模式，前端只需要向後端傳遞數據，告訴執行什麼動作
就可以按既定的業務模式執行業務了
