WCF:Per-Call 和 Per-Session 服务……需要说服 Per-Call 是值得的

Question

我们目前正在审查我们的 WCF 服务设计，困扰我的一件事是在 Per-Call 和 Per-Session 服务之间做出决定。我相信我了解两者背后的概念，但我并没有真正看到按调用服务的优势。我知道使用 Per-Call 服务的动机是 WCF 服务只在调用的生命周期内持有一个服务器对象，从而限制了服务实例持有昂贵资源的时间，但对我来说使用起来要简单得多更像 OO 的 Per-Session 模型，其中您的代理对象实例始终对应于相同的服务器对象实例，并且只需手动处理任何昂贵的资源。

例如，假设我有一个带有 Add、Update、Delete 和 Select 方法的 CRUD 服务。这可以作为具有在服务器对象构造函数中实例化的数据库连接(“昂贵的资源”)的 Per-Call 服务来完成。或者，它可以是 Per-Session 服务，在每个公开的 CRUD 方法中实例化和关闭数据库连接。

对我来说，它在资源方面没有什么不同，它使编程模型更简单，因为客户端可以确保它们始终具有相同的代理服务器对象:维护调用之间可能存在的任何廉价状态，并且没有额外的参数当服务再次实例化新的服务器对象时(如 Per-Call 的情况)，需要在方法上识别哪些状态数据必须由服务检索。就像使用类和对象一样，其中存在相同的资源管理问题，但我们不会为对象上的每个方法调用创建新的对象实例!

那么我在 Per-Call 模型中缺少什么？

谢谢

Answer 1

PerCall 或 PerSession 没有对错，只是优点和缺点不同。您似乎是从面向对象的角度出发的，其中 PerSession 是一个自然的选择。典型的 SOA 方法是 PerCall 方法。

在所有条件相同的情况下，权衡是性能与可扩展性。 PerSession 应该表现得更好，因为不必在后续请求中实例化对象。 PerCall 应该可以更好地扩展，因为在服务器上实例化的唯一对象正在执行实际工作。这不仅仅是“昂贵”的资源，而是在服务器上打开的所有 session 。例如在 PerSession 情况下，您可能在服务器上实例化了 1000 个对象，但实际上只有 100 个在任何时候都在调用中。但是，在 PerCall 情况下，对于 100 次调用只会实例化 100 个对象。实例化的 PerSession 对象可能会浪费资源，并可能影响在负载下处理请求的能力。

如果我的服务被公开，我也不愿意相信我的对象生命周期取决于服务消费者的心血来潮；我会担心我的服务可能会被恶意代码或错误代码关闭。

PerCall 方法的另一个潜在好处是系统可用性。回到前面的示例，如果 PerSession 服务器崩溃，那么在该服务器上拥有 session 的所有 1000 个客户端都将丢失其 session 并且无法完成其工作。在 PerCall 情况下，唯一会发生的错误是正在进行的 100 个实际请求(假设快速故障转移)。其他 900 个客户端可以在下一次调用时路由到另一台服务器。这对于 SLA 可能很重要。