最近有個項目需要本地處理之後，然後調用第三方接口，本來開始覺得很簡單得事情，不就是調用第三方接口嗎？但是卻一波三折。
初版
首先有了下面的第一版的設計。
這個設計很簡單，也是最容易想到的。主要有下面幾步
1、本地處理；
2、調用第三方接口；
3、本地日誌打印，包括是否調用成功及失敗原因等；
看似很簡單的過程，卻在線上出了問題，我們說看一個功能是否穩定，不是看99.9%的正常，而是看0.01%的失敗。沒錯，線上報錯了，問題出現在調用第三方接口的時候由於網絡問題，超時了，真尷尬，
分析這個方案有以下幾個不足，
1、沒有重試功能；
2、調用接口記錄未持久化；
爲此在第一版的基礎上做了修改；
優化版本
優化版本考慮了上面的兩個不足之處，對調用第三方接口進行了重試，且把調用記錄寫進本地表；
改進方案有幾個需要注意的地方，
1、重試，由於是第一次調用失敗便要重試，要注意重試的次數，可以在系統中設計一個最大重試次數（比如5次），超過最大重試次數不再重試，每次的重試可以有一定的間隔，可以採用當前線程睡眠的方式，睡眠的時間可以隨着重試次數增大二增加；
2、記錄調用日誌，這裏調用日誌記錄在mysql中，mysql的表結構可參考，
另外，由於包含重試，對於調用日誌的話，考慮是否要區分重試日誌；還有一點就是是否需要一個最終的調用結果。
改進版上線後，返現確實線上調用第三方接口失敗的情況很少了，但是還是存在失敗的情況，由於已經把調用記錄保存在了mysql中，爲此針對重試仍然失敗的情況可以單啓一個定時任務，
好了，有了定時任務，針對調用失敗的情況可以進行再次執行，那麼成功的機率就很高了，換而言之失敗的情況很少了。
如果還是有失敗的情況，那麼應該從調用方式、第三方接口是否正常等方面去排查，程序方面很難有所改進了。
其實針對重試這塊還可以直接使用定時，這種情況對於實時性要求不高的情況完全可以，也就是下面的樣子，
這就是直接定時掃描調用記錄表，定時執行。不過，仍然會出現一直失敗的情況，那就陷入死循環了，可以針對掃描範圍作一個限制，比如最近7天的記錄，超過這個時間即使失敗也不會再執行定時重調了。
除了在程序中作重試外還有其他方案嗎？
最優版本嗎
日常的開發中肯定都用過MQ，用來生產及消費消息，那麼這裏的重試便可以使用MQ，把第一次調用第三方接口失敗作爲消息投遞到MQ，再重啓另外的服務去消費MQ，在消費者中進行重試。
這種方案適合調用第三方接口較多，而且對主程序性能要求較高的情況，把重試從主程序中分離開，可以避免重試成爲影響程序性能的瓶頸。
這個方案的優點是將重試和主程序分割開來，起到了解耦的作用。可能有不少會問消費MQ如果第一次執行失敗怎麼辦，MQ已經考慮到這個問題了，MQ可以重發，感興趣的小夥伴可以瞭解下哦。
總結，通過上邊的幾種方案，可以看到調用第三方接口看似簡單，其實內含玄機。到底採用哪種方案要根據實際情況而定，不要因爲想使用什麼技術而去採取相應的方案，只有適合的纔是最好的。可以從下面幾個方面考慮，
1、系統性能；
2、實時性；
3、系統調用量；
好了，讀到這裏的小夥伴，不知道對於調用第三方接口，有沒有其他的想法，歡迎交流哦。
