Vert.xとNettyの違い
Vert.xはNettyベースのより高度なパッケージですが、解決する問題は異なります.Vert.xはNettyのスーパーセットであり、NettyのEventloopを利用して開発者により友好的なプログラミングモデルを提供しています.
Nettyは、大量の接続をどのようにサポートするかという問題を解決しました.
NettyはネットワークI/Oツールとして、ネットワークを操作したり、バイトを操作したりするなど、ビジネスにあまり関係のないものをいつでもはっきりと感じることができます.明らかに、Nettyが解決した同高スループットのネットワークI/O問題は、プログラミング問題ではない.Nettyを使用する場合、通常は
もう一度考えてみると、普段使っているTomcatというサーブレットコンテナは、ネットワークI/OもNIOで実現されているので、Nettyとはあまり差がありません.同期サーブレットを使用する場合、サーブレットにはいくつかの仕様があるため重くなり、XXXXXStream応答を呼び出すときに現在のスレッドをブロックする必要があります.Nettyは、現在指定されたNIOスレッドにあるかどうかを判断し、イベントとしてタスクキューに送信して実行を待つ必要があります.そうしないと、現在のビジネススレッドはブロックされません.
Vert.xビジネスプログラミング/エンジニアリング実装の問題をさらに解決
Vert.xはNettyに基づいて、1つのエンジニアリング上でプログラマーにより友好的なパッケージを提供します.
Vert.xは、JDBC呼び出し、Redisクエリー、ファイルI/Oなど、スレッドがブロックされる可能性のあるすべての操作を非同期化してCPU使用率をさらに搾取することを奨励します.それを実現するためにVert.x政府はjdbc-client、redis-client、mongodb-client、web-clientなど、多くの一般的なサービスの非同期化を実現しています.jsと同様に,いずれも操作開始時にコールバックを登録し,処理完了後にコールバックメソッドが実行される.
それと同時にVert.xはまた、
それだけでなく、工事の上でVert.xはまた、
この角度から見るとVert.xはNettyのスーパーセットであり,単純なネットワークI/O問題だけでなく,エンジニアリング問題の解決に重点を置いている.筆者は業務上、HTTPインタフェースを大量に呼び出す必要があるシーンに遭遇したことがある.従来のスレッドプールを使用している場合、1秒あたり1万のコンカレント数を単一のインスタンスでサポートすることはできません.Nettyを使用する場合は、I/Oに近い「最下位」コードを大量に記述する必要があり、煩雑です.最後にVert.を使用xは問題を解決し、コードは非常に簡潔で、性能は同じように強い.
ではVert.x何か劣勢はありますか?今まで、筆者はただ一つの劣勢を感じただけで、Vert.xバイナリプロトコルの解析は友好的ではない.パッケージングの程度が高いため,バイナリプロトコルの解析が柔軟ではなく,巧みな方法で実現する場合もある.そのため、バイナリプロトコルに基づいたサービスをしている場合はVert.をお勧めしませんか?x、おとなしくて実用的なNettyでしょう.
Nettyは、大量の接続をどのようにサポートするかという問題を解決しました.
NettyはネットワークI/Oツールとして、ネットワークを操作したり、バイトを操作したりするなど、ビジネスにあまり関係のないものをいつでもはっきりと感じることができます.明らかに、Nettyが解決した同高スループットのネットワークI/O問題は、プログラミング問題ではない.Nettyを使用する場合、通常は
ChannelHandlerを作成し、まず要求を復号し、タスクにカプセル化してから自分たちのビジネススレッドプールにトラフィックを転送し、その後、応答を符号化し、writeAndFlush()を呼び出してクライアントに応答を送信します.しかし、ビジネス・スレッド・プールで実行されるタスクは、スレッドをブロックするデータベース・クエリー、ネットワークI/Oなどの操作であり、これらの操作を実行するときに、現在のビジネス・スレッドがI/Oの完了を待っていても、ビジネス・スレッド・プールのリソースを浪費します.この場合、Nettyを使用すると、少量のスレッドで大量の接続をサポートする方法だけが解決されます.接続は確立されていますが、ビジネス処理ロジックはそれによってより速くなりません(スループットが高くなります).もう一度考えてみると、普段使っているTomcatというサーブレットコンテナは、ネットワークI/OもNIOで実現されているので、Nettyとはあまり差がありません.同期サーブレットを使用する場合、サーブレットにはいくつかの仕様があるため重くなり、XXXXXStream応答を呼び出すときに現在のスレッドをブロックする必要があります.Nettyは、現在指定されたNIOスレッドにあるかどうかを判断し、イベントとしてタスクキューに送信して実行を待つ必要があります.そうしないと、現在のビジネススレッドはブロックされません.
Vert.xビジネスプログラミング/エンジニアリング実装の問題をさらに解決
Vert.xはNettyに基づいて、1つのエンジニアリング上でプログラマーにより友好的なパッケージを提供します.
Vert.xは、JDBC呼び出し、Redisクエリー、ファイルI/Oなど、スレッドがブロックされる可能性のあるすべての操作を非同期化してCPU使用率をさらに搾取することを奨励します.それを実現するためにVert.x政府はjdbc-client、redis-client、mongodb-client、web-clientなど、多くの一般的なサービスの非同期化を実現しています.jsと同様に,いずれも操作開始時にコールバックを登録し,処理完了後にコールバックメソッドが実行される.
それと同時にVert.xはまた、
CompositeFeatureのような多くの使いやすい非同期調整ツールを提供しています.これにより、複数の非同期呼び出しを組み合わせて、一定の条件を満たしたときに別のコールバックをトリガーすることができます.これは、Nettyでビジネスロジックを非同期化しようとしたときにNettyに欠けているコンポーネントです.それだけでなく、工事の上でVert.xはまた、
Event Busのような「ワンストップ」のエンジニアリングソリューションを提供し、Verticleを複数のサーバ(クラスタ)に配備することができます.各インスタンスはEvent Bus通信を通じて、現在流行しているマイクロサービスアーキテクチャのために準備されている登録センターVert.x Service Discovery、遮断器Vert.x Circuit Breakerなどもあります.この角度から見るとVert.xはNettyのスーパーセットであり,単純なネットワークI/O問題だけでなく,エンジニアリング問題の解決に重点を置いている.筆者は業務上、HTTPインタフェースを大量に呼び出す必要があるシーンに遭遇したことがある.従来のスレッドプールを使用している場合、1秒あたり1万のコンカレント数を単一のインスタンスでサポートすることはできません.Nettyを使用する場合は、I/Oに近い「最下位」コードを大量に記述する必要があり、煩雑です.最後にVert.を使用xは問題を解決し、コードは非常に簡潔で、性能は同じように強い.
ではVert.x何か劣勢はありますか?今まで、筆者はただ一つの劣勢を感じただけで、Vert.xバイナリプロトコルの解析は友好的ではない.パッケージングの程度が高いため,バイナリプロトコルの解析が柔軟ではなく,巧みな方法で実現する場合もある.そのため、バイナリプロトコルに基づいたサービスをしている場合はVert.をお勧めしませんか?x、おとなしくて実用的なNettyでしょう.