N層Webアプリケーションでのユーザー認証の実装
私はすべてのヘルプとフィードバックに感謝します。これが冗長すぎる場合、太字の部分は重要な部分です。おそらく、私が環境に配慮した開発者であることを言及するのに役立ちます。こことStack Overflowに投稿された関連する質問から役立つ情報を見つけましたが、100％と感じたものはありません。
バックグラウンド
現在作業中ですが、クライアントによって設定された厳しい制約を持つWebアプリケーションを開発しています。通常、私たちはRailsショップですが、クライアントは本当に私たちと一緒に仕事をしたいと思っていました。したがって、彼らのアーキテクチャに合わせるために、ASP.NETを使用します。ASP.NETの経験はあまりありませんが、私を含む一部のチームは、デスクトップアプリケーションに.NETを使用しています。
このアプリケーションは3層で、次のものが含まれます。
- 一般向けサーバー
- Webサービスサーバー
- データサーバー
クライアントは高い需要を期待しており、いずれかの層に複数のサーバーがある場合があります。すべての層の間にファイアウォールがあります。私の理解では、これは非常に一般的な設定です。
主要な目標は、公衆向けサーバーからデータベースへのネットワーク経由のトリップを最小限に抑えることです。
問題
各層に潜在的に多くのサーバーがあるN層アプリケーションでパフォーマンスを妨げずにユーザー認証をどのように処理しますか？
これまでに行ったこと
私たちはビューステートを使用するという考えをいじっていましたが、結局これは悪い考えだと感じました。もちろん、ビューステートに再度アクセスすることに反対するわけではありませんが、ビューステートはCookieよりもメリットがなく、ユーザーがアプリケーションの複数のタブを開くのを難しくするだけだと感じています。
私は、カスタム実装されたセッションストアでデフォルトのセッション状態を使用する方法を調査してきました。 デフォルトのセッション状態は、ネットワークを介して送信される複数のリクエストを生成する傾向があります。ログインとログアウトは問題ありませんが、ユーザーがアプリを使用しているときは、これは望ましくありません。カスタムセッションストアは、影響を最小限に抑えるのに役立ちますが、十分ではありません。
結論と考えられるアイデア
データベース内へのアクセスは、アプリケーション内に入るとほぼすべての要求で避けられないため、おそらくユーザーにログイン成功のキーを提供するのが最善の方法です。次に、ユーザーが新しいページをリクエストするか、新しいページを投稿するときに、リクエストに関連するSQLトランザクションとともにそのキーを送信し、キーを検証できます。これにより、コードベースが大幅に簡素化されると思います。
したがって、問題を繰り返します：各層に潜在的に多くのサーバーがあるN層アプリケーションのパフォーマンスを妨げずにユーザー認証をどのように処理しますか？上記のアイデアは、しっかりした実装？
おかげで、
ジョナソン
多分私は冷笑的ですが、私はここで一般的な問題のにおいを嗅ぎます。彼らは高い需要を期待しているので、慎重に最適化して最初から最後まですべてを分散しています。彼らは製品を持っている前に。
このトラフィックのすべてを受け取ることをどのようにして知っていますか？
これらのトラフィックをすべて取得した場合、単純なものがスケーリングされないことをどのようにして知るのでしょうか。
正しい解決策は、バックグラウンドで単純なデータベースリクエストを実行する単純な関数を実装することですが、これを後で凝ったものに切り替えることができます。そして、証明された問題があるまでそれについて心配しないでください。 10年前、私は同じようなことをしました、そして毎時10万動的ページまでスケーリング問題にぶつかりませんでした。そして、そこで問題にぶつかったとき、問題はログインにぶつかることではありませんでした！
はい、拡張性の高い多数の豪華なアーキテクチャを提案できます。私もいくつか作りました。しかし、そこに行く必要があるまでは、行くつもりはないと想定してください。