Netty対Apache MINA
MINAとNettyの野望は似ていますが、実際にはまったく異なっているため、選択を慎重に検討する必要があります。 MINAで多くの経験があり、Nettyをいじることができたという点で幸運でした。特にきれいなAPIとより優れたドキュメントが気に入りました。紙上でもパフォーマンスが向上したようです。さらに重要なことは、Trustin Leeが私たちの質問に答えてくれることを知っていたということです。
Nettyではすべてが簡単になりました。期間。すでにMINAで使用していたのと同じ機能を再実装しようとしていましたが、最初から実装しました。優れたドキュメントと例に従うことで、はるかに少ないコードでより多くの機能を実現できました。
Netty Pipelineの方がうまく機能しました。すべてがハンドラーであり、アップストリームイベント、ダウンストリームイベント、またはその両方を処理するか、より低レベルのものを消費するかを決定するのはあなた次第であるMINAよりも簡単です。 「リプレイ」デコーダでバイトをゴブリングすることは、ほとんど喜びでした。また、パイプラインをオンザフライで簡単に再構成できることも非常に良かったです。
しかし、Nettyの最大の魅力は、「1つのカバレッジ」でパイプラインハンドラーを作成できることです。おそらく既にドキュメントでこのカバレッジアノテーションについて読んだことがありますが、基本的には1行のコードで状態を示します。いじり、セッションマップ、同期などは一切なく、通常の変数（「ユーザー名」など）を宣言して使用することができました。
しかし、それから私たちは障害にぶつかりました。すでにMINAの下にマルチプロトコルサーバーがあり、そこではアプリケーションプロトコルがTCP/IP、HTTP、およびUDPで実行されました。 Nettyに切り替えたとき、数分でリストにSSLとHTTPSを追加しました！これまでのところ非常に良いことですが、UDPに関しては、私たちはスリップしたことに気付きました。 MINAは、UDPを「接続された」プロトコルとして扱うことができるという点で非常に良かったです。 Nettyでは、そのような抽象化はありません。 UDPはコネクションレスであり、Nettyはそれをそのように扱います。 Nettyは、MINAよりも低いレベルでUDPのコネクションレス型の性質をより多く公開します。 NettyでUDPを使用してできることは、MINAが提供する高レベルの抽象化ではできないが、私たちが依存していることです。
「接続されたUDP」ラッパーなどを追加するのはそれほど簡単ではありません。時間の制約と、最善の方法はNettyで独自のトランスポートプロバイダーを実装することである（これは迅速ではない）というTrustinのアドバイスを考えると、最終的にNettyを放棄しなければなりませんでした。
そのため、それらの違いをよく見て、トリッキーな機能が期待どおりに機能していることをテストできる段階に素早く進んでください。 Nettyがその仕事をすることに満足しているなら、MINAでそれを使うことをheしません。 MINAからNettyに移行する場合も同じことが当てはまりますが、2つのAPIは実際には大幅に異なるため、Nettyの仮想書き換えを検討する必要があります。後悔しないでください。
MINAには、より複雑な機能と比較的低いパフォーマンスという犠牲を払って、すぐに使用できる機能があります。これらの機能の一部は、ユーザーが必要としない場合でも削除できないほどにコアに統合されています。 Nettyでは、MINAの既知の長所を維持しながら、このような設計上の問題に対処しようとしました。
現在、MINAで利用可能なほとんどの機能はNettyでも利用できます。私の意見では、NettyはMINAをゼロから再構築して既知の問題に対処しようとした結果であるため、Nettyにはよりクリーンで文書化されたAPIがあります。重要な機能が欠けていることがわかった場合は、フォーラムに提案を投稿してください。私はあなたの懸念に対処してうれしいです。
Nettyの開発サイクルが速いことに注意することも重要です。単に、最近のリリースのリリース日を確認してください。また、MINAチームが大幅な書き換えMINA 3に進むことを検討する必要があります。これは、APIの互換性を完全に破壊することを意味します。
1つはNetty（netty-protobuf-rpc）に基づいており、もう1つはmina（protobuf-mina-rpc）に基づいている2つの「Google Protobuffer RPC」実装のパフォーマンスをテストしました。 Nettyは、すべてのメッセージサイズで一貫して高速（+-10％）になりました。これは、Netty Webサイトの全体的なパフォーマンスの主張を裏付けています。このようなRPCライブラリを使用するときは、コードのあらゆる効率を絞りたいので、Nettyに基づいて protobuf-rpc-pro と書きました。私は過去にMINAを使用しましたが、2.0のドキュメントには大きな穴があり、APIの下位互換性の破綻には大きなマイナスがあります。
MINAとNettyは、最初は同じ著者によって設計および構築されました。それが、彼らがお互いにとても似ている理由です。 MINAはもう少し機能が少し高いレベルで設計されていますが、Nettyは少し高速です。基本的な概念は同じで、大きな違いはないと思います。
Nettyサイトでは、いくつかのパフォーマンスを見つけることができます reports 。予想どおり:-)彼らはNettyが最高のパフォーマンスを備えたフレームワークであると指摘しています。
Nettyを使用したことはありませんが、MINAを使用してTCPプロトコルを実装しました。エンコードとデコードの実装は簡単でしたが、ステートマシンの実装はそれほど簡単ではありませんでした。 MINAには、ステートマシンを実装する際に役立つクラスがいくつかありますが、使いにくいと感じました。結局、MINAを捨ててゼロからプロトコルを実装することにし、驚くべきことに、より高速なサーバーで終了しました。
Nettyが好きです。
Twitterは、新しい検索システムを構築するためにNettyを選択し、3倍高速化しました。
Netaを選択したのは、MinaやJettyなどの他の競合他社よりもNettyを選択したためです。それは、クリーンなAPI、優れたドキュメント、さらに重要なことに、Twitterの他のいくつかのプロジェクトがこのフレームワークを使用しているためです。
MINAを使用して小さなhttpのようなサーバーを構築したことがあります。これまでに遭遇した最大の問題：
- それはあなたの「リクエスト」と「レスポンス」をメモリに保持します。使用するプロトコルはhttpであるため、これは問題にすぎません。ただし、独自のプロトコルを使用してこれを回避できます。
- 大きなファイルを提供したい場合に、ディスクからストリームを提供するオプションはありません。独自のプロトコルを実装することで回避できます
それについての素晴らしいこと：
- 多くの接続を処理できます
- ある種の分散作業システムを実装することを選択した場合、ノードの1つがダウンして接続を失ったことを知ることは、別のノードで作業を再開するのに役立ちます。