又到了很無聊的時候了，於是隨便看看源碼假裝自己很努力的樣子，哈哈哈；

　　記得上一篇博客隨便說了一下RequestBody的用法以及注意的問題，這個註解作為非常常用的註解，也是時候了解一波其中的原理了。

　   溫馨提示：閱讀本篇博客，默認你之前大概看過springmvc源碼，懂得其中的基本流程

1.HttpMessageConverter接口

　　這個接口就是@RequestBody和@ResponseBody這兩個註解的精髓，我們就先看看這個頂層接口定義了哪些方法：

public interface HttpMessageConverter<T> {

    //判斷當前轉換器是否可以解析前端傳過來的數據
    boolean canRead(Class<?> clazz, @Nullable MediaType mediaType);

    //判斷當前轉換器是否可以將後端數據解析為前端需要的格式
    boolean canWrite(Class<?> clazz, @Nullable MediaType mediaType);

    //當前轉換器能夠解析所有的數據類型
    List<MediaType> getSupportedMediaTypes();

    //這個方法就是讀取前端傳過來的數據
    T read(Class<? extends T> clazz, HttpInputMessage inputMessage) throws IOException, HttpMessageNotReadableException;

    //將後台數據轉換然後返回給前端
    void write(T t, @Nullable MediaType contentType, HttpOutputMessage outputMessage) throws IOException, HttpMessageNotWritableException;

}

　　我們從這個頂層接口中這幾個方法就大概能看到一些東西，可以肯定的就是在@RequestBody和@ResponseBody這兩個註解原理的內部轉換器應該都是實現了這個HttpMessageConverter，因為這個接口裡又是read，又是write；然後就是在上面我只是簡單說了前端傳過來的數據，返回給前端需要的格式這種模糊的說法，為什麼不直接說返回json格式的數據呢？

　　哈哈，可能有的小夥伴會說，瑪德，你絕逼是怕說錯，才說這些模糊的說法；咳，當然有部分是這個意思，但是最大的原因就是上面方法參數中有個類MediaType，你打開看看就知道了，這裏定義了很多的可以解析的數據類型，比如”application/json”，”application/xml”，”image/gif”,”text/html”….等等，還有好多聽都沒聽過的；

　　其實了解http請求的小夥伴應該已經看出來了，這裏這些數據類型就是下圖所示的這些；當然，我們暫時只關注json的，至於其他類型的怎麼解析有興趣的小夥伴可以研究研究；

 2.HandlerMethodArgumentResolver接口

　　我們看看這個接口，看名字就知道應該是方法參數解析器，很明顯就是用於解析方法Controller中方法的參數的，還是簡單看看這個接口中的方法：

public interface HandlerMethodArgumentResolver {

    //該解析器是否支持解析Controller中方法中的參數，因為這裏參數類型可以是簡單類型，也可以是集合等類型
    boolean supportsParameter(MethodParameter parameter);

    //開始解析Http請求中的數據，解析出來的數據要和方法參數對應
    Object resolveArgument(MethodParameter parameter, @Nullable ModelAndViewContainer mavContainer, NativeWebRequest webRequest, @Nullable WebDataBinderFactory binderFactory) throws Exception;

}

 　　這個接口定義的方法作用其實就是將http請求中的參數對應到Controller中的參數

3.HandlerMethodReturnValueHandler接口　

public interface HandlerMethodReturnValueHandler {

    //這個方法判斷該處理器是否支持返回值類型，這裏的返回值就是controller方法執行后的返回值
    boolean supportsReturnType(MethodParameter returnType);

    //將controller方法的返回值進行解析成前端需要的格式，後續就會丟給前端
    void handleReturnValue(@Nullable Object returnValue, MethodParameter returnType, ModelAndViewContainer mavContainer, NativeWebRequest webRequest) throws Exception;

}

 　　這個接口的作用：比如一個Controller方法中的返回值是一個集合，那麼springmvc內部在將數據返回給前端之前，就會先拿到所有的返回值解析器，然後遍歷每一個，分別執行supportsReturnType方法，看看哪個解析器可以解析集合類型，找到解析器之後，然後再執行handleReturnValue方法解析就行了，其實2中的方法參數解析器也是這樣的一個步驟

4.ServletInvocableHandlerMethod類

　　這個類是干什麼的呢？看過springmvc源碼的人應該知道一點，還是簡單說說吧，在springmvc中會將controller中的每個被RequestMapping註解修飾的方法（也可以叫做處理器）給封裝成ServletInvocableHandlerMethod類，封裝后想要執行該處理器方法只需要執行該類的invokeAndHandle方法;

　　請注意：就是在invokeAndHandle這個方法中會調用：調用方法參數解析器——>執行處理器方法——–>調用返回值解析器、

　　可以簡單看看源碼，請一定要了解springmvc的流程，因為我不會從頭到尾講一遍，我們直接從DispatcherServlet中的doDispatch方法的ha.handle（xxx）這裏說起，這裏主要是執行處理器適配器的handle方法，這裏具體的處理器適配器實現是：AbstractHandlerMethodAdapter

　　我們進入AbstractHandlerMethodAdapter這個適配器的handle方法看看(^o^)／：

//可以看到這裏就是調用了handleInternal方法，而handleInternal方法未實現
public final ModelAndView handle(HttpServletRequest request,HttpServletResponse response, Object handler)throws Exception {
        return handleInternal(request, response, (HandlerMethod) handler);
    }


//這個方法在子類RequestMappingHandlerAdapter中實現
protected abstract ModelAndView handleInternal(HttpServletRequest request, HttpServletResponse response,HandlerMethod handlerMethod) throws Exception;

　　接下來我們看看RequestMappingHandlerAdapter中實現的handleInternal方法(」゜ロ゜)」：

protected final ModelAndView handleInternal(HttpServletRequest request, HttpServletResponse response,HandlerMethod handlerMethod) throws Exception {

        //省略跟邏輯無關的代碼
                .......
               .........
        
        return invokeHandlerMethod(request, response, handlerMethod);
    }

　　進入invokeHandlerMethod方法看看(´･_･`)：

private ModelAndView invokeHandlerMethod(HttpServletRequest request, HttpServletResponse response,HandlerMethod handlerMethod) throws Exception {
        
        ServletWebRequest webRequest = new ServletWebRequest(request, response);

        WebDataBinderFactory binderFactory = getDataBinderFactory(handlerMethod);
        ModelFactory modelFactory = getModelFactory(handlerMethod, binderFactory);
        ServletInvocableHandlerMethod requestMappingMethod = createRequestMappingMethod(handlerMethod, binderFactory);

        ModelAndViewContainer mavContainer = new ModelAndViewContainer();
        //省略一些代碼

        //就是再這裏去執行Controller中的處理器方法
        requestMappingMethod.invokeAndHandle(webRequest, mavContainer);

        //此處省略好多代碼
    }

　　繼續進入到invokeAndHandle方法內部看看╮(╯_╰)╭：

public final void invokeAndHandle(NativeWebRequest request, ModelAndViewContainer mavContainer,Object... providedArgs) throws Exception {
         //請注意，這裏面就是執行handler方法的位置
        Object returnValue = invokeForRequest(request, mavContainer, providedArgs);

        //省略一些代碼              

        try {
            //這裏就是執行我們前面說的返回值解析器
            returnValueHandlers.handleReturnValue(returnValue, getReturnType(), mavContainer, request);
        } 
       //省略一些代碼
    }

　　看看invokeForRequest方法你就能看到有趣的東西ヽ(”`▽´)ﾉ

public Object invokeForRequest(NativeWebRequest request, @Nullable ModelAndViewContainer mavContainer, Object... providedArgs) throws Exception {
                //這裏就是從request中拿到參數，利用方法參數解析器進行解析，映射到方法參數中，這個方法就在下面
                Object[] args = getMethodArgumentValues(request, mavContainer, providedArgs);
        
               //省略一些代碼
        
                //這裏就是根據上一步將請求參數映射到處理器方法參數中，然後執行對應的處理器方法
               Object returnValue = doInvoke(args);
        
               //省略一些代碼
        
                return returnValue;
    }


private Object[] getMethodArgumentValues(NativeWebRequest request,@Nullable ModelAndViewContainer mavContainer,Object... providedArgs) throws Exception {
          //這裏獲取匹配到的handler方法的參數數組，每個參數在之前都被封裝成了一個MethodParameter對象，然後再遍歷這個數組，將其中每個MethodParameter和http請求提供的參數進行比較，
至於怎麼比較，就會用到之前說的參數解析器的那個support方法     
        MethodParameter[] parameters = getMethodParameters();
        Object[] args = new Object[parameters.length];
        for (int i = 0; i < parameters.length; i++) {
            MethodParameter parameter = parameters[i];
            parameter.initParameterNameDiscovery(this.parameterNameDiscoverer);
            args[i] = resolveProvidedArgument(parameter, providedArgs);
            if (args[i] != null) {
                continue;
            }
            if (this.argumentResolvers.supportsParameter(parameter)) {
                try {
                    args[i] = this.argumentResolvers.resolveArgument(
                            parameter, mavContainer, request, this.dataBinderFactory);
                    continue;
                }
           //省略一些代碼
            
        return args;
    }

　    其實到這裏，有木有感覺清晰一點了，那麼肯定有小夥伴要問了，說了半天，你還是沒有說json是怎麼解析的啊？

　　不要急，我們先把大概的流程過一遍之後，後面的都是小問題，那麼，我們的轉換器是在哪裡轉換的呢？

　　欲知後事如何，請往後面看

5.無題

　　在4中我們重點看兩個地方，第一個地方：this.argumentResolvers.supportsParameter(parameter)；第二個地方：this.argumentResolvers.resolveArgument(parameter, mavContainer, request, this.dataBinderFactory);

　　5.1.RequestResponseBodyMethodProcessor

　　　　第一個地方，我們點進去supportsParameter方法，

　　然後我們進入getArgumentResolver方法內部（´□｀川）：

@Nullable
    private HandlerMethodArgumentResolver getArgumentResolver(MethodParameter parameter) {
        HandlerMethodArgumentResolver result = this.argumentResolverCache.get(parameter);
        if (result == null) {
             //for循環遍歷所有的方法參數解析器，
            for (HandlerMethodArgumentResolver methodArgumentResolver : this.argumentResolvers) {
                
                //省略一些代碼
                
               //判斷哪一個解析器支持解析request中的參數，這裏很關鍵，因為眾多解析器中其中有一個參數解析器是RequestResponseBodyMethodProcessor，
　　　　　　　　　　//下面我們看看這個解析器的supportParameter方法
                if (methodArgumentResolver.supportsParameter(parameter)) {
                    result = methodArgumentResolver;
                    this.argumentResolverCache.put(parameter, result);
                    break;
                }
            }
        }
        return result;
    }

　　RequestResponseBodyMethodProcessor的supportsParameter方法，這裏想必能看得懂吧，就是看Controller中的處理器方法中的參數前面有沒有RequestBody註解，有註解，那麼這個RequestResponseBodyMethodProcessor解析器就會生效

　　對了，補充一點，這個解析器RequestResponseBodyMethodProcessor可是同時實現了方法參數解析器接口、返回參數解析器接口的哦，這說明了處理返回值解析器用的也是這個解析器

　　5.2.執行argumentResolvers.resolveArgument()方法

//這個方法就到了最關鍵的地方了，注意了注意了
public Object resolveArgument(MethodParameter parameter, ModelAndViewContainer mavContainer,NativeWebRequest webRequest, WebDataBinderFactory binderFactory) 

　　throws Exception {

         //獲取一個轉換器，用於讀取前端傳過來的json數據
        Object arg = readWithMessageConverters(webRequest, parameter, parameter.getParameterType());
                

        //獲取handler方法形參中的所有註解，例如@Valid。@PathVariable等
        Annotation[] annotations = parameter.getParameterAnnotations();
        

　　　　  for (Annotation annot : annotations) {      
　　　　　　//判斷如果是以valid開頭的註解，其實就是@Valid註解或者是@Validated註解，那麼就會去校驗是否符合規則嘛，這個不用多說
　　　　　　　　if(annot.annotationType().getSimpleName().startsWith("Valid")) {
                String name = Conventions.getVariableNameForParameter(parameter);
                WebDataBinder binder = binderFactory.createBinder(webRequest, arg, name);
                Object hints = AnnotationUtils.getValue(annot);
                binder.validate(hints instanceof Object[] ? (Object[]) hints : new Object[] {hints});
                BindingResult bindingResult = binder.getBindingResult();
                if (bindingResult.hasErrors()) {
                    throw new MethodArgumentNotValidException(parameter, bindingResult);
                }
            }
        }
        return arg;
    }

　　最後我們只需要輕輕點開readWithMessageConverters方法，就能看到更有意思的東西~^o^~

6.xxxConverter

　　我們進入readWithMessageConverters這個方法，

@SuppressWarnings("unchecked")
    protected <T> Object readWithMessageConverters(HttpInputMessage inputMessage, MethodParameter methodParam, Class<T> paramType) throws IOException,
            HttpMediaTypeNotSupportedException {
            //這裏回答了本篇最開始說的MediaType 到底是什麼東西，從哪裡獲取的，很明顯是從請求頭中的ContentType獲取的
             MediaType contentType = inputMessage.getHeaders().getContentType();
            if (contentType == null) {
                 contentType = MediaType.APPLICATION_OCTET_STREAM;
            }
            //獲取所有的HttpMessageConverter，遍歷，看看哪一個轉換器支持前端傳過來的數據類型
            for (HttpMessageConverter<?> messageConverter : this.messageConverters) {
                 if (messageConverter.canRead(paramType, contentType)) {
                     //調用對應的轉換器的read方法去把前端傳過來的json字符串轉為java對象 return ((HttpMessageConverter<T>) messageConverter).read(paramType, inputMessage);
                    }
                }
            
                //省略一些代碼
            }

 　　到了這裏肯定有人會說，那到底用的是哪一個轉換器呢？難道是要我們自己導入？還是默認已經導入轉換器了呢？

　　當然是默認就為你初始化了一些轉換器了啊，如果你想自定義也行，而且仔細看看下圖中跟json有關的只有MappingJackson2HttpMessageConverter這個轉換器了，可想而知這個轉換器(實際上是這個轉換器的父類方法中才有具體的操作)中使用的就是開源的Jackson來將json字符串轉為java對象的，有興趣了解的可以使用一下Jackson自己嘗試一下；

　　偷偷告訴你(҂ ˘ _ ˘ )，springboot默認已經導入了Jackson包，如果你後期想用其他的轉換器，只需要導入相關依賴就ok了；

7.結束

　　這篇博客到這裏就差不多了，寫了好久，邊寫邊查資料，可以說每次看源碼都能學到新的東西，當然，我也沒有死磕精神，不是不想，主要是沒有那個水平，哈哈；

　　其實還要寫還能寫，不是還有個@ResponseBody原理還沒說嗎？其實跟@RequestBody大同小異的，有興趣的可以在第4點最後的代碼中返回值參數處理器方法，這裏就是入口

　　話說還有個問題沒有解決，本來我想找一下最後的那幾個轉換器初始化時機的，然後實在是找不出來啊，查了一下資料，都說是在處理器適配器的構造器中初始化這些轉換器的，哎，jdk1.8，我在適配器中找了好久，愣是沒找到，打斷點也調試不出來，把自己坑了好久；

　　有沒有大哥知道初始化時機的，評論一下，謝謝了(ㄒoㄒ)

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※台北網頁設計公司這麼多，該如何挑選?? 網頁設計報價省錢懶人包"嚨底家"

※網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

※南投搬家費用,距離,噸數怎麼算?達人教你簡易估價知識!

編者注：Java nio 空輪詢bug也就是Java nio在Linux系統下的epoll空輪詢問題。

epoll機制是Linux下一種高效的IO復用方式，相較於select和poll機制來說。其高效的原因是將基於事件的fd放到內核中來完成，在內核中基於紅黑樹+鏈表數據結構來實現，鏈表存放有事件發生的fd集合，然後在調用epoll_wait時返回給應用程序，由應用程序來處理這些fd事件。

使用IO復用，Linux下一般默認就是epoll，Java NIO在Linux下默認也是epoll機制，但是JDK中epoll的實現卻是有漏洞的，其中最有名的java nio epoll bug就是即使是關注的select輪詢事件返回數量為0，NIO照樣不斷的從select本應該阻塞的Selector.select()/Selector.select(timeout)中wake up出來，導致CPU 100%問題。如下圖所示：

那麼產生這個問題的原因是什麼的？其實在 上已經說明的很清楚了，比如下面是bug復現的一個場景：

A DESCRIPTION OF THE PROBLEM :
The NIO selector wakes up infinitely in this situation..
0. server waits for connection
1. client connects and write message
2. server accepts and register OP_READ
3. server reads message and remove OP_READ from interest op set
4. client close the connection
5. server write message (without any reading.. surely OP_READ is not set)
6. server's select wakes up infinitely with return value 0

上面的場景描述的問題就是連接出現了RST，因為poll和epoll對於突然中斷的連接socket會對返回的eventSet事件集合置為POLLHUP或者POLLERR，eventSet事件集合發生了變化，這就導致Selector會被喚醒，進而導致CPU 100%問題。根本原因就是JDK沒有處理好這種情況，比如SelectionKey中就沒定義有異常事件的類型。

class SelectionKey {
    public static final int OP_READ = 1 << 0;
    public static final int OP_WRITE = 1 << 2;
    public static final int OP_CONNECT = 1 << 3;
    public static final int OP_ACCEPT = 1 << 4;
}

既然nio epoll bug存在，那麼能不能規避呢？答案是有的，比如netty就很巧妙的規避了這個問題，它的處理機制就是如果發生了這種情況，並且發生次數超過了SELECTOR_AUTO_REBUILD_THRESHOLD（默認512），則調用rebuildSelector()進行Selecttor重建，這樣就不用管之前發生了異常情況的那個連接了。因為重建也是根據SelectionKey事件對應的連接來重新註冊的。

該問題最早在 Java 6 發現，隨後很多版本聲稱解決了該問題，但實際上只是降低了該 bug 的出現頻率，目前從網上搜索到的資料显示，Java 8 還是存在該問題（）。

最後一起來分析下，nio epoll bug不是linux epoll的問題，而是JDK自己實現epoll時沒有考慮這種情況，或者說因為其他系統不存在這個問題，Java為了封裝（比如SelectionKey 中的4個事件類型）的統一而沒去處理？

這裏思考下，如果想要從java nio層面上來解決這個問題，該如何做呢？

一種是nio事件類型SelectionKey新加一種”錯誤”類型，比如針對linux epoll中的epollhup和epollerr，如果出現這種事件，建議程序直接close socket，但這種方式相對來說對於目前的nio SelectionKey改動有點大，因為SelectionKey的定義目前是針對所有jdk平台的；還有一種是針對jdk nio 對epoll的封裝中，對於epoll的epollhup和epollerr事件，epoll封裝內部直接處理，比如close socket，但是這種方案也有一點尷尬的是，可能上層應用代碼還保留有出現問題的socket引用，這時最好是應用程序能夠感知這種情況來處理比較好。

Java nio空轉問題由來已久，一般程序中是通過新建Selector的方式來屏蔽掉了JDK5/6的這個問題，因此，對於開發者來講，還是盡量將JDK的版本更新到最新，或者使用NIO框架如Netty，Grizzly等進行研發，以免出更多的問題。

推薦閱讀

歡迎小夥伴關注【TopCoder】閱讀更多精彩好文。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※想知道網站建置、網站改版該如何進行嗎?將由專業工程師為您規劃客製化網頁設計及後台網頁設計

※不管是台北網頁設計公司、台中網頁設計公司，全省皆有專員為您服務

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※帶您來看台北網站建置，台北網頁設計，各種案例分享

• 事故經過
• 排查
• 總結

事故經過

11-01 12:00 中午午飯期間，手機突然收到業務網關非200異常報警，平時也會有一些少量499或者網絡抖動問題觸發報警，但是很快就會恢復（目前配置的報警閾值是5%，閾值跟當時的採樣窗口qps有直接關係）。

報警當時非200佔比已經過10%並且在持續升高，根據歷史規律應該很快就會恢復，我們稍微觀察了幾分鐘（一邊吃着很香的餃子一邊看着手機），但是過了幾分鐘故障沒有恢復而且佔比升高了突破50%，故障逐漸升級（故障如果不在固定時間內解決會逐漸升級，故障群每次升級都會逐層拉更高level的boss進來）手機持續報警震動已經發燙了，故障佔比已經快100%，影響面突然變大。

此時提現系統也開始報警，大量打款訂單擠壓（打款訂單擠壓突破一定閾值才會報警，所以不是實時），工位同事也反應支付系統也有少量連接錯誤，突然感覺情況複雜了，迅速停止吃飯，趕緊回公司排查。

回到工位時間差不多12:40左右，快速查看監控大盤，基本都是499、504錯誤，此類錯誤都是因為網絡超時導致。集群中的兩台機器均有錯，而且qps也比較平均，可以排除某台機器問題。

RT99線基本5s，而且連續橫盤，這5s是觸發了上游sidecar proxy調用超時主動斷開了，真正的RT時間可能更長。

故障還未見恢復，業務運維協助一起排查，此時故障群已經升級到技術中心老大，壓力瞬間大的一筆。

查看網關係統日誌，大量調用我們內部的兩個系統報出“下游服務器超時”錯誤，根據日誌信息可以判斷網絡問題導致超時，但是我們調用的是內網服務，如果是網絡問題為什麼只有我們的系統受到影響。

在12:51到13:02之間錯誤佔比情況有所好轉，但是之後錯誤佔比繼續升高。

此時業務運維同步其他部門有大量302報警，時間線有點吻合，此時時間差不多13:30。但是別的部門的系統和我們的系統沒有任何關係，太多的疑問大家開始集中坐到一起排查問題。

他們嘗試做了版本回滾未見好轉，然後嘗試將訪問返回302域名切到內網故障立馬恢復，此時正好14:00。根據他們的反饋在做實驗放量，導致在12:00的時候有一波流量高峰，但是這一波流量高峰對我的系統鏈路衝擊在哪裡，一臉懵逼，疑點重重。

本次故障持續時間太長，報警整整報了兩個小時，故障群每三種報警一次並且電話通知，報警電話幾十個，微信報警群“災難”級別的信息更多，嚴重程度可想而知。

排查

雖然故障是因為別的部門放量導致，但是還是有太多疑問沒有答案，下次還會再出現。作為技術人員，線上環境是非常神聖的地方是禁區，一定要找到每次故障的 root cause，否則沒辦法給自己一個交代，我們開始逐層剝洋蔥。

我們來梳理下疑問點：

1.302是什麼原因，為什麼做了域名切換就整體恢復了？
2.兩邊的系統在鏈路上有什麼交集？如果應用鏈路沒有交集，那麼在網絡鏈路上是否有交集？
3.我們業務網關中的“下游服務器超時”為什麼其他系統沒有影響？對日誌的解讀或者描述是否有歧義？
4.504是觸發sidecar proxy 超時斷開連接，網關服務設置的超時為什麼沒起作用？

1.302是什麼原因，為什麼做了域名切換就整體恢復了？

經過我們的運維和阿里雲專家的排查，出現大量302是因為訪問的域名觸發DDos/CC高防策略。由於訪問的域名配置了DDos/CC高防策略，大量請求觸發了其中一條規則導致拒絕請求（具體觸發了什麼規則就不方便透露），所以會返回302，通過添加白名單可以解決被誤殺的情況。
（從合理性角度講內部調用不應該走到外網，有一部分是歷史遺留問題。）

2.兩邊的系統在鏈路上有什麼交集？如果應用鏈路沒有交集，那麼在網絡鏈路上是否有交集？

所有人焦點都集中在高防上，認為網關故障就是因為也走到了被高防的地址上，但是我們的網關配置里根本沒有這個高防地址，而且我們內部系統是不會有外網地址的。

排查提現系統問題，提現系統的配置里確實有用到被高防的外網地址，認為提現打款擠壓也是因為走到了高防地址，但是這個高防地址只是一個旁路作用，不會影響打款流程。但是配置里確實有配置到，所以有理由判斷肯定使用到了才會影響，這在當時確實是個很重要的線索，是個突破口。

根據這個線索認為網關係統雖然本身沒有調用到高防地址，但是調用的下游也有可能會走到才會導致整個鏈路出現雪崩的問題。

通過大量排查下游服務，翻代碼、看日誌，基本上在應用層調用鏈路沒有找到任何線索。開始在網絡層面尋找線索，由於是內網調用所以路線是比較簡單的，client->slb->gateway->slb->sidecar proxy->ecs，幾個下游被調用系統請求一切正常，slb、sidecar proxy監控也一切正常，應用層、網絡層都沒有找到答案。

sidecar proxy 因為沒有打開日誌所以看不到請求（其實有一部分調用沒有直連還是通過slb、vtm中轉），從監控上看下游的 sidecar proxy 也一切正常，如果網路問題肯定是連鎖反應。

百般無解之後，開始仔細檢查當天出現故障的所有系統日誌（由於現在流行Microservice所以服務比較多，錯誤日誌量也比較大），在排查到支付系統的渠道服務時發現有一些線索，在事故發生期間有一些少量的 connection reset by peer，這個錯誤基本上多數出現在連接池化技術中使用了無效連接，或者下游服務器發生重啟導致。但是在事故當時並沒有發布。

通過對比前一周日誌沒有發生此類錯誤，那很有可能是很重要的線索，聯繫阿里雲開始幫忙排查當時ecs實例在鏈路上是否有問題，驚喜的是阿里雲反饋在事故當時出現 nat網關 限流丟包，一下子疑問全部解開了。

限流丟包才是引起我們系統大量錯誤的主要原因，所以整個故障原因是這樣的，由於做活動放量導致高防302和出網限流丟包，而我們系統受到影響都是因為需要走外網，提現打款需要用到支付寶、微信等支付渠道，而支付系統也是需要出外網用到支付寶、微信、銀聯等支付渠道。
（由於當時我們並沒有nat網關的報警導致我們都一致認為是高防攔截了流量。）

問題又來了，為什麼網關調用內部系統會出現問題，但是答案已經很明顯。簡單的檢查了下其中一個調用會走到外網，網關的接口會調用下游三個服務，其中第一個服務調用就是會出外網。

這個問題是找到了，但是為什麼下游設置的超時錯誤一個沒看見，而且“下游服務器超時”的錯誤日誌stack trace 堆棧信息是內網調用，這個還是沒搞明白。

3.我們業務網關中的“下游服務器超時”為什麼其他系統沒有影響？對日誌的解讀或者描述是否有歧義？

通過分析代碼，這個日誌的輸出並不是直接調用某個服務發生超時timeout，而是 go Context.Done() channel 的通知，我們來看下代碼：

func Send(ctx context.Context, serverName, method, path string, in, out interface{}) (err error) {
    e := make(chan error)
    go func() {
        opts := []utils.ClientOption{
            utils.WithTimeout(time.Second * 1),
        }
        if err = utils.HttpSend(method, path, in, out, ops, opts...); err != nil {
            e <- err
            return
        }
        e <- nil
    }()

    select {
    case err = <-e:
        return
    case <-ctx.Done():
        err = errors.ErrClientTimeOut
        return
    }
}

Send 的方法通過 goroutine 啟動一個調用，然後通過 select channel 感知http調用的結果，同時通過 ctx.Done() 感知本次上游http連接的 canceled。

err = errors.ErrClientTimeOut
ErrClientTimeOut         = ErrType{64012, "下游服務器超時"}

這裏的 errors.ErrClientTimeOut 就是日誌“下游服務器超時”的錯誤對象。

很奇怪，為什麼調用下游服務器沒有超時錯誤，明明設置了timeout時間為1s。

        opts := []utils.ClientOption{
                    utils.WithTimeout(time.Second * 1),
                }
        if err = utils.HttpSend(method, path, in, out, ops, opts...); err != nil {
            e <- err
            return
        }

這個 utils.HttpSend 是有設置調用超時的，為什麼一條調用超時錯誤日誌沒有，跟蹤代碼發現雖然opts對象傳給了utils.HttpSend方法，但是裏面卻沒有設置到 __http.Client__對象上。

client := &http.Client{}
    // handle option
    {
        options := defaultClientOptions
        for _, o := range opts {
            o(&options)
        }
        for _, o := range ops {
            o(req)
        }
        
        //set timeout
        client.Timeout = options.timeout

    }

    // do request
    {
        if resp, err = client.Do(req); err != nil {
            err = err502(err)
            return
        }
        defer resp.Body.Close()
    }

就是缺少一行 client.Timeout = options.timeout 導致http調用未設置超時時間。加上之後調用一旦超時會拋出 “net/http: request canceled (Client.Timeout exceeded while awaiting headers)” timeout 錯誤。

問題我們大概知道了，就是因為我們沒有設置下游服務調用超時時間，導致上游連接超時關閉了，繼而觸發context.canceled事件。

上層調用會逐個同步進行。

    couponResp, err := client.Coupon.GetMyCouponList(ctx, r)
    // 不返回錯誤 降級為沒有優惠券
    if err != nil {
        logutil.Logger.Error("get account coupon  faield",zap.Any("err", err))
    }
    coins, err := client.Coin.GetAccountCoin(ctx, cReq.UserID)
    // 不返回錯誤 降級為沒有金幣
    if err != nil {
        logutil.Logger.Error("get account coin faield",zap.Any("err", err))
    }
    subCoins, err := client.Coin.GetSubAccountCoin(ctx, cReq.UserID)
    // 不返回錯誤 降級為沒有金幣
    if err != nil {
        logutil.Logger.Error("get sub account coin faield",zap.Any("err", err))
    }

client.Coupon.GetMyCouponList 獲取優惠券
client.Coin.GetAccountCoin 獲取金幣賬戶
client.Coin.GetSubAccountCoin 獲取金幣子賬戶

這三個方法內部都會調用Send方法，這個接口邏輯就是獲取用戶名下所有的現金抵扣權益，並且在超時時間內做好業務降級。但是這裏處理有一個問題，就是沒有識別Send方法返回的錯誤類型，其實連接斷了之後程序再往下走已經沒有意義也就失去了Context.canceld的意義。
（go和其他主流編程語言在線程（Thread）概念上有一個很大的區別，go是沒有線程概念的（底層還是通過線程在調度），都是goroutine。go也是完全隱藏routine的，你無法通過類似Thread Id 或者 Thread local線程本地存儲等技術，所有的routine都是通過context.Context對象來協作，比如在java 里要想取消一個線程必須依賴Thread.Interrupt中斷，同時要捕獲和傳遞中斷信號，在go里需要通過捕獲和傳遞Context信號。）

4.504是觸發sidecar proxy 超時斷開連接，網關服務器設置的超時為什麼沒起作用？

sidecar proxy 斷開連接有三個場景：

1.499同時會關閉下游連接
2.504超時直接關閉下游連接
3.空閑超過60s關閉下游連接

事故當時499、504 sidecar proxy 主動關閉連接，網關服務Context.Done()方法感知到連接取消拋出異常，上層方法輸出日誌“下游服務器超時”。那為什麼我們網關服務器本身的超時沒起作用。

http/server.Server對象有四個超時參數我們並沒有設置，而且這一類參數通常會被忽視，作為一個服務器本身對所有進來的請求是有最長服務要求，我們一般關注比較多的是下游超時會忽視服務本身的超時設置。

type Server struct {
    // ReadTimeout is the maximum duration for reading the entire
    // request, including the body.
    //
    // Because ReadTimeout does not let Handlers make per-request
    // decisions on each request body's acceptable deadline or
    // upload rate, most users will prefer to use
    // ReadHeaderTimeout. It is valid to use them both.
    ReadTimeout time.Duration

    // ReadHeaderTimeout is the amount of time allowed to read
    // request headers. The connection's read deadline is reset
    // after reading the headers and the Handler can decide what
    // is considered too slow for the body.
    ReadHeaderTimeout time.Duration

    // WriteTimeout is the maximum duration before timing out
    // writes of the response. It is reset whenever a new
    // request's header is read. Like ReadTimeout, it does not
    // let Handlers make decisions on a per-request basis.
    WriteTimeout time.Duration

    // IdleTimeout is the maximum amount of time to wait for the
    // next request when keep-alives are enabled. If IdleTimeout
    // is zero, the value of ReadTimeout is used. If both are
    // zero, ReadHeaderTimeout is used.
    IdleTimeout time.Duration
}

這些超時時間都會通過setDeadline計算成絕對時間點設置到netFD對象（Network file descriptor.）上。
由於沒有設置超時時間所以相當於所有的連接關閉都是通過sidecar proxy觸發傳遞下來的。

我們已經知道 sidecar proxy 關閉連接的1、2兩種原因，第3種情況出現在http長連接上，但是這類連接關閉是無感知的。

默認的tcpKeepAliveListener對象的keepAlive是3分鐘。

func (ln tcpKeepAliveListener) Accept() (net.Conn, error) {
    tc, err := ln.AcceptTCP()
    if err != nil {
        return nil, err
    }
    tc.SetKeepAlive(true)
    tc.SetKeepAlivePeriod(3 * time.Minute)
    return tc, nil
}

我們服務host是使用endless框架，默認也是3分鐘，這其實是個約定90s，過小會影響上游代理。

func (el *endlessListener) Accept() (c net.Conn, err error) {
    tc, err := el.Listener.(*net.TCPListener).AcceptTCP()
    if err != nil {
        return
    }

    tc.SetKeepAlive(true)                  // see http.tcpKeepAliveListener
    tc.SetKeepAlivePeriod(3 * time.Minute) // see http.tcpKeepAliveListener

    c = endlessConn{
        Conn:   tc,
        server: el.server,
    }

    el.server.wg.Add(1)
    return
}

sidecar proxy 的超時是60s，就算我們要設置keepAlive的超時時間也要大於60s，避免sidecar proxy使用了我們關閉的連接。
（但是這在網絡不穩定的情況下會有問題，如果發生HA Failover 然後在一定小概率的心跳窗口內，服務狀態並沒有傳遞到註冊中心，導致sidecar proxy重用了之前的http長連接。這其實也是個權衡，如果每次都檢查連接狀態一定會影響性能。）

這裡有個好奇問題，http是如何感知到四層tcp的狀態，如何將Context.cancel的事件傳遞上來的，我們來順便研究下。

type conn struct {
    // server is the server on which the connection arrived.
    // Immutable; never nil.
    server *Server

    // cancelCtx cancels the connection-level context.
    cancelCtx context.CancelFunc
}

func (c *conn) serve(ctx context.Context) {
    
    // HTTP/1.x from here on.
    
    ctx, cancelCtx := context.WithCancel(ctx)
    c.cancelCtx = cancelCtx
    defer cancelCtx()

    c.r = &connReader{conn: c}
    c.bufr = newBufioReader(c.r)
    c.bufw = newBufioWriterSize(checkConnErrorWriter{c}, 4<<10)

    for {
        w, err := c.readRequest(ctx)

        if !w.conn.server.doKeepAlives() {
            // We're in shutdown mode. We might've replied
            // to the user without "Connection: close" and
            // they might think they can send another
            // request, but such is life with HTTP/1.1.
            return
        }

        if d := c.server.idleTimeout(); d != 0 {
            c.rwc.SetReadDeadline(time.Now().Add(d))
            if _, err := c.bufr.Peek(4); err != nil {
                return
            }
        }
        c.rwc.SetReadDeadline(time.Time{})
    }
}

// handleReadError is called whenever a Read from the client returns a
// non-nil error.
//
// The provided non-nil err is almost always io.EOF or a "use of
// closed network connection". In any case, the error is not
// particularly interesting, except perhaps for debugging during
// development. Any error means the connection is dead and we should
// down its context.
//
// It may be called from multiple goroutines.
func (cr *connReader) handleReadError(_ error) {
    cr.conn.cancelCtx()
    cr.closeNotify()
}

// checkConnErrorWriter writes to c.rwc and records any write errors to c.werr.
// It only contains one field (and a pointer field at that), so it
// fits in an interface value without an extra allocation.
type checkConnErrorWriter struct {
    c *conn
}

func (w checkConnErrorWriter) Write(p []byte) (n int, err error) {
    n, err = w.c.rwc.Write(p)
    if err != nil && w.c.werr == nil {
        w.c.werr = err
        w.c.cancelCtx()
    }
    return
}

其實tcp的狀態不是通過主動事件觸發告訴上層http的，而是每當http主動去發現。

read時使用connReader來感知tcp狀態，writer時使用checkConnErrorWriter對象來感知tcp狀態，然後通過server.conn對象中的cancelCtx來遞歸傳遞。

type conn struct {
    // server is the server on which the connection arrived.
    // Immutable; never nil.
    server *Server

    // cancelCtx cancels the connection-level context.
    cancelCtx context.CancelFunc
}

總結

此次故障排查了整整两天半，很多點是需要去反思和優化的。

1.所有的網絡調用沒有拋出最原始error信息。（經過加工之後的日誌會嚴重誤導人。）
2.超時時間的設置未能起到作用，未經過完整的壓測和故障演練，所以超時時間很容易無效。
3.內外網域名沒有隔離，需要區分內外網調用，做好環境隔離。
4.http服務器本身的超時沒有設置，如果程序內部出現問題導致處理超時，併發會把服務器拖垮。
5.對雲上的調用鏈路和網絡架構需要非常熟悉，這樣才能快速定位問題。

其實系統一旦上雲之後整個網絡架構變得複雜，干擾因素太多，排查也會面臨比較大的依賴，監控告警覆蓋面和基數也比較大很難察覺到個別業務線。（其實有些問題根本找不到答案。）
所有無法復現的故障是最難排查的，因為只能事後靠證據一環環解釋，涉及到網絡問題情況就更加複雜。

作者：王清培（趣頭條 Tech Leader）

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!

※網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司，幫您輕鬆架站!

※想知道最厲害的台北網頁設計公司推薦、台中網頁設計公司推薦專業設計師”嚨底家”!!