文章目錄

• 簡介
• 本文的目標
• 支持多個圖片服務
• http2處理器
• 處理頁面和圖像
• 價值上億的速度優化方案
• 總結

簡介

其實軟件界最賺錢的不是寫代碼的，寫代碼的只能叫馬龍，高級點的叫做程序員，都是苦力活。那么有沒有高大上的職業呢？這個必須有，他們的名字就叫做咨詢師。

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

今天除了要給大家介紹一下如何在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>() {@Overrideprotected 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>() {@Overrideprotected 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() {@Overridepublic 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/

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

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

超強干貨來襲 云風專訪：近40年碼齡，通宵達旦的技術人生

總結

以上是生活随笔為你收集整理的netty系列之:一个价值上亿的网站速度优化方案的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。