WCF：每次通话和每次会话服务…需要让人相信每次通话都是值得的

我们目前正在审查我们的WCF服务设计，困扰我的一件事是每次呼叫和每次会话服务之间的决定。我相信我理解这两者背后的概念，但我并没有真正看到每次通话服务的优势。我理解使用每次呼叫服务的动机是，WCF服务仅在呼叫生命周期内保留服务器对象，从而限制服务实例保留昂贵资源的时间，但对我来说，使用更像OO的每会话模型要简单得多，在这种模型中，代理对象实例总是对同一个服务器对象实例进行响应，并且只需手动处理任何昂贵的资源

例如，假设我有一个CRUD服务，上面有Add、Update、Delete和Select方法。这可以通过在服务器对象构造函数中实例化数据库连接（“昂贵的资源”）的每次调用服务来完成。或者，它可以是每会话服务，在每个公开的CRUD方法中实例化并关闭数据库连接

对我来说，这在资源方面并没有什么不同，它使编程模型变得更简单，因为可以确保客户机的代理始终具有相同的服务器对象：在调用之间可能存在的任何昂贵状态都会得到维护，并且在方法上不需要额外的参数来确定客户端必须检索哪些状态数据再次实例化新服务器对象时的服务（如每次调用的情况）。这就像使用类和对象一样，同样的资源管理问题也适用于这些类和对象，但我们不会为对象上的每个方法调用创建新的对象实例

那么，我在每次通话模式中遗漏了什么

---

谢谢

简而言之，答案是无状态和可伸缩性

如果您知道服务将如何使用的环境，并且您可以共享资源，从而使服务有状态，那么每个会话都可以很好地工作。当您需要引入故障保护服务器、负载平衡和路由服务调用时，会话服务将出现问题，因为调用并不总是解析到同一个服务对象。此外，如果该服务由工作流不固定的客户端使用，您如何知道何时为该会话释放服务对象？大多数时候，您依赖于租约超时，但在高负载环境中，这本身也会造成在内存中创建对象和空闲的问题

---

在设计方面，使服务调用相互独立也是一种很好的做法。因此，您不需要依赖以前的服务调用来设置对象的状态

在理解和坚持上没有对错，只有不同的优点和缺点。从面向对象的角度来看，PerSession是一种自然的选择。典型的SOA方法是PerCall方法

在所有条件相同的情况下，性能与可伸缩性是一个权衡。PerSession的性能应该更好，因为对象不必在后续请求中实例化。PerCall应该扩展得更好，因为只有在服务器上实例化的对象才能执行实际工作。这不仅仅是“昂贵”的资源，还包括服务器上打开的所有会话。e、 在PerSession情况下，您可能在服务器上实例化了1000个对象，但在任何时候实际调用的对象只有100个。但是，在PerCall情况下，对于100个调用，只有100个对象被实例化。实例化PerSession对象可能会浪费资源，并可能影响在负载下为请求提供服务的能力

如果我的服务是公开的，我也不愿意相信我的对象生命周期是服务消费者一时兴起的；我会担心我的服务可能会被恶意代码或错误代码破坏

---

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

我对负载平衡和路由不太了解，但在不知道客户端如何使用代理的情况下，我的相同论点也适用：对服务器对象进行编码，使其不保留昂贵的资源，这样，客户端不关闭代理就无关紧要了。此外，这似乎与我在Juval Lowys WCF一书中读到的内容不一致，书中说“如果每次呼叫服务是真正无状态的，那么就不需要每次呼叫。这是因为该服务声明您需要每次呼叫模式。”除了负载平衡/路由，我仍然看不出有什么区别。这种区别在可伸缩性上更为突出，但如果没有考虑到这一点，那么我同意你上面的评论。在高负载服务器上，假设您的服务在5分钟内从不同的客户端调用了10k次，在每会话配置中，主机需要保持此10k会话对象处于活动状态，并为其租约状态进行池化。这显然会增加服务器的内存和性能开销。