6

分散環境で Thrift サービスを見つけるために、Zookeeper の上にサービス検出レイヤーを構築しました。現在、これらのサービスを本番環境で実行するための最良の方法を探しています。

現在、Tomcat に展開される war をパッケージ化することによって行われます。TThreadPoolServerサーブレットのインスタンス化中に、Tomcat の内部を作成する Spring ApplicationContext が作成されます。

私はいくつかの理由でこれが好きではありません:

  • それは Tomcat を役に立たなくし、簡単な展開を容易にするためのハックのように感じます
  • Tomcat のスレッド プーリングと、リクエストを分散する最善の方法を見つけ出すために必要なすべてのロジックを回避します。

これを処理するための最良の戦略を見つけようとしている過程で、いくつかの代替案を思いつきました。

  • リサイクル サービスをスタンドアロン JAR として起動します (これは好きではありません。主な理由は、アプリ コンテナーの開発者が多くの時間を費やして取り組んできたロジックを再発明する必要があるためです)。
  • HTTP 経由でホストを節約するため、Tomcat スレッド プールとサービス リクエストのロジックを利用します (これについては、マイナーではありますが、パフォーマンス ヒットが発生するため、不明です)
  • これらのサービスをホストするために別のタイプのアプリケーション コンテナを使用する

以前に分散サーバーのホスティングをどのように処理したかについて、提案がある人はいますか? Tomcat 内で HTTP を使用した方が良いですか?

4

1 に答える 1

6

Tomcat を Thrift サーバーのホストとして使用してみましたが、追加の価値がないことがわかりました。このシナリオでは、サーブレット コンテナーのすべての機能 (リクエスト ルーティングなど) は必要ありません。一方、Tomcat は複雑さと可動部分を追加します (つまり、PermGen の問題を解決するのが難しくなります)。

Thrift over HTTP を使用すると、特に多数のクライアント接続を伴う高負荷のシナリオで、パフォーマンスに重大な影響が生じます。

そのため、Supervisor Daemon ( http://supervisord.org/ )の下でスタンドアロンの Thrift サービスを実行することになりました。これにより、分散展開の管理が非常に便利になります。HTTP 経由で Thrift API を公開する必要がある場合 (たとえば、JS クライアントの場合)、vert.x ( http://vertx.io/ ) に実装されたシン非同期プロキシを使用します。

于 2013-07-15T10:10:34.050 に答える