技術問題總結(11.24)

這周寫了好幾篇關於OSB封裝的服務，在客戶端伺服器消費的時候出現報文被截斷的異常錯誤的問題分析文章，由於該問題出現概率不高，由於客戶端有重試機制，也暫時不影響到具體的OSB服務執行和使用。雖然到現在為止，造成該問題的原因究竟是客戶端伺服器配置，負載均衡，網路，報文字身，OSB套件本身的Bug缺陷等哪方面還沒有最終確認，但是整個問題排查和分析過程還是有意義的。

在問題排查和分析過程中，對於各類超時時間的含義，OSB的一些關鍵配置，報文解析，Http Post報文傳送長短連線，Tomcat的一些配置都進行了瞭解，同時通過該問題的分析，也發現了在技術問題分析過程中的一些問題，供後面在分析問題中借鑑和參考。

1. 確定問題邊界始終是最重要的

客戶端傳送報文到伺服器端接收報文，當前現象是客戶端Log日誌報文是完整的，而OSB上Log的日誌報文不完整，那麼究竟是客戶端，服務端，還是網路傳輸過程中出現的問題如何確定邊界就相當重要。實際上在幾天的問題分析和排查中對於問題邊界一直沒有最終確認，導致問題也一直沒有很肯定的得到定位究竟在哪裡，也導致最終問題沒有得到明確的解決和排查。

比如這次出現的問題，實際上應該進一步確定邊界。那麼如何確定，就應該在客戶端進行Http或TCP Trace，同時在伺服器端也進行Http TCP Trace，通過兩邊的Trace資訊才能夠最終確定問題的邊界在哪裡。但是在生產環境我們很難這樣去做，一個是併發量大，而且不止這一個介面服務在呼叫，一個是協調的需要配合的資源也太多，很難去聯合排查和跟蹤。

2. 問題復現很重要

在該問題的解決過程中，由於該異常是偶然出現，不定時而且是沒有規律出現，這個也給我們排查問題造成了很大的麻煩。雖然在問題排查過程中，我將出現問題的異常日誌，和前後正常的例項都進行了匯出分析，對出現問題的伺服器Server節點，呼叫方，呼叫時間段都進行了分析，但是沒有明顯的發現出現問題的規律究竟在哪裡。

同時該問題具有很高的隨機性，往往是第一次呼叫不成功，但是同樣的報文在第二次或第三次就呼叫成功，同時每次對於報文的截斷長度都不相同。這也導致我們很難分析具體什麼場景下呼叫不成功。

即由於問題不能在特定的輸入條件下重現，導致我們很難對問題進行進一步的分析和定位，也導致我們很難去進行特定的跟蹤和邊界確定。同時也很難在測試環境對該問題進行進一步的分析，和各種引數條件修改後的測試和驗證。這些都導致問題很難快速的進行定位。

3. Oracle Support知識庫和網上搜索很難搜尋到完全一致的異常場景

在該問題的排查過程中，我們基本都Oracle Support網站進行了所有相關知識點的排查，同時選擇各類關鍵字進行搜尋引擎的搜尋，其中包括了: Weblogic Tomcat Post Timeout KeepAlive 長連線 超時 382030 Failed to parse XML text等，但是並沒有搜尋到完全一致的場景。

對於一個最相似的關於Failed to parse XML document的場景，我們進行了相關的調整，即將KeepAlive設定為False，同時對Post Timeout設定為120秒，但是仍然出現在120秒超時時間到達後任何沒有Post到完整的請求而導致超時的問題。

由於無法搜尋到完全類似的場景，也導致我們很難根據網上給出的方法進行進一步測試和驗證。這也導致了問題遲遲不能得到有效的解決。而該問題對於Oracle顧問也只能給出進行Tcp Trace的無用建議。

4. 關鍵基礎技術知識缺乏，導致問題分析和提出假設不合理，走彎路

在原來問題的分析和解決中，由於搜尋引擎往往會給出完全類似的場景，我們只需要根據搜尋引擎給出的排查思路對問題進行排查即可。因此解決起來效率很高，對於具體底層原理性的內容我們並不需要掌握和了解，只需要能夠選擇合適的關鍵字，通過搜尋引擎搜尋到最合適的內容然後進行排查即可。

但是這次問題，特殊點就在於搜尋引擎根本無法給出完全類似的文章。這就導致我們要自己去提出各自合理的假設，並對假設進行逐一驗證。那麼如何提出合理的假設？這裡就涉及到對於TCP底層協議，各個超時值的含義和原理，Tomcat Server的引數配置，OSB代理服務的解析過程，Weblogic的關鍵引數配置和含義，負載均衡策略，乃至Docker容器和IP對映等很多內容都有技術積累才可能提出最合理的思路。

比如在排查過程中，我會想到是否需要將Tomcat 的MaxPostSize值調大的假設，但是該異常是Tomcat向Weblogic Server進行Post請求傳送資料，對於Tomcat 的MaxPostSize根本不會影響到這個Post請求，而只有Weblogic上的Post Size才會有影響。這個假設本身就不合理。而要快速的判斷這些假設不合理，你就必須提前有這些關鍵的基礎技術知識和背景積累。

包括對於Keep Alive長連線，Keep Alive的Time out超時時間設定是否會對該服務異常呼叫操作影響，實際上由於對Keep Alive長連線和各類Timeout的具體含義理解的並不深入，也使得很難判定究竟是否有影響，也只能是注意嘗試去排除可能性，這些也都導致了很難快速的定位出問題根源究竟在哪裡。

5. 涉及到外圍干係人協同的時候，導致排除困難

這個也是解決服務介面問題的一個關鍵影響。對於介面服務執行問題，往往涉及到業務系統消費方，業務系統提供方，OSB服務匯流排，網路，負載均衡裝置等多個相關因素和廠商。對於一個問題的排查往往需要協調多方的資源在約定的時間相互配合才能夠完成，這些都直接導致排查難度很大，很難依靠個人一方力量就完成。

在原來類似大專案實施過程中，也經常會遇到這些介面問題的分析和排查，往往也都是問題造成嚴重影響後，各方才會真正重視該問題，並各自協調資源形成聯合的問題排查團隊進行問題分析和排查，最終才能夠解決問題。

雖然截止現在問題沒有得到最終解決，但是整個分析過程仍然有意義，特進行本文總結。