Azure Service Fabricでのアプリケーションの設計

Question

新しいAzure Service Fabricテンプレートに合わせてアプリケーションを設計する方法については、どのように考えるべきか、助けが必要です。

今日、私たちはAzure Cloud Services上に構築されたアプリケーションを持っています。このアプリケーションはDDDの周りに構築されており、アプリケーションの異なるサブシステム部分に別々の境界のあるコンテキストがあります。限定されたコンテキストは、今日、単一のWebAPIを使用してこれらのサブシステムを公開する1つのワーカーロールでホストされています。

さらに、Webフロントエンドをホストする1つのWebロールと、バックグラウンドキューを処理する1つのワーカーロールがあります。

マイクロサービスアーキテクチャに移行するよう努めています。私が最初にやろうとしたのは、すべての境界のあるコンテキストを独自のAPIホストに抽出することでした。これにより、サブシステムをサポートする5〜10の新しいWebAPIサービスが実現します。

私の質問では、これらのサブシステム/境界型コンテキスト/ APIホストはすべて、独自のサービスファブリックアプリケーションまたは単一のサービスファブリックアプリケーション内のサービスであるべきですか？

私は何度もここにService Fabric Application Modelたドキュメントを、読んで、私のサービスはに収まるところ、私は理解することはできません。

我々はシステムが異なるサービスのバージョン、およびサービスをサポートしたいです異なるスケールでスケールすることも可能でなければなりません。 1つのマイクロサービスをより大きなVMサイズで実行し、その後は残りのサービスを実行する必要があるかもしれません。

私のニーズに合ったガイドができます。

Answer 1

私はあなたには、一般的には、それぞれの有界コンテキストが（マイクロ）サービスであるという正しい考えがあると思います。サービスファブリックは、アプリケーションとサービスの2つのレベルの組織を提供します。アプリケーションはサービスを論理的にグループ化したものです。それがあなたのために意味するものです：

論理的に言えば、アプリケーションを一貫した機能のセットと考えてください。そのまとまった機能をまとめて形成するサービスは、アプリケーションとしてグループ化する必要があります。それぞれのサービスについて、「他のサービスなしでこのサービスを単独で展開するのは意味がありますか？答えが「いいえ」の場合、おそらく同じアプリケーションでグループ化されるべきです。

発達的に言えば、Visual Studioツールは、1つのアプリケーションで複数のサービスに向いていますが、複数のアプリケーションを1つのソリューションに含めることもできます。

• あなたが複数のサービスタイプを持っている場合は、作成したアプリケーションの各インスタンスは、独自のプロセスを取得します（またはプロセスの設定：

  運用上は、アプリケーションがグループをアップグレードし、プロセス境界を表し、グループのバージョニング、話しますアプリケーション）。サービスタイプのサービスインスタンスは、ホストプロセスを共有します。異なるサービスタイプのサービスインスタンスは、タイプごとに独自のプロセスを取得します。

• アプリケーションは最上位のアップグレード単位です。つまり、アップグレードするたびにアプリケーションがアップグレードされます。アプリケーション内の個々のサービスをアップグレードできます（アプリケーション内のすべてのサービスを必ずしもアップグレードする必要はありません）が、アップグレードするたびにアプリケーションのバージョンが変更されます。
• クラスタ内に同じアプリケーションタイプの異なるバージョンのサイドバイサイドインスタンスを作成できます。アプリケーションインスタンス内で同じサービスタイプの異なるバージョンのサイドバイサイドインスタンスを作成することはできません。

配置と縮尺はサービスで行われます。たとえば、アプリケーション内で1つのサービスを拡張し、別のサービスをより大きなVMに配置することができます。