Netty対Apache MINA

どちらもほぼ同じ機能を提供します。高性能TCPサーバーを開発するには、どちらを選択すればよいですか？長所と短所は何ですか？

参照リンク：

Apache MINA（ソース）

Netty（ソース）

MINAとNettyは同じような野心を持っていますが、実際にはかなり異なっているため、慎重に選択を検討する必要があります。私たちはMINAで多くの経験を積んでいて、Nettyで遊ぶ時間を持っていたので幸運でした。特に、よりクリーンなAPIとはるかに優れたドキュメントが気に入りました。紙の上でもパフォーマンスは良くなったようです。さらに重要なことは、Trustin Leeが私たちの質問に答えるために待機していることを知っていて、彼は確かにそうしました。

Nettyの方がすべてが簡単です。限目。MINAですでに使用していたのと同じ機能を再実装しようとしていましたが、ゼロから実装しました。優れたドキュメンテーションと例をたどることにより、はるかに少ないコードでより多くの機能が得られました。

Netty Pipelineは私たちにとってより効果的でした。これは、すべてがハンドラーであり、アップストリームイベント、ダウンストリームイベント、またはその両方を処理するか、より低レベルのものを消費するかを決定するのはユーザー次第です。「再生」デコーダーでバイトを取得することは、ほとんどの楽しみでした。パイプラインをその場で簡単に再構成できることも非常に良かったです。

しかし、Nettyの主な魅力であるimhoは、「1つのカバレッジ」を持つパイプラインハンドラーを作成できることです。このカバレッジアノテーションについてはすでにドキュメントで読んだことがあるかもしれませんが、基本的には1行のコードで状態を示します。いじり、セッションマップ、同期などは一切なく、通常の変数（たとえば「ユーザー名」）を宣言して使用するだけで済みました。

しかし、それから障害物にぶつかった。MINAの下にはすでにマルチプロトコルサーバーがあり、アプリケーションプロトコルはTCP / IP、HTTP、UDPで実行されていました。Nettyに切り替えると、SSLとHTTPSが数分でリストに追加されました！これまでのところ良好ですが、UDPに関しては、私たちが失敗したことに気付きました。UDPを「接続された」プロトコルとして扱うことができるという点で、MINAは私たちにとって非常に良かったです。Nettyの下では、そのような抽象化はありません。UDPはコネクションレスであり、Nettyはそれをそのように扱います。Nettyは、MINAよりも低いレベルでUDPのコネクションレスの性質をより多く公開します。Nettyの下でUDPを使用すると、MINAが提供するより高いレベルの抽象化ではできないことよりも、私たちが頼りにできることがいくつかあります。

「接続されたUDP」ラッパーなどを追加するのはそれほど簡単ではありません。時間の制約と、先へ進む最善の方法はNettyに独自のトランスポートプロバイダーを実装することでしたが、それは迅速ではないため、最終的にNettyを放棄する必要がありました。

したがって、それらの違いをよく見て、トリッキーな機能が期待どおりに機能しているかどうかをテストできる段階にすばやく進んでください。Nettyがその仕事をすることに満足しているなら、私はMINAを介してそれに行くのをためらわないでしょう。MINAからNettyに移行する場合も同じことが当てはまりますが、2つのAPIは実際には大きく異なるため、Nettyの仮想書き換えを検討する必要があります。後悔はしません。

MINAはより複雑な機能と比較的低いパフォーマンスを犠牲にして、すぐに使える機能を備えています。これらの機能の一部はコアに統合されているため、ユーザーが必要としていない場合でも削除できません。Nettyでは、MINAの既知の長所を維持しながら、このような設計の問題に対処しようとしました。

現在、MINAで利用できるほとんどの機能はNettyでも利用できます。私の意見では、Nettyはよりクリーンでドキュメント化されたAPIを持っています。Nettyは、MINAをゼロから再構築して既知の問題に対処しようとした結果です。重要な機能が欠けている場合は、お気軽にフォーラムに投稿してください。私はあなたの懸念に対処できてうれしいです。

Nettyの方が開発サイクルが速いことにも注意してください。簡単に言えば、最近のリリースのリリース日を確認してください。また、MINAチームがAPIの互換性を完全に破壊することになることを意味するMINA 3の大幅な書き換えに進むことを検討する必要があります。

私は2つの「Google Protobuffer RPC」実装をパフォーマンステストしました。1つはNetty（netty-protobuf-rpc）に基づいており、もう1つはmina（protobuf-mina-rpc）に基づいていました。Nettyは、すべてのメッセージサイズで一貫して高速（+-10％）になりました。これは、Netty Webサイトでの全体的なパフォーマンスの主張を裏付けています。このようなRPCライブラリを使用するときは、コードの効率を少しずつ絞りたいので、Nettyに基づいてprotobuf-rpc-proを作成しました。私は過去にMINAを使用しましたが、2.0に関するドキュメントには大きな穴があり、APIの下位互換性が失われていることは大きなマイナス点です。

MINAとNettyは、最初は同じ作成者によって設計および構築されました。それが、彼らがお互いにとても似ている理由です。MINAは少し高いレベルで設計されており、もう少し多くの機能がありますが、Nettyは少し高速です。基本的な考え方は同じですが、それほど大きな違いはないと思います。

Nettyサイトでは、いくつかのパフォーマンスレポートを見つけることができます。予想通り:-)彼らはNettyを最高のパフォーマンスを持つフレームワークとして指摘しました。

私はNettyを使用したことはありませんが、MINAを使用してTCPプロトコルを実装しました。エンコードとデコードの実装は簡単でしたが、ステートマシンの実装はそれほど簡単ではありませんでした。MINAは、ステートマシンの実装時に役立ついくつかのクラスを提供しますが、それらを使用するのは少し難しいと感じました。最終的に、MINAを廃止してプロトコルを最初から実装することを決定し、驚くべきことに、より高速なサーバーで終了しました。

私はNettyを好みます。

Twitterはまた、新しい検索システムを構築するためにNettyを選択し、最大3倍の速度で高速化しました。

参照：Twitter検索が3倍高速になりました

私たちは、よりクリーンなAPI、より優れたドキュメント、そしてさらに重要なことに、Twitterの他のいくつかのプロジェクトがこのフレームワークを使用しているため、MinaやJettyなどの他の競合他社よりもNettyを選びました。

サーバーのような小さなhttpを構築するためにMINAを使用したことはありません。これまでに遭遇した最大の問題：

1. それはあなたの「リクエスト」と「レスポンス」をメモリに保持します。私が使用することを選択したプロトコルはhttpであるため、これは唯一の問題です。ただし、これを回避するには独自のプロトコルを使用できます。
2. 大きなファイルを提供する場合に備えて、ディスクからストリームを提供するオプションはありません。再び独自のプロトコルを実装することで回避できます

それについて素晴らしいこと：

1. 多くの接続を処理できます
2. ある種の分散作業システムを実装することを選択した場合、ノードの1つがダウンして接続が失われたことを知ることは、別のノードで作業を再開するのに役立ちます。