かなり単純な WCF ベースのサービスをまとめようとしていますが、それをデータベースから切り離す最善の方法について質問があります。
背景: 私が実装しようとしているサービスは非常に重要で、地理的に分散しており、災害やデータベース障害が発生した場合でも可能な限り利用できる必要があります。ビジネス ロジックは非常に単純です。外部ソースからイベントを受信し、状態テーブルを維持し、処理された更新を接続されたクライアントにブロードキャストします。現在、毎秒 400 ～ 600 件の着信イベントと、約 10 ～ 20 件の同時接続クライアントを処理するサービスを置き換えています。米国内の複数の場所でサービスの複数のインスタンスが実行されます。すべてのインスタンスが同じ状態データをホストし、イベントを共有します。1 つの場所にマスター (SQL Server 2008) データベースのインスタンスが 1 つあります。
課題: 私は過去にこれに似たアプリケーションを数多く構築してきましたが、アーキテクチャ上のハードルのほとんどは私の背後にあります。しかし、私が遭遇した課題が 1 つあります。それに対して、より良い解決策があると想像せずにはいられません。私の設計では、データベース (MSSQL) は永続化のためだけに使用されます。データベースは、サービスの最初のインスタンスが開始されたときとオフライン レポート用にのみ読み取られます。通常の操作中、アプリケーションは履歴データのみを DB に書き込みます。
アプリケーションをデータベースから完全に切り離すために、以前は SQL Service Broker を使用していました。サービスを実行している各サーバーに、コアへの Service Broker メッセージのキューとして機能する SQL Server Express のインスタンスをインストールします ( SSB "ターゲット") データベース。通常の動作条件では、アプリケーションはローカル インスタンスに対してすべての SQL 操作を実行し、SSB を介してそれらをキューに入れ、ターゲット DB に転送します。これは非常にうまく機能し、正直なところ満足しています... SQL Server Express のローカル インスタンスが稼働している限り、アプリケーションは明らかにターゲット DB の問題、データベース間のネットワークの問題を認識しません。対象のDBなどを守り、局地的な災害時でも高い耐用性を発揮します。監視するのは簡単で、設定するのもそれほどひどくはありません。すべてサポートされています。要するに、それは機能し、必要に応じてそれと一緒に暮らすことに満足しています.
しかし、それはちょっとした決まりごとのように私には思えます。それを行うためのより良い方法があるべきだと感じています。
明らかに、1 つのオプションは、処理中のデータベース操作をキューに入れることです。私はそれが好きではありません。なぜなら、物事をまったく分離する場合は、アプリケーション自体を実際に分離して、DB からできるだけ遠ざけることを好むからです。また、これらの操作をキューに入れるデータ サービスを作成することもできます...実際にその道を簡単に歩き始めたのですが、「待って、これは SSB が既に行っていることではないでしょうか?」と考えました。
変更不可能な外部制約があるため、より堅牢な HA SQL Server アーキテクチャは選択肢にありません。私は 1 つの DB クラスターを与えられました。それだけです。
だから私はどんな考えや批判にもオープンです。私が見逃している明らかなものはありますか？これは、私がどういうわけか見落としていた石のように単純なものが存在する可能性のあるもののように感じます (検索不足のためではありませんが)。
前もって感謝します！