0

これから着手しようとしているサブスクリプション サービスのアーキテクチャについていくつか質問があり、最適な設定方法についてフィードバックを求めています。

私は Basecamp のように多くの顧客を抱えているわけではなく、おそらく数百人であり、顧客サイトをセットアップするための堅固なアーキテクチャーは何かを考えていました。専用マシンで SQL Server と .NET を実行しています。データの制御と分離を行うために顧客ごとに新しいデータベースを作成する必要がありますか、それともすべてを 1 つのデータベースに保持する必要がありますか?

また、必要に応じて各サイトを変更できるように、顧客ごとにサブドメインを作成することも考えています。顧客 URL は次のようになります。

https://customer1.foobar.com

https://customer2.foobar.com

各顧客が必要に応じてカスタマイズできるように、サイトにアップロードされるレポートを「プラグイン」できるようにする予定です。私の頭の上では、これらのレポートをアップロードするために、各サブドメインを独自のコードベースに配置する必要があります。

したがって、メイン サイトで顧客が新しいサブスクリプションにサインアップし、メイン コード ベースから顧客用の新しいディレクトリをプログラムで作成し、顧客用の新しいディレクトリを指すサブ ドメインを作成し、最後に顧客のデータベースを作成します。

これは正しいと思いますか?私は正しい軌道に乗っていますか?他のそのようなサイトはどのように同じことを達成していますか?

これについて少し耳を傾けてくれてありがとう。

4

2 に答える 2

0

メンテナンスの観点からは、顧客ごとに仮想ディレクトリを用意するのは恐ろしいことです。同様のことを行ったので、あなたがほのめかしているように、別のドメインポインターを作成します。次に、参照ヘッダーをチェックして、表示される内容を確認できます。おそらく、1 つのメイン サイト テンプレートを作成し、顧客ごとに動的にブランド化するでしょう。顧客固有のレポート用に、またはその顧客に固有のカスタム ページが本当に必要な場合は、別のフォルダーを作成できます。それぞれ独自のサイトを作成するつもりはありません。

于 2010-03-13T01:31:36.143 に答える
0

別々のサイト (データベースを含む) の利点は、1 つのクライアントの運命が他のすべてのクライアントに拘束されないことです。他の全員に展開する前に、サブセットにアップグレード (試用) する方が簡単です。スコットが指摘するように、ここでの大きな問題は時間です。物事を可能な限り自動化したい (そして十分にテストした) などです。クライアントが離れたときも簡単です。いつでもデータベースをバックアップして送信できます(たとえば)。

新しいサイトやデータベースの自動プロビジョニングは簡単ではなく、それを行うアカウントには多くの権限が必要になるため、セキュリティ テストは通常​​よりも優れたものにする必要があります。

マルチテナンシー アプローチは時間を最小限に抑えるのに適していますが、注意が必要です。顧客データが混同されないようにする必要があります。

1 つのアプリ (およびデータベース) 内で機能する 1 つのアプローチは、HttpHandlers (おそらく MVC フレームワーク) を使用して、何らかのクライアント識別子が URL の一部になるようにすることですが、フォルダーは物理的にする必要はありません。存在します (または IIS の意味では事実上)。そうすれば、フォルダーのアクセス許可を正しく取得することを心配する必要はありません。ただし、クライアントとその ID を正しく識別し、クライアントが自分のものではない ID を使用して呼び出しを行うことができないように注意する必要があります。

https://www.foobar.com/[clientid]/subscriptions

これの利点は、比較的単純なことです。すべてがアプリケーション内にあり、新しい DNS レコードの追加、ディレクトリやデータベースのアクセス許可の設定などについて心配する必要はありません。

于 2010-03-14T20:59:05.220 に答える