c# - 具有共享业务对象的 WCF 每次调用服务

Question

我需要一些帮助来指明正确的方向。

我们希望通过 WebHTTP 端点将服务功能(包括读取和更新 SQL Server 数据库)作为按调用服务提供给用户。如果可以避免，我们不想使用 SOAP，因为我们很难在其他平台上进行互操作。这必须可扩展到 1000 多个用户，在这种情况下，这些用户不太可能提交许多并发请求。据估计，在任何给定时间最多应该有 25 个并发请求。

(这就是为什么要排除按 session 服务的原因，因为这意味着要保持 1000 多个 session 打开，而只执行 25 个操作。)

然而，根据测试服务的经验，我们发现通过 HTTP 使用纯 Per-Call WCF 服务的性能很差，最大的延时是 SQL 服务器连接的初始化。

这有点类似于网络服务器通常会遇到的情况。因此，使用与 Web 服务器类似的方法似乎是明智的——出于性能原因，它们保持 HTTP 引擎池处于事件状态，并且传入请求被分配到池中的引擎之一。

因此，我们希望保持一个包含 25-30 个“业务逻辑对象”(即具有与纯粹服务接口(interface)分离的实际服务逻辑的类)的池，这些对象应该在服务主机启动时实例化。

似乎 WCF 没有内置支持这种开箱即用的方案。我该怎么办？

当我自托管时，我可以从 ServiceHost 派生一个自定义类并添加一个包含业务对象的字典。我猜这会导致线程问题，我必须通过手动同步来处理，对吗？

如果我们决定在 IIS 中托管，那我该怎么做，因为 IIS 会自动负责创建 ServiceHost 类的实例，因此我没有太多机会在​​两者之间使用我自己的自定义主机，我呢？

或者这完全是一种糟糕的方法。任何其他想法表示赞赏。

Answer 1

无状态、无 session 方法实际上是否存在瓶颈？

“业务逻辑对象”池在我看来不是个好主意。您将面临难以调试的并发问题。

您是否实际测试过以下模式？

• 每个请求一个业务逻辑对象，生命周期尽可能短
• 每个业务逻辑对象一个 SQL 连接
• 无状态服务

By experience with a test service, we find however, that using pure Per-Call WCF services over HTTP perform poorly, with the largest time lapse being the initialization of the SQL server connection.

真的，SQL Server 连接不应该因为 SQL Server 连接池而成为瓶颈。