簡介
其實軟體界最賺錢的不是寫代碼的,寫代碼的隻能叫馬龍,進階點的叫做程式員,都是苦力活。那麼有沒有高大上的職業呢?這個必須有,他們的名字就叫做咨詢師。
咨詢師就是去幫企業做方案、做架構、做優化的,有時候一個簡單的代碼改動、一個架構的調整都可以讓軟體或者流程更加高效的運作,進而為企業節省上億的開支。
今天除了要給大家介紹一下如何在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/最通俗的解讀,最深刻的幹貨,最簡潔的教程,衆多你不知道的小技巧等你來發現!
歡迎關注我的公衆号:「程式那些事」,懂技術,更懂你!