キューを使用してスケーラブルなソリューションを設計する
次のシナリオを想定しています。
ユーザーから入力を受け取り、5〜25分（入力に応じて）かかるアルゴリズムを介して入力を処理し、異なる結果を提供するWebアプリケーション。つまり、ユーザーがUIの背後で結果を待つことはなく、計算が完了するとメールで通知されます。
- 入力を処理するアルゴリズム部分はスケーラブルでなければなりません。
- アプリケーションはオンプレミスでホストする必要があります。
- 有料ユーザーからのリクエストはキューの先頭にある必要があります。
私は高レベルのアーキテクチャを設計しようとしており、スケーラブルなソフトウェア、コンテナ、マイクロサービスの世界で初めてです。
これは私がこれまでに持ってきた大まかな基本設計です： 
上：
- フロントエンドアプリは、ユーザー入力の受信を担当します。 （当面はスケーラブルである必要はありません）、メッセージングサーバーに要求を発行します。
- メッセージングサーバーは、RabbitMQなどのソフトウェアをホストするサーバーです。
- 「キューマネージャー」は、メッセージにサブスクライブされ、アルゴリズムランナーの未割り当てインスタンスが使用可能な場合にリクエストを割り当てる、開発が必要なソフトウェアです。また、ユーザーがサブスクライブしているプランによっては、キューの順序にも責任があるため、有料ユーザーのリクエストが優先されます。
- アルゴリズムランナーインスタンスはコンテナー（Dockerなど）の内部にあり、インスタンスの数を増やすことで拡大できます。
これが私の質問です。
このアーキテクチャ/デザインはまったく意味がありますか？それはやり過ぎではありませんか、逆に言えば、それは単純すぎるかもしれませんか？
私の最大の疑問は、キューマネージャーアプリがまったく必要か、またはコンテナーがメッセージを直接サブスクライブできるようにする必要があるかです。その場合、優先順位付けはどのように機能しますか？
コメントは1つだけ-個人的にはキューマネージャーサービスを保持します。
might「ワーカー」コンテナがアルゴリズムタスクを実行するためにメッセージ自体をサブスクライブすることは可能ですが、いくつかの機能を実装することは非効率的/困難/不可能です（IMHOは遅かれ早かれそれを行います） 「必要」）コードを「ワーカー」コンテキストで実行することから：
- システム/サービスの動的/グローバルなビューを提供する
- 優先順位スケジューリングの実行
- ワーカーコンテナーの監視と障害/回復ロジックの実行
- 必要に応じてコンテナーを上下に移動する/ワーカーコンテナープールをスケーリングする
- サービス全体を拡大する
専用の集中キューマネージャーを使用すると、上記の項目を実装するためのIMHOがはるかに簡単になります。
- サービスの集中/グローバルビューがすでにある
- 一元化されたジョブスケジューリングの決定を所有し、優先順位または同様のサービス品質ロジックを実装することはほとんど簡単です
- これは、ジョブを実行するワーカーコンテナーのステータスを監視する中心的なエンティティであり、障害を簡単に検出できます。別のマイクロサービスとして引き出すことができます。
- スケジューリングの決定に使用されるサービス情報は、スケジューリングアクティビティから取得されるサービスステータス情報によって補完され、通常、作業コンテナプールのスケーリングの決定に必要な情報のほんの一部です。 Queue Manager自体がそれらの決定の実行を駆動するか、またはそのための専用の別のサービスにトリガーを提供することができます。
- システムのスケーリングでは、通常、ワーカーコンテナーのスケーリングは必要ありません（キューマネージャー機能を実行する場合に必要です）。