我正在考虑整合一个相当直接的基于WCF的服务，我有一个关于如何最好地将其与数据库分离的问题。
背景：我将要实施的服务非常关键，地理位置分散，并且需要尽可能通过灾难或数据库故障提供服务。业务逻辑非常简单;它从外部源接收事件，维护状态表，并向已连接的客户端广播已处理的更新。我正在更换目前每秒处理400-600个传入事件的服务，以及大约10-20个并发连接的客户端。将在美国的多个位置运行多个服务实例。所有实例都托管相同的状态数据并共享事件。在一个位置有一个主（SQL Server 2008）数据库实例。
挑战：我过去已经构建了许多类似的应用程序，而且我背后的大部分架构障碍都在我身后。但是我遇到了一个挑战，我不禁想象有一个更好的解决方案：在我的设计中，数据库（MSSQL）仅用 来实现持久性;只有在服务的第一个实例启动和脱机报告时才会读取数据库。在正常操作期间，应用程序仅将历史数据写入DB。
为了将应用程序与数据库完全分离，过去我使用过SQL Service Broker：在运行该服务的每台服务器上，我安装一个SQL Server Express实例，它实际上只是作为Service Broker消息的队列。核心（SSB“目标”）数据库。在正常操作条件下，应用程序针对本地实例执行所有SQL操作，本地实例通过SSB将它们排队/转发到目标数据库。这很好用，说实话我对它很满意......只要SQL Server Express的本地实例启动，应用程序显然会不知道目标数据库的问题，它与它之间的网络问题目标数据库等，在本地化灾难的情况下，它具有很高的生存能力。它很容易监控，设置起来也不会太难看，而且它都受到了支持。简而言之，它是有效的，如果必须的话，我很满足于它。
但它让我感觉像是一个混乱。感觉应该有更好的方法来做到这一点。
显然，一种选择就是将正在进行的数据库操作排队。我不喜欢这样，因为如果我要解耦一些东西，我宁愿真正解耦并保持我的应用程序本身尽可能远离数据库。我还可以编写一个对这些操作进行排队的数据服务......我实际上是在对自己进行思考之前简要地开始了这条道路，“等等，这不是SSB已经做的了吗？”
由于不可更改的外部约束，不能选择更健壮的HA SQL Server体系结构。我得到了我的一个数据库集群，就是这样。
所以我对任何想法和/或批评持开放态度。有什么明显的东西我不见了吗？这感觉就像那种可能有某种东西的东西 - 简单的我只是被忽略了（虽然不是因为缺乏搜索。）我在这里犯了一些更广泛的建筑错误吗？
提前致谢！
答案 0 :(得分：4)
我的观点显然是有偏见的，但是对于记录我可以指出几个相当大的项目（或者做过），例如High volumn contiguos real Time ETL，March Madness on Demand或MySpace SQL Server Service Broker 。
但是后来几年发生了一些变化，主要的变化是PaaS产品的兴起。今天，您可以拥有一个高度可用，可扩展的数据库和消息平台，例如。 SQL Azure和Azure Queues/Azure Service Buss。如果您愿意走出SQL / ACID，请DynamoDB和SQS。可以说，SQL Express实例推向中央SQL Server标准版的价格点将低于PaaS解决方案，但在可用性，免费维护和按需扩展方面难以击败PaaS。
除了上面提到的PaaS之外，我认为你所拥有的解决方案优于MS堆栈的其他任何东西。 WCF肯定很容易编程，除非你有反SOAP热，但在可用性/可靠性方面基本上提供0（零）。您的流程已经消失===您的数据已经消失，故事结束。 MSMQ上的WCf只是名义上的“WCF”，队列通道的编程模型距离http / net绑定WCF编程模型几英里远。而MSMQ几乎没有能够再次站起来的服务经纪人（除了无处不在）。但是，你可能知道，在我看来，我真的有偏见......