2

私は、単一のインスタンスに対して手動で構成およびデプロイできる meteor.js アプリケーションを持っています。

ここで、アプリケーションのアーキテクチャをリファクタリングし、アプリケーションの周りにインフラストラクチャを構築して、アプリケーションをクライアントにデプロイして更新できるようにします。

クライアントがアプリにサインアップできるページにアクセスしてもらいたいのですが、インスタンスまたはテナンシーが自動的にセットアップされ、使用を開始できます。バックエンドには、アプリケーションの更新を管理するためのインフラストラクチャがあります。

行う必要があるいくつかの明白な決定があります。

  • マルチテナントになるようにリファクタリングしますか? (より多くのアプリケーション コードの変更)
  • マルチインスタンスになるようにリファクタリングしますか? (より多くのインフラストラクチャの構築とコード)
  • ハイブリッドですか？(アプリケーションは 1 つ、データベースは複数)

上記の質問に対する正しい答えを決定するために、どのようなテストを適用しますか? それぞれの長所と短所は何ですか？

その決定が下されたら、適切なリファクタリングをガイドまたは刺激する設計パターンは存在しますか? また、マルチテナントまたはマルチインスタンス アプリを構築したことがない人向けに、どのような学習リソースが存在しますか?

そのマルチインスタンス化は、インスタンス化と更新をアプリケーション自体の一部にする必要がありますか、それともその部分を管理するために構築する必要があるコードとツールの別のレイヤーがありますか?

4

1 に答える 1

3

ここで 3 つの質問を数えますが、それらを別のスレッドに分割することをお勧めします。とにかく：

1) 正しいアーキテクチャを決定するためのテストは何ですか? さて、各アーキテクチャをサポートするのにどれくらいの費用がかかるのか、それぞれをどれだけ迅速に実装できるのか、そして待っている顧客が何人いるのかを比較してみましょう。率直に言って、おそらくあなたはおそらくすでに好みを持っているので、それを脇に置いても構わないと思っているのでなければ、私がここで与える答えは意味がありません. これがビジネスの場合は、収益のルールを覚えておいてください。最も美しくエレガントなアーキテクチャでさえ、収益がなければ重要ではありません。収益があれば、ほとんどのアーキテクチャの誤りを時間内に修正できます。

2) マルチテナントの埋め込み可能なアプリケーションに適した設計パターンは? 設計パターンが正しい答えかどうかはわかりませんが、むしろデータ管理とテストの厳密さです。ここでの目標は、たとえ 1 人の個人がクライアント A とクライアント B の両方のユーザーであったとしても、クライアント A の顧客がクライアント B の顧客データのヒントを得ないようにすることです。API キーとセッション キーの管理には細心の注意を払う必要があります。その日。

3) アプリでのインスタンス管理か、それとも別のツールか? 現在のアプリケーションとインフラストラクチャを分析せずに、この質問に満足のいく答えを出せる人はいないでしょう。おそらく、ほとんど自己展開型のアプリケーションを使用していて、新しい DB をセットアップしたり、新しい AWS インスタンスを起動したりするのに数行追加するだけで済みます... あるいは、高度な手動プロセスを使用しているかもしれません。これは、質問 1 で選択したアーキテクチャや、どれだけの時間があるかによっても影響を受ける可能性があります。質問 1 の収益に関するメモを参照してください。

于 2013-08-05T03:13:24.327 に答える