1

サーバー/クライアントの設計に少し問題があり、アドバイスがあれば教えてください。

データ ストアを抽象化する Thrift サーバーがあります。サーバーが提供するインターフェイスを使用して、基本的なデータ ストアを受信、操作し、独自のデータを提供する、本質的にアウト プロセス プラグインである多数のクライアントが存在するという考えです。サーバーとその「プラグイン」によって提供されるデータにアクセスするだけのクライアントが他にも多数あります。

問題のケースは、これらの「プラグイン」の 1 つが独自のデータを提供し、そのデータへのインターフェースを提供したい場合です。サーバーは、プラグインのデータやインターフェースを認識してはなりません。

理想的には、すべてのクライアントがメインのリサイクル サーバーを介して機能にアクセスできるようにして、プラグインのファサードとして機能させたいと考えています。クライアントがプラグインによって提供されるデータを要求した場合、メイン サーバーはそのデータを提供するためにプラグインに委任できます。これは、各プラグインがthriftクライアントとサーバーであることを意味すると思います. 私はPythonでサーバーを書いたので、おそらくまだ定義されていないthrift呼び出しを処理できますが、これらの呼び出しを別のthriftサーバーIEがプロキシとして機能するように転送することは可能でしょうか?

別の方法は、プラグインをクライアントのみにして、データをサーバーにプッシュすることです。ただし、これらのメッセージの形式はサーバーには認識されず、さまざまな種類のデータに対応できるように十分に汎用的である必要があります。このデータへの便利なインターフェイスを他のクライアントに提供する方法がわかりません。

私の知る限り、所有するデータを保存および操作する方法を知っているのはプラグインだけなので、このアイデアはおそらく機能しません。

アドバイスをありがとう。どんな提案も歓迎します。

4

1 に答える 1

0

リクエストを利用可能なさまざまなプラグインに関連付けるために、何らかのメカニズムが必要なようです。理想的には、プラグインごとに公開された一連の操作ごとに異なる URL パスが存在する必要があります。

プラグインへの URL パスの一種のマップ/辞書を実装することを検討します。次に、受信したリクエストごとに、マップでルックアップを実行し、関連するプラグインを取得して、それに応じてリクエストを送信します。マップにエントリがない場合は、リダイレクト/プロキシが送信される可能性があります。たとえば、URL =http://yourThriftServer/path/operationの場合、操作またはパス操作がプラグインにマップされます。

追加の手順は、一種のメタ リクエストを実装することです。これにより、クライアントは、サーバーで使用可能な URL パス/操作を照会できます。

于 2012-05-18T09:06:06.410 に答える