3

我正在寻找一个相当直接的基于 WCF 的服务，我有一个关于如何最好地将它与数据库分离的问题。

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

挑战：过去我已经构建了许多与此类似的应用程序，并且我已经克服了大部分架构障碍。但是我遇到了一个挑战，我不禁想象有一个更好的解决方案：在我的设计中，数据库（MSSQL）仅用于持久性；只有在服务的第一个实例启动和离线报告时才会读取数据库。在正常操作期间，应用程序只会将历史数据写入数据库。

为了将应用程序与数据库完全分离，过去我使用过 SQL Service Broker：在每个运行该服务的服务器上，我安装了一个 SQL Server Express 实例，该实例基本上只是充当 Service Broker 消息到核心的队列（ SSB“目标”）数据库。在正常操作条件下，应用程序对本地实例执行所有 SQL 操作，本地实例通过 SSB 将它们排队/转发到目标数据库。这工作得很好，老实说，我对它相当满意......只要 SQL Server Express 的本地实例启动，应用程序显然不会意识到目标数据库的问题，它和它之间的网络问题目标数据库等，并且在局部灾难的情况下具有很高的生存能力。它很容易监控，设置起来也不会太难看，而且它' 都支持。简而言之，它有效，如果必须的话，我很乐意接受它。

但这让我觉得有点杂乱无章。感觉应该有更好的方法来做到这一点。

显然，一种选择是仅将正在进行的数据库操作排队。我不喜欢这样，因为如果我要完全解耦，我更愿意真正解耦并使我的应用程序本身尽可能远离数据库。我还可以编写一个数据服务来对这些操作进行排队……实际上，我在思考自己之前曾短暂地沿着这条路走下去，“等等，这不是 SSB 已经在做的吗？”

由于不可更改的外部约束，更健壮/HA SQL Server 体系结构不是一个选项。我已经获得了我的一个数据库集群，仅此而已。

所以我对任何想法和/或批评持开放态度。我有什么明显的遗漏吗？这感觉就像是我只是以某种方式忽略了一些简单的东西（尽管不是因为缺乏搜索）。我在这里犯了某种更广泛的架构错误吗？

提前致谢！

4

1 回答 1

4

我的观点显然是有偏见的，但为了记录，我可以指出几个相当大的项目，它们以相同的方式进行（或做过），例如High volumn contiguos real Time ETL、March Madness on Demand或MySpace SQL Server Service Broker。

但后来几年发生了一些变化，主要变化是 PaaS 产品的兴起。今天，您可以拥有一个高度可用、可扩展的数据库和消息传递平台，例如。SQL Azure和Azure 队列/Azure 服务总线。或者DynamoDB和SQS，如果您愿意跳出 SQL/ACID。可以说，将 SQL Express 实例推送到中央 SQL Server 标准版的价格点将低于 PaaS 解决方案，但在可用性、免费维护和按需扩展方面很难击败 PaaS。

因此，除了上面的 PaaS 观点之外，我认为您拥有的解决方案几乎优于 MS 堆栈所拥有的任何其他解决方案。WCF 肯定很容易编程，除非您有反 SOAP 狂热，但在可用性/可靠性方面基本上可以提供 0（零）。您的流程消失了===您的数据消失了，故事结束。MSMQ 上的 WCf 只是名义上的“WCF”，队列通道的编程模型与 http/net 绑定 WCF 编程模型相去甚远。并且 MSMQ 几乎无法与 Service Broker 抗衡（除了无处不在）。但话又说回来，你可能知道，我的观点真的有偏见......

于 2013-03-08T19:48:13.347 回答