請求處理過程描述

我們提供的服務有：成都做網站、網站建設、微信公眾號開發、網站優化、網站認證、高密ssl等。為上1000+企事業單位解決了網站和推廣的問題。提供周到的售前咨詢和貼心的售后服務，是有科學管理、有技術的高密網站制作公司

服務端 使用 框架 加載 業務so,并未業務so創建協程處理，處理完成后給出 響應。so入口函數接收(const Type&in, Type &out,Type &extend)，是否給出響應的前提是 out里面要有 業務so的處理結果，即 out 不能是空的。這樣處理的 原因是 有些客戶端 只關心 消息是否被服務端收到，不關心處理結果，這時 服務端在收到 請求后 直接發送響應告訴 客戶端 收到消息了， 而服務端業務so處理 完消息后 置out為空，就不會再次向同一筆請求 發送響應.

框架調用業務so偽碼:

try

{

  loadso；

 proc_func=get_symbol：入口函數

 proc_func(in,out,extend);

}

catch(...)

{

  printf "unkow exception"

}

問題點:

業務現網請求消息20%超時，服務端框架日志里有 “unkow exception”,但因為框架要處理很多業務，框架日志是公用的，不能確認"unkow exception”是不是超時請求引起的。

調整框架日志和業務so級別 為debug，框架調用業務so會輸出兩條接口日志（req，ans）;

分析

a.懷疑是壞的請求，框架解析請求失敗。根據請求里關鍵字，查看接口日志，發現只有req,沒有ans，可以確定 框架接收到了請求，說明網絡沒問題(在進行這步是可以進行抓包，和有80%成功率)，并且請求沒問題。

b.業務so 有該請求的運行日志，發現運行到某 特定行后 就不往下處理，沒產生core文件；可以確認問題不在框架，結合框架產生的異常異常日志，說明 業務so 產生了異常。

c.從業務so輸出的最后一條debug日志點 往下分析，異常一定是后續產生的；逐行代碼分析，重點關注可能拋出異常的函數(老司機一眼看出來，牛)，最終鎖定在string str.substr(pos),該函數原型為

string substr(size_t pos=0,size_t len=npos)const;

If this is greater than the string length, it throws out_of_range.

總結

a.發現現網問題，先向直接領導匯報，說自己正在處理，領導可以幫助協調資源，評估影響。

b.打開日志級別到debug,所有日志都要打開。（剛開始沒有打印接口日志，導致框架沒輸出req,不能確定是不是框架沒收到消息.）

c.確定請求處理的最后幾行代碼。逐行分析.(有經驗老司機，一眼就看出來問題代碼行)

d.建議框架既然捕獲了異常，就輸出標準異常的詳情.e.what()，catch(exception e){} catch(...){}

e.業務so 使用guard 類 局部對象 在析構函數中判斷 out 是否為空，以判斷是不是異常退出，保證業務so 因業務異常退出時 能輸出日志，有據可查. 同時guard 內也可以進行 資源釋放回收，防止資源泄露.