Netty対Apache MINA

https://stackoverflow.com/questions/1637752

08-07-2019
|

質問

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

参照リンク：

解決

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

Nettyではすべてが簡単になりました。期間。すでにMINAで使用していたのと同じ機能を再実装しようとしていましたが、最初から実装しました。優れたドキュメントと例に従うことで、はるかに少ないコードでより多くの機能を実現できました。

Netty Pipelineの方がうまく機能しました。すべてがハンドラーであり、アップストリームイベント、ダウンストリームイベント、またはその両方を処理するか、より低レベルのものを消費するかを決定するのはあなた次第であるMINAよりも簡単です。「リプレイ中」のバイトをゴブリングデコーダーはほとんど喜びでした。パイプラインをオンザフライで簡単に再構成できることも非常に良かったです。

しかし、Nettyの主な魅力であるimhoは、「カバレッジ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の互換性を完全に破ることを意味します。

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

MINAとNettyは、最初に同じ著者によって設計および構築されました。それが、彼らがお互いにとても似ている理由です。 MINAはもう少し高い機能を備えたわずかに高いレベルで設計されていますが、Nettyは少し高速です。それほど大きな違いはなく、基本的な概念は同じだと思います。

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

Nettyを使用したことはありませんが、MINAを使用してTCPプロトコルを実装しました。エンコードとデコードの実装は簡単でしたが、ステートマシンの実装はそれほど簡単ではありませんでした。 MINAには、ステートマシンを実装する際に役立つクラスがいくつかありますが、使いにくいと感じました。結局、MINAを捨ててゼロからプロトコルを実装することにしました。驚くべきことに、より高速なサーバーで終了しました。

Nettyが好きです。

TwitterはNettyを選択して新しい検索システムを構築し、3倍高速化しました。

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

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

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

「リクエスト」を保持します;および「応答」メモリ内。使用するプロトコルはhttpであるため、これは問題にすぎません。ただし、これを回避するには独自のプロトコルを使用できます。
大きなファイルを提供したい場合に、ディスクからストリームを提供するオプションはありません。ここでも、独自のプロトコルを実装することで回避できます

それに関する素晴らしいこと：

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

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow