netty系列之:一個價值上億的網站速度優化方案

flydean發表於2021-12-16
Netty網站優化

簡介

其實軟體界最賺錢的不是寫程式碼的，寫程式碼的只能叫馬龍，高階點的叫做程式設計師，都是苦力活。那麼有沒有高大上的職業呢？這個必須有，他們的名字就叫做諮詢師。

諮詢師就是去幫企業做方案、做架構、做優化的，有時候一個簡單的程式碼改動、一個架構的調整都可以讓軟體或者流程更加高效的執行，從而為企業節省上億的開支。

今天除了要給大家介紹一下如何在netty中同時支援http和https協議之外，還給大家介紹一個價值上億的網站資料優化方案，有了這個方案，年薪百萬不是夢！

本文的目標

本文將會給大家介紹一下如何在一個netty服務中同時支援http和http2兩種協議，在這兩個伺服器中，提供了對多圖片的訪問支援，我們介紹如何從伺服器端返回多個圖片。最後介紹一個價值上億的速度優化方案，肯定大家會受益匪淺。

支援多個圖片服務

對於伺服器端來說，是通過ServerBootstrap來啟動服務的，ServerBootstrap有一個group方法用來指定acceptor的group和client的group。

    public ServerBootstrap group(EventLoopGroup group) 
    public ServerBootstrap group(EventLoopGroup parentGroup, EventLoopGroup childGroup)

當然你可以指定兩個不同的group，也可以指定同一個group，它提供了兩個group方法，效果上沒太大的區別。

這裡我們現在主伺服器中建立一個EventLoopGroup，然後將其傳入到ImageHttp1Server和ImageHttp2Server中。然後分別在兩個server中呼叫group方法，然後配置handler即可。

先看一下ImageHttp1Server的構造：

        ServerBootstrap b = new ServerBootstrap();
        b.option(ChannelOption.SO_BACKLOG, 1024);
        b.group(group).channel(NioServerSocketChannel.class).handler(new LoggingHandler(LogLevel.INFO))
        .childHandler(new ChannelInitializer<SocketChannel>() {
            @Override
            protected void initChannel(SocketChannel ch){
                ch.pipeline().addLast(new HttpRequestDecoder(),
                                      new HttpResponseEncoder(),
                                      new HttpObjectAggregator(MAX_CONTENT_LENGTH),
                                      new Http1RequestHandler());
            }
        });

我們傳入了netty自帶的HttpRequestDecoder、HttpResponseEncoder和HttpObjectAggregator。還有一個自定義的Http1RequestHandler。

再看一下ImageHttp2Server的構造：

ServerBootstrap b = new ServerBootstrap();
        b.option(ChannelOption.SO_BACKLOG, 1024);
        b.group(group).channel(NioServerSocketChannel.class).childHandler(new ChannelInitializer<SocketChannel>() {
            @Override
            protected void initChannel(SocketChannel ch)  {
                ch.pipeline().addLast(sslCtx.newHandler(ch.alloc()), new CustProtocolNegotiationHandler());
            }
        });

為了簡單起見，我們預設如果從http來訪問的話，就使用http1服務，如果是從https來訪問的話，就使用http2服務。

所以在http2服務中，我們只需要自定義ProtocolNegotiationHandler即可，而不用處理clear text升級的請求。

http2處理器

在TLS環境中，我們通過自定義CustProtocolNegotiationHandler，繼承自ApplicationProtocolNegotiationHandler來進行客戶端和伺服器端協議的互動。

對於http2協議來說，使用了netty自帶的InboundHttp2ToHttpAdapterBuilder和HttpToHttp2ConnectionHandlerBuilder將http2 frame轉換成為http1的FullHttpRequest物件。這樣我們直接處理http1格式的訊息即可。

轉換過程如下：

DefaultHttp2Connection connection = new DefaultHttp2Connection(true);
        InboundHttp2ToHttpAdapter listener = new InboundHttp2ToHttpAdapterBuilder(connection)
                .propagateSettings(true).validateHttpHeaders(false)
                .maxContentLength(MAX_CONTENT_LENGTH).build();

        ctx.pipeline().addLast(new HttpToHttp2ConnectionHandlerBuilder()
                .frameListener(listener)
                .connection(connection).build());

        ctx.pipeline().addLast(new Http2RequestHandler());

轉換轉換的http2 handler和普通的http1的handler唯一不同的是需要額外設定一個streamId屬性到請求頭和響應頭中。

並且不需要處理http1特有的100-continue和KeepAlive。其他的和http1 handler沒什麼兩樣。

處理頁面和影像

因為我們使用轉換器將http2的frame轉換成了http1的普通物件，所以對請求相應的頁面和影像來說，跟http1的處理沒什麼太大區別。

對於頁面來說，我們需要獲取要返回的html，然後設定CONTENT_TYPE為"text/html; charset=UTF-8"，返回即可：

    private void handlePage(ChannelHandlerContext ctx, String streamId,  FullHttpRequest request) throws IOException {
        ByteBuf content =ImagePage.getContent();
        FullHttpResponse response = new DefaultFullHttpResponse(HTTP_1_1, OK, content);
        response.headers().set(CONTENT_TYPE, "text/html; charset=UTF-8");
        sendResponse(ctx, streamId, response, request);
    }

對於影像來說，我們獲取到要返回的影像，將其轉換成為ByteBuf，然後設定CONTENT_TYPE為"image/jpeg"，返回即可：

    private void handleImage(String id, ChannelHandlerContext ctx, String streamId,
            FullHttpRequest request) {
        ByteBuf image = ImagePage.getImage(parseInt(id));
        FullHttpResponse response = new DefaultFullHttpResponse(HTTP_1_1, OK, image);
        response.headers().set(CONTENT_TYPE, "image/jpeg");
        sendResponse(ctx, streamId, response, request);
    }

這樣，我們就能夠在netty伺服器端同時處理頁面請求和圖片請求了。

價值上億的速度優化方案

終於要到本文中最精彩的部分了，價值上億的速度優化方案是什麼呢？

在講這個方案之前，先給大家講一個抗洪搶險的故事。有兩個縣都住在一條大河的旁邊。這條大河很不安穩，經常會發洪災，但是兩個縣的縣長做法很不同。

A縣的縣長認真負責，派人定期巡邏檢查所屬的河段，築堤、種樹、巡視，一刻都放鬆，在他的任期平平安安，沒有發生任何洪水潰堤的情況。

B縣的縣長從來不巡檢，一道河水氾濫的時候，B縣長就組織人抗洪搶險，然後媒體全都報導的是B縣長抗洪的豐功偉績，最後B縣長由於政績突出，升任市長。

好了，故事講完了，接下來是我們的優化。不管是使用者請求頁面還是圖片，最終都需要呼叫ctx.writeAndFlush(response)方法進行響應回寫。

如果將其放入一個定時任務中，來定時執行，如下所示：

ctx.executor().schedule(new Runnable() {
            @Override
            public void run() {
                ctx.writeAndFlush(response);
            }
        }, latency, TimeUnit.MILLISECONDS);

那麼伺服器在經過latency指定的毫秒之後，才會傳送對應的響應。比如這裡我們設定latency的值為5秒。

當然5秒是不能夠讓人滿意的，於是領導或者客戶找到你，說讓你給優化一下。你說這個效能問題是很難的，涉及到了麥克斯韋方程組和熱力學第三定律，需要一個月時間。領導說好，擼起袖子加油幹，下個月給你工資漲50%。

一個月後，你把latency改成2.5秒，效能提升了100%，這個優化值不值幾個億？

總結

當然，上一節給大家開個玩笑，不過在netty響應中使用定時任務的技巧，大家也應該牢牢掌握，原因你懂的！

本文的例子可以參考：learn-netty4

本文已收錄於 http://www.flydean.com/34-netty-multiple-server/

最通俗的解讀，最深刻的乾貨，最簡潔的教程，眾多你不知道的小技巧等你來發現！

歡迎關注我的公眾號:「程式那些事」,懂技術，更懂你！

相關文章