第三方介面掛掉，我們的服務會受影響麼？
一、緣起與大坑
很多時候，業務需要跨公網呼叫乙個第三方服務提供的介面，為了避免每個呼叫方都依賴於第三方服務，往往會抽象乙個服務：
解除呼叫方與第三方介面的耦合
當第三方的介面變動時，只有服務需要修改，而不是所有呼叫方均修改
此時介面呼叫流程是什麼樣的呢？
如上圖1-4所述：
（1）業務呼叫方呼叫內部service
（2）內部service跨公網呼叫第三方介面
（3）第三方介面返回結果給內部service
（4）內部service返回結果給業務呼叫方
這個過程存在什麼潛在的大坑呢？
內部服務可能對上游業務提供了很多服務介面，當有乙個介面跨公網第三方呼叫超時時，可能導致所有介面都不可用，即使大部分介面不依賴於跨公網第三方呼叫。
為什麼會出現這種情況呢？
內部服務對業務方提供的n個介面，會共用服務容器內的工作執行緒（假設有100個工作執行緒）。
假設這n個介面的某個介面跨公網依賴於第三方的介面，發生了網路抖動，或者介面超時（不妨設超時時間為5秒）。
潛台詞是，這個工作執行緒會被占用5秒鐘，然後超時返回業務呼叫方。
假設這個請求的吞吐量為20qps，言下之意，很短的時間內，所有的100個工作執行緒都會被卡在這個第三方超時等待上，而其他n-1個原本沒有問題的介面，也得不到工作執行緒處理。
潛在優化方案？
增大工作執行緒數（不根本解決問題）
降低超時時間（不根本解決問題）
垂直拆分，n個介面拆分成若干個服務，使得在出問題時，被牽連的介面盡可能少（依舊不根本解決問題，難道乙個服務只提供乙個介面嗎？）
跨公網呼叫的穩定性優化，是本文要討論的問題。
二、非同步**法
解決方案：增加乙個**，向服務遮蔽究竟是「本地實時」還是「非同步遠端」去獲取返回結果
本地實時流程如上圖1-5：
（1）業務呼叫方呼叫內部service
（2）內部service呼叫非同步**service
（3）非同步**service通過openid在本地拿取資料
（4）非同步**service將資料返回內部service
（5）內部service返回結果給業務呼叫方
非同步遠端流程如上圖6-8粗箭頭的部分：
（8）重新整理本地資料
優點：公網抖動，第三方介面超時，不影響內部介面呼叫
不足：本地返回的不是最新資料（很多業務可以接受資料延時）
有時候，內部service和非同步**service可以合成乙個service
三、第三方介面備份與切換法
業務場景：呼叫第三方簡訊閘道器，或者電子合同等
解決方案：同時使用（或者備份）多個第三方服務
流程如上圖1-4：
（1）業務呼叫方呼叫內部service
（2）內部service呼叫第乙個三方介面
（3）超時後，呼叫第二個備份服務，未來都直接呼叫備份服務，直到超時的服務恢復
（4）內部service返回結果給業務呼叫方
優點：公網抖動，第三方介面超時，不影響內部介面呼叫（初期少數幾個請求會超時）
四、非同步呼叫法
業務場景：本地結果，同步第三方服務，例如使用者在58到家平台下單，58到家平台需要通知平台商家為使用者提供服務
解決方案：本地呼叫成功就返回成功，非同步呼叫第三方介面同步資料（和非同步**有微小差別）
本地流程如上圖1-3：
（1）業務呼叫方呼叫內部service
（2）內部service寫本地資料
（3）內部service返回結果給業務呼叫方成功
非同步流程如上圖4-5粗箭頭的部分：
（4）非同步service定期將本地資料取出（或者通知也行，實時性好）
（5）非同步呼叫第三方介面同步資料
優點：公網抖動，第三方介面超時，不影響內部介面呼叫
不足：不是所有業務場景都可以非同步同步資料
五、總結
跨公網呼叫第三方，可能存在的問題：
公網抖動，第三方服務不穩定，影響自身服務
乙個介面超時，佔住工作執行緒，影響其他介面
降低影響的優化方案：
增大工作執行緒數
降低超時時間
服務垂直拆分
業務需求決定技術方案，結合業務的解決方案：
業務能接受舊資料：讀取本地資料，非同步**定期更新資料
有多個第三方服務提供商：多個第三方互備
向第三方同步資料：本地寫成功就算成功，非同步向第三方同步資料
希望第三方的服務掛掉，不再影響大家的服務。
spring 針對 跨域呼叫的解決方案
spring 針對 跨域呼叫的解決方案 github位址 crossorigin restcontroller public class restdemocontroller ajax 注釋在方法和介面 類 列舉 註解上 target 執行時有效 即執行時保留 retention retention...
乙個跨平台資料遷移的方案優化
如果有一套環境，業務優先順序很高，伺服器的服役時間比我工作時間都長，現在需要遷移到x86平台，而且經過評估，如果能夠公升級資料庫的軟體版本，可以使用到更多的特性和功能。這套環境的資料量大概是800g,停機維護時間在2個小時的樣子，對於很多公司來說，盡可能縮短維護視窗時間，提前起服就意味著有更多的收入...
提高使用者體驗的優化方案 站內優化與站外優化
使用者體驗說得再多其實萬變不離其中，就是使用者通過 得到什麼，可以給使用者帶來什麼，使用者在得到需要的資訊過程中方便嗎？這就是使用者體驗，而往往 內部的優化則是最能影響使用者體驗的，就像自己在別人面前說這別墅怎麼怎麼好，不過都是聽說而已，要想真正信服自然要進屋裡面瞧瞧才知道真假吧。所以，今天筆者談談...