5

現在、SOA スタイルのアプリケーションをクラウド上の PAAS にデプロイすることを検討しています。

Cloud Foundry、Heroku、Jelastic などの多くの PAAS プロバイダーを評価しています。

現時点では、簡単にするために、Grails アプリと、Jetty サーバーが組み込まれた 1 つのサービス jar ファイルしかありません。これは複数のサービスと Web フロント エンドに拡張され、サービスは中間にあり、すべてが rabbit mq と http の混合を介して通信します。

現在、これらを PAAS に展開する方法のトポロジーを理解するのに苦労しています。

私の質問は次のとおりです。

  1. すべてのサービスと Web アプリは、PAAS 内の最上位の「アプリケーション」としてデプロイする必要がありますか (たとえば、Heroku で dyno を使用できますか?)

  2. その場合、サービスへのアクセスを制限して、Web アプリケーション (最終的にはゲートウェイ) からのみリクエストを送信できるようにすることができます。

  3. 各サービスの複数のインスタンスが存在する可能性があるため、負荷分散 (および自動スケーリング) の恩恵を受けるために、それらはトップレベルのアプリとして存在する必要がありますか?

  4. 各サービスが独自のデータストアを持つ場合、これもアプリである必要があると思いますか?

  5. 各サービスに完全なアプリを使用せずにこれを達成する方法がある場合、ノードはどのように個別にアドレス指定できますか? ある種のディレクトリ サービスに自分自身を登録できますか?

ありがとう！

4

1 に答える 1

5

これは私が最も熟達しているもの（そして私が支払われているもの）であるため、CloudFoundryについて回答します:)

前文: CloudFoundry には、アプリケーション (実行されるコードの断片。外部に公開される場合と公開されない場合があります。つまり、standalone ランタイムがあります) とサービス (データストアなど、RabbitMQ がそのカテゴリに分類されます) の概念があります。アプリをデプロイし、0 個以上のサービスにバインドします。

  1. サービスと呼ぶもの (つまり、CF の意味でのサービスではなく、SOA の意味でのサービス) のそれぞれを個別に再デプロイおよびスケーリングする機能が必要であると仮定して、私は「はい」と答えます。
  2. CloudFoundry の場合、答えは「いいえ」です。プログラムでそれを行う必要があります。サービスが *eg* RabbitMQを介してのみ通信する場合、それらを StandAlone アプリとしてデプロイすることになり、そもそも Web アドレスを指定できないことに注意してください。
  3. CloudFoundry には「トップ レベル」と「その他のレベル」はありません。アプリケーションは、スケーリングできるものです。URL にバインドされたアプリケーションは、自動的に負荷分散されます。
  4. はい。いくつかの SOA 「サービス」を単一の「アプリ」としてパッケージ化し、その一部を CloudFoundry サービス A と通信させ、他の部分をサービス B と通信させることができることに注意してください。欠点については、1) を参照してください。
  5. これまでの回答から、答えは NO です。たとえば、RabbitMQ をメッセージ ブローカーとして使用する場合、ルーティング キーは一種の「ディレクトリ」として使用されます。

これが理にかなっていることを願っています:)

于 2012-10-09T09:00:39.420 に答える