.net - 非常简单的企业应用程序架构 - 使其可扩展

Question

我正在为我的一个内部网企业应用程序使用一个非常简单的架构。

客户:

在每台计算机上运行 1 个代理发送系统配置数据(一次)，报告(每 2 到 5 分钟)=> 从客户端流向服务器的数据大小为几百字节，很少触及 1 KB。

服务器:

1 个 Web 应用程序(用于管理客户端、查看报告的前端)

接收所有传入数据的 Web 服务(它只是将其转储到表中)

每隔几秒钟读取转储并执行相关查询的系统服务 - 插入，更新用于报告的实际表(此步骤可能与 ETL 相比)

由于成千上万的客户端同时向服务器发送数据，服务器只需将这些传入数据转储到临时表中(每个客户端发送数据时插入一次)。在后台运行的系统服务不断刷新这个临时表 - 从某种意义上说 - 每 10 秒，它从转储表中读取前 100 行，将这些数据组织到用于报告的相关表中，并从转储中删除这 100 行等等。

到目前为止，我已经在 2,000 台计算机的网络中运行了我的应用程序，它似乎运行良好。现在我需要扩展它以支持 25,000 个客户端的网络。我将以每秒 25,000 个请求运行模拟测试，并检查架构是否良好。

服务器基于 .NET。 ASP .NET Web 应用程序 - 前端，用于转储数据的 Web 服务。基于 .NET 的系统服务来执行 ETL。 SQL Server 2005/2008 作为数据库服务器。

希望能从 stackoverflow 社区得到一些 build 性的批评和指导，以改进这个架构。您认为使用单个服务器处理 25,000 个客户端的方式是否足够好？您认为随着并发事件的增加，最有可能崩溃的组件是什么？是否存在根本性缺陷？欢迎各种指导。谢谢。

Answer 1

均匀分布，“最坏的情况”是 12500 次/分钟，即每秒 209 次。

您可能最好做的是对前端进行负载平衡。

如果您有 4 台机器，则每台机器上每秒传输 52 次。每台机器都在本地存储他们的 trans 数据，然后批量插入到后端的最终数据库中。这使主数据库上的传输量保持在较低水平。插入 1 行和 50 行(取决于行大小)之间的差异非常小。在某些时候，它是“相同的”，具体取决于网络开销等。

所以，如果我们四舍五入到 50(为了简单的数学计算)，前端机器每 5 秒就会向后端数据库插入 250 行。这不是一个低音量(再次取决于行大小)。

您提到在后端每个进程轮询 100 个记录。无论您在这里使用什么数字，再加上处理时间，都需要小于您的总流量和所需的完成时间。

具体来说，后端处理在短期内比前端插入速度慢是可以的，只要从长远来看，您的后端会 catch 。例如，也许您的大部分流量是从上午 8 点到下午 5 点，但所有所说和完成的后端处理都将在晚上 9 点之前 catch 。

否则，后端永远赶不上，你总是落后，而且积压工作只会越来越大。所以你需要确保你也能正确处理。

如果您的报告查询很昂贵，最好也卸载它们。让前端机器将原始数据发送到单个中间层机器，然后让第三台机器将大量(可能是每天)批量导出到本地报告数据库以进行数据库查询。

此外，请考虑故障和可用性场景(即，如果您丢失了一台负载平衡的前端机器，您是否仍能跟上流量等)。这里有很大的失败空间。

最后，作为一项规则，更新往往比删除更便宜，因此如果您可以在停机时间而不是在主流处理期间进行删除，那么如果您需要，您可能会在那里找到一些性能。