11

Finagle内で使用されるNettyは、「ハンドラー」のパイプラインを使用して、バインドされたデータを順次処理します。Nettyの例と含まれているライブラリは、認証、プロトコルコーデック、サービスの実際のビジネスロジックなどに使用されるさまざまなハンドラーを示しています。

Finagleはハンドラーの概念を採用しているようで、代わりにAPIユーザーにコーデック、フィルター、およびサービスを直接提供しています。これらにはさまざまな署名がありますが、Finagleの新規ユーザーには、サーバー全体の各部分を実装するためにどちらを使用するかを決定するタスクが残されています。チェーンをさまざまなNettyハンドラーに分割する場所を単に決定するのではなく、チェーンの最後にある単一のサービスに対して、フィルターに対して、コーデックの一部にする部分を決定する必要があります。要約すると、FinagleはNettyよりも高レベルのライブラリであり、サービスの構築タスクを容易にするはずですが、APIユーザーはより多くの選択肢を選択できる可能性があります。

処理ストリームの特定の部分をコーデック、フィルター、単一サービスに配置するための重要な決定ポイントと長所/短所は何ですか？パイプラインをさらに拡張できる可能性がある場合は、代わりにサービスロジックをフィルターに配置し、パイプラインの最後に「noop」サービスを配置する必要がありますか？（パイプラインのハンドラーとしての）フィルターの順序付けの柔軟性を考えると、一方の端に単一のコーデックがあり、もう一方の端にサービスがあるのに対して、なぜ「すべて」をフィルターにすべきではないのでしょうか。

4

2 に答える 2

18

Finagle と Netty の構造はまったく異なります。

サービス、フィルター、およびコーデックは、実際にはまったく直交する概念です。試して説明しましょう。ユーザーとして - つまり。コーデックの実装者ではありません。サービスとフィルターについてのみ知っておく必要があります。

まず、コーデックは、バイト ストリームを個別の要求または応答に変換する役割を果たします。たとえば、HTTP コーデックはバイトストリームを読み取り、HttpRequestまたはHttpResponseオブジェクトを生成します。

AServiceは、要求が与えられると、応答の を生成するオブジェクトです。Futureこれは単純な関数です (実際には を拡張しますFunction)。サービスの興味深い点は、サービスが対称であることです。クライアントはサービスを使用し、サーバーはサービスを提供します。サービスの重要な点は、(1) 個別の要求と応答で動作すること、および (2) 要求を応答に一致させることです。これらはすべて、そのタイプによって暗示されます。これが、finagle を「RPC」システムと呼ぶ理由です。要求/応答のペアが RPC の特徴を定義しています。

サービスがありますが、サービス自体とは独立してサービスの動作を変更することは便利で重要です。たとえば、タイムアウト機能または再試行を提供したい場合があります。これが私Filterたちのすることです。これらは、サービスの動作を変更するサービスに依存しない方法を提供します。これにより、モジュール性と再利用が強化されました。たとえば、finagle のタイムアウトはフィルターとして実装され、任意のサービスに適用できます。

サービスとフィルターの詳細については、Scala Schoolを参照してください。

*

それでは、これを Netty のハンドラーと対比してみましょう。これらはスタック可能な汎用イベント ハンドラーです。それらを使用して多くの類似したことを行うことができますが、基礎となるモデルは、接続に関連付けられたイベントのストリームです。これにより、操作しているパイプラインについて多くの仮定を立てることができないため、一般的なモジュール (たとえば、再試行、タイムアウト、失敗の発生、トレース、例外レポートなどを実装する) を作成することがより困難になります。

また、Netty パイプラインは、プロトコルの実装をアプリケーション ハンドラーと混同します。Finagle はこの 2 つを明確に分離しており、そのおかげでモジュール性が強化されています。

Netty は素晴らしい抽象化のセットですが、RPC サーバーの場合、finagle はより優れたモジュール性と構成可能性を提供します。

*

大まかに要約すると、Netty は「ストリーム指向」であり、finagle は「サービス指向」であると言えます。これは重要な違いであり、堅牢な RPC サービスをモジュール方式で実装できるようにするものです。たとえば、RPC クライアントにとって非常に重要な接続プーリングと負荷分散は、サービス モデルから自然に除外されますが、ストリーム モデルには適合しません。

于 2012-07-21T05:40:41.380 に答える
0

コーデックかフィルターかの決定であってはならないと思います。コーデックはむしろフィルターでラップされます。

決定ロジックに関しては、どこに配置するかは、下すべき決定によって異なります。ビジネス上の決定はビジネス ロジックに沿って行う必要がありますが、ルーティング、負荷分散、特定の種類のアクセス制御などの一部の決定は、フィルターとしてうまく適合する可能性があります。

通常、サービスは行の最後にあり、Finagle とそのフィルターを使用すると、そこに到達できます。

これが理にかなっているかわからない？

技術的な詳細から少し離れて、ロジックを見てください。何を何に責任を負わせ、設計に合うようにテクノロジを取得する必要があります。テクノロジーに合わせてデザインを曲げすぎないでください。

ところで、私は Finagle の上にゲートウェイ サーバーを実装しましたが、これは素晴らしいライブラリです。

あなたが何を構築しようとしているのかはわかりませんが、可能性のある代替案も見てみましょう: スプレー、ブルーアイズ、フィルターなし、Play-Mini など。

于 2012-07-19T18:22:00.030 に答える