使用SQL服务代理将服务与数据库解耦

我正在考虑将一个相当直接的基于wcf的服务放在一起，我有一个关于如何最好地将它与数据库解耦的问题。

Background:我将要实现的服务是高度关键的，地理分布的，并且需要在灾难或数据库故障时尽可能可用。业务逻辑非常简单;它从外部源接收事件，维护状态表，并将处理后的更新广播到已连接的客户端。我正在替换一个服务，它目前每秒处理400-600个传入事件，以及大约10-20个并发连接的客户端。该服务将在美国多个地点运行多个实例。所有实例托管相同的状态数据并共享事件。在一个地方有一个主数据库(SQL Server 2008)的实例

挑战:我过去已经构建了许多类似的应用程序，并且我已经克服了大多数架构障碍。但是我遇到了一个挑战，我忍不住想象有一个更好的解决方案:在我的设计中，数据库(MSSQL)只使用进行持久化;只有在服务的第一个实例启动和离线报告时才读取数据库。在正常操作期间，应用程序只向DB写入历史数据。

为了将应用程序与数据库完全解耦，过去我使用了SQL Service Broker:在运行服务的每个服务器上，我安装了一个SQL server Express实例，它本质上只是充当Service Broker消息到核心(SSB"目标")数据库的队列。在正常操作条件下，应用程序对本地实例执行所有SQL操作，本地实例通过SSB将它们排队/转发到目标DB。这很有效，老实说，我对此相当满意……只要SQL Server Express的本地实例启动，应用程序显然就不会意识到目标DB上的问题、它与目标DB之间的网络问题等，并且在发生局部灾难的情况下，它具有很高的生存能力。它很容易监控，设置起来也不会太难看，而且都得到了支持。简而言之，它是有效的，如果我不得不这样做，我也很满意。

但它给我的印象是有点拼凑。我觉得应该有更好的方法。

显然，一种选择是将正在处理的数据库操作排队。我不喜欢那样，因为如果我要解耦，我更喜欢真正解耦，让我的应用程序本身尽可能远离DB。我还可以编写一个数据服务来对这些操作进行排队…实际上，在我想"等等，这不是SSB已经在做的吗?"之前，我曾短暂地沿着这条路走下去。

由于不可改变的外部约束，一个更健壮的/HA SQL Server架构不是一个选择。我已经得到了我的一个DB集群，就是这样。

所以我愿意接受任何想法和/或批评。有什么明显的东西我没注意到吗?这感觉就像有一些石头一样简单的东西，我只是不知何故忽略了(尽管不是因为缺乏搜索)。我是不是在建筑学上犯了更大的错误?

提前感谢!