19

実際のプロジェクトではどのようなサーバーを目にしますか?

1) Web サービスはステートレスである必要があります: 基本的に、すべてのリクエストでユーザー名/パスワードを送信する必要があり、すべてのリクエストで HTTPS を使用する必要があり、必要に応じて毎回 User オブジェクトを認証してロードします。

2) Web サービスのセッション: Web コンテナーのように、少なくとも認証済みのユーザー オブジェクトを保存し、セッション ID に似たものを保持できるため、リクエストごとにユーザーを認証、読み込み、確認する必要がありません。

3) スティッキー サービス (リクエスト間で永続的なサービス): https://jax-ws.dev.java.net/nonav/2.1/docs/statefulWebservice.html

ステートフル サービス (および Web アプリケーション セッション) のスケーラビリティの問題は理解していますが、ショッピング カートなど、何らかの状態が必要になる場合があります。ただし、この状態をデータベースに入れる (バックエンドをある種のセッションarghとして使用する) か、状態全体をクライアントに渡すこともできます (クライアントはショッピング カート全体を再送信する責任を負います)。

実際のところ、少なくとも Web アプリケーションの場合、セッションは多くの状況で大いに役立ちます。システムが「Web サーバーがダウンした場合、ユーザーは何をしていても最初からやり直さなければならない」ことを受け入れる場合、またはそれが受け入れられない場合はセッション クラスターを試すことができる場合、スケーラビリティの問題は無視できます。

Web サービスの場合はどうですか? Web サービスは Web アプリケーションとは大きく異なり、オプション 1) (常にステートレス) を受け入れると結論付けたいと思いますが、実際のプロジェクトの経験に基づいた他の意見を聞くことができれば幸いです。

4

5 に答える 5

19

それはほんのわずかな違いですが、それでも言及する必要があります：

スケーラビリティを損なうのは Web サービスの状態ではなく、スケーラビリティを損なうWebサービスをホストしているアプリケーション サーバーの状態です。このユーザーがこのサーバーにアクセスする必要があると言った瞬間 (スティッキー セッションで行われるように) は、事実上、スケーラビリティ オプションを制限していることになります。あなたが到達したいポイントは、「負荷分散された無料の App サーバーのいずれか」がこの Web サービス要求を処理できるということです。App Server を 1 つ追加すると、% より多くのユーザーを処理できるはずです。

状態を維持して認証トークンを渡し、リクエストごとにサービスを取得してデータストアから「状態」を取得する場合は、まったく問題ありません (個人的にお勧めします)。 /値データ ストア)。これが、Amazon が SimpleDb で、Google が BigTable で行う方法です。

Ebay は少し異なるアプローチを取り、クライアントの状態のほとんどを Cookie に保存して、すべてのリクエストで渡されるようにします。より多くのトラフィックを生成しますが、どのサーバーでもリクエストを処理できるため、スケーラブルです。

スケーラブルなデータ ストアが必要な場合は、redis を検討することをお勧めします。redisには、キー/値データ ストアでは勝てない速度と機能があります。

高速でスケーラブルなサービスを構築する方法に関する優れた資料にアクセスしたい場合は、highscalability.comもチェックしてください。

于 2010-02-09T23:39:07.757 に答える
7

理想的には、Web サービス (および Web サイト) はステートレスであるべきです。

残念ながら、これには問題領域をよく考え抜いた上で、懸念事項を明確に分離する必要があります。

実際には、実際にはほとんどの実際のWeb サイトは状態に依存していることがわかりましたが、これによりスケーラビリティが制限されます。

また、実際のWeb サービスの多くも状態に依存していることに気付きました。

最終的に「正しい」決定は、特定の問題に対して機能するものであるため、状態に依存する Web サービスを記述し、スケーラビリティが問題になる場合は後でリファクタリングしても問題ないでしょう。

于 2009-06-17T22:46:03.667 に答える
2

サービスが単一のトランザクション指向 (株価情報を取得するなど) であるか、またはサービスからの出力が複数のトランザクションにわたって特定のクライアントから提供されたデータに依存しているか (その場合、状態を維持する必要があります) に大きく依存します。

スケーラビリティの問題に関しては、データベースに状態を保存することは実際には悪い方法ではありません (実際、サーバー ファーム全体でサービスの負荷を分散している場合は、おそらくこれが唯一の方法です)。

于 2009-06-17T22:45:14.153 に答える
0

状態と認証を同一視しているようです。ユーザー名とパスワードをセッション状態に保存することに慣れているのではないでしょうか?

これは、古い ASMX Web サービスでも必要ありません。必要な情報を「ログイン」操作に渡すだけです。この操作は、「認証チケット」ヘッダーを返すように定義されます。

認証を必要とする他のすべての操作には、この「認証チケット」ヘッダーが必要です。それぞれがヘッダーをチェックして、有効な認証済みユーザーを表しているかどうかを確認します。もしそうなら、彼らは彼らの仕事を実行します。そうでない場合は、認証が必要であることを示す SOAP Fault を返します。

状態は必要ありません。サービスが実行されている任意のサーバー (たとえば、Web ファーム) で認証チケットを検証できることを確認するだけで問題ありません。

于 2009-06-17T23:28:04.143 に答える