6

これは新しいことではないかもしれませんが、Azure の展開中に少し混乱するので、誰かが私を正しい軌道に乗せてくれることを願っています。Azure への展開を計画中です。これは私が持っているものです

  1. パブリック向けの ASP.Net MVC アプリ (web-role) + WCF サービス (web-role) は、この asp.net アプリ + WCF サービス (worker-role) にのみアクセス可能になり、1. メッセージ キュー経由で再度アクセス可能になります。
  2. Id-Provider (Relying Party である 1 の場合) + WCF サービス (web-role) として機能するカスタム STS、つまり ASP.NET MVC アプリ (web-role) は、STS 機能の一部を 1 などの RP に公開します。
  3. SQL Azure: 1 と 2 によってアクセスされます。 注: 1. 最終的には、Web でホストされる複数の wcf サービスと、内部および外部アクセス用のワーカー ロールを備えたポータルに成長します。

私の質問は、1. が一般に公開されるアプリになり、2. が 1. セキュリティ (内部) をフェデレートするためのものであるかどうかです。1. いつかスケールアウトが必要になることを念頭に置いて、Azure での展開をどのように計画すればよいでしょうか。後で 2 つの wcf サービスと一緒に? 1 つのクラウド サービスに発行するのか、それともどのように発行するのか?. 私の理解では、クラウド サービスは n-web/worker ロールの論理コンテナーです。しかし、この場合の両方のasp.netアプリのように2つのWebソールがある場合、どちらがデフォルトになりますか?

宜しくお願いします サティシュ

4

2 に答える 2

5

既定では、ソリューション内のすべての Web ロールはパブリックです。必要に応じて、サービス定義に移動して HTTP エンドポイントを削除することで、これを変更できます。クラウド サービスでのみ使用できる内部 HTTP エンドポイントを定義することもできます。ロード バランサーには何も公開されません。すべての Web ロールを同じプロジェクトに配置する利点は、RoleEnvironment と各 Web ロールを動的に検査しやすいことです。つまり、ソリューション内のすべてのロールは、他のロールとその使用可能なポートを「認識」しています。1 つのパッケージを展開するのも簡単です。

すべてのロールは同じ DNS 名 (.cloudapp.net) を共有します (ただし、ホスト ヘッダーを使用して区別できます) が、通常、.cloudapp.net サービスのロード バランサーを介して異なるポートを使用して公開されます。これは、サービスがクラウドで実行されているときに確認できます。ポータルには、ポートを指定するパブリック HTTP エンドポイントを持つ各ロールを指すリンクがあります。ポート 80 (外部 HTTP エンドポイントで定義) のサイトが「デフォルト」サイトです。

複数のクラウド プロジェクトを作成し、それらを個別にデプロイすることもできます。この場合、それぞれが独自の DNS 名を持ち、それぞれが個別に管理されます。これが良いことかどうかは、アプリケーションがどの程度緊密に結合されているか、および通常はソリューション全体を展開するのか、それともそのソリューション内の個々のロールを更新するだけなのかによって異なります。ただし、コストやスケーラビリティの違いはありません。

ロールの 1 つだけを頻繁に再デプロイする場合は、分割することをお勧めします。

于 2013-03-25T17:20:58.437 に答える
1

同じクラウド インスタンスに複数の Web ロールを展開するには、これを参照してください: Web サイトをクラウド サービスに展開するためのベスト プラクティス

複数の worker ロールは実装が難しくなります: インスタンスごとに複数の WorkerRoles を実行します

于 2013-03-25T17:13:52.833 に答える