これは適切なアーキテクチャですか、それとも改善できますか？
ビジネス/企業の要件と私たちの建築家の好みの組み合わせにより、私には少し離れているように見える特定のアーキテクチャにたどり着きましたが、私は非常に限られた建築知識しかなく、クラウド知識がさらに少ないため、確認するための健全性チェックが大好きですここで行うことができる改善がある場合： 背景：ゼロから完全に書き直した既存のシステムの代替品を開発しています。これには、BAPI / SOAP Webサービスを介してSAPインスタンスからデータを調達し、SAPにないデータ用に独自のデータベースを使用する必要があります。現在、管理対象のすべてのデータは、分散アプリケーションのローカルDB、または移行元のMySQLデータベースに存在します。既存の分散アプリの機能を複製する一握りのWebアプリケーションを作成し、管理するデータに対して管理関連の機能を提供する必要があります。 ビジネス/エンタープライズ要件： 私たちが管理するデータベースは、MS SQL Serverに実装する必要があります 作成するデータベースの数を最小限に抑える フェーズ1では、アプリケーションをAzureにデプロイしますが、将来的にはこれらのアプリケーションをオンプレミスにする機能が必要です 運用チームは、コードの管理が大幅に簡単になると感じているため、すべてをドッキングすることを望んでいます。 データの複製を最小化/排除 コーディングスタックは、マイクロサービスと管理アプリの場合は.NET Coreになりますが、メインのフロントエンドアプリケーションの場合はAngular 5になります。 これらの要件から、私たちの建築家はこの設計を思いつきました： 私たちのフロントエンドは、一連のマイクロサービス（「ドメイン」レベルでかなり大きいため、この用語を軽く使用します）からフィードし、各ドメインで読み取りサービスと書き込みサービスに分割されます。どちらもスケーラブルで、Kubernetesを通じて負荷分散されます。それぞれには、データベース内の読み取り専用のコピーがコンテナ内にアタッチされており、読み取り専用コピーへの更新をプッシュする書き込みに使用できるdbの単一のマスターインスタンスがあります。 （低品質の画像については申し訳ありませんが、当然、建築家の頭を除いて、これに関する実際のドキュメントがないため、メモリからやり直しています。） サービス間の通信は、各サービスがリッスンし、関連するメッセージを処理するメッセージキューを介して行われます。情報のために通信を提供するためのサービスを必要とするものはまだ特定されていないため、これの主な用途は電子メールの生成です。複数のサービスの関与を必要とする「ビジネスロジック」に関連するものは、フロントエンドから流れる可能性が高く、フロントエンドは各サービスを個別に呼び出し、原子性を扱います。 私の見解では、間違った方法でこすりつけているのは、読み取り専用のdbインスタンスがサービスのDockerコンテナー内でスピンアップしていることです。サービス自体とdbは、負荷の点で要求が大幅に異なるため、それらを個別に負荷分散できれば、はるかに理にかなっています。MYSQLには、マスター/スレーブ構成でそれを行う方法があると思います。この場合、負荷が高くなるたびに新しいスレーブを起動できます。特に、システムがクラウドにあり、インスタンスごとに支払いを行っている場合、別のdbインスタンスのみが必要なときにサービス全体の新しいインスタンスをスピンアップすると無駄になります（反対に、実際にちょうど新しいデータベースコピーをスピンアップすると、 Webサービスインスタンスが必要です）。ただし、これに対するMS SQL Serverの制限はわかりません。 私の最大の懸念は、MS SQL Serverの実装に関するものです。読み取り専用インスタンスをサービスに非常に密に結合すると、気分が悪くなります。これを行うより良い方法はありますか？ 注：私はソフトウェアエンジニアリングについてこれを尋ねると、ここで私を指摘しました。これが適切なSEではない場合は、申し訳ありません。 また、MS SQL Serverタグはありません