WCF技术剖析之二十三:服务实例(Service Instance)生命周期如何控制[中篇]

简介:

[第1篇]中,我们介绍了WCF关于实例管理一些基本的知识点,包括InstanceContext、InstanceContextMode、已经如何通过ServiceBehaviorAttribute应用不同的实例上下文模式给不同的服务。在[第1篇]中,对WCF采用的三种不同实例上下文模式进行了简单的比较,本篇的重点方法对单调(PerCall)模式为进行详细介绍。

在单调(Per-Call)实例上下文模式下,WCF总是创建一个新的服务实例上下文处理接收到的每一个服务调用请求,并在服务操作执行结束后,回收服务上下文和服务实例。换句话说,单调服务实例上下文模式使服务实例上下文的生命周期与服务调用本身绑定。我们首先来介绍单调模式下服务实例上下文具体有怎样的生命周期。

一、 单调模式下的服务实例上下文提供机制

对于单调模式,服务实例的生命周期大体上可以看成服务操作执行的生命周期。服务实例在服务操作执行前被创建,在操作完成之后被回收。下面的列表揭示了在单调模式下,对于每一次服务调用请求,WCF的整个服务实例激活过程:

  • WCF服务端接收到来自客户端的服务调用请求;
  • 通过实例上下文提供者(InstanceContextProvider)对象试图获取现有服务实例的实例上下文,对于单调模式,返回的实例上下文永远为空;
  • 如果获取实例上下文为空,则通过实例提供者(IntanceProvider)创建服务实例,封装到新创建的实例上下文中;
  • 通过InstanceContext的GetServiceInstance方法获取服务实例对象,借助操作选择器(OperationSelector)选择出相应的服务操作,最后通过操作执行器(OperationInvoker)对象执行相应的操作方法;
  • 操作方法执行完毕后,关闭被卸载InstanceContext对象。在此过程中,会调用InstanceProvider对象释放服务实例,如果服务类型实现了接口IDisposable,则会调用Disposable方法;
  • 服务实例成为垃圾对象,等待GC回收。

对于上述列表中提到的InstanceContextProvider、InstanceProvider等重要的对象,以及相关的实现机制,将在本系列后续的部分进行单独讲解。为了加深读者的理解,这里通过一个简单的例子来演示在单调模式下服务实例的整个激活流程。

二、 实例演示:单调模式下服务实例的生命周期

本案例依然沿用典型的4层结构和计算服务的场景,下面是服务契约和具体服务实现的定义。在CalculatorService类型上,通过ServiceBehaviorAttribute特性将实例上下文模式设为单调(Per-Call)模式。为了演示服务实例的创建、释放和回收,我们分别定义了无参构造函数,终止化器(Finalizer)以及实现的接口IDisposable,并在所有的方法中输出相应的指示性文字,以便更容易地观测到它们执行的先后顺序。

   1: using System.ServiceModel;
   2: namespace Artech.WcfServices.Contracts
   3: {
   4:     [ServiceContract(Namespace="http://www.artech.com/")]
   5:     public interface ICalculator
   6:     {
   7:         [OperationContract]
   8:         double Add(double x, double y);
   9:     }
  10: }
   1: using System;
   2: using System.ServiceModel;
   3: using Artech.WcfServices.Contracts;
   4: namespace Artech.WcfServices.Services
   5: {
   6:     [ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall)]
   7:     public class CalculatorService : ICalculator, IDisposable
   8:     {
   9:         public CalculatorService()
  10:         {
  11:             Console.WriteLine("Service object is instantiated.");
  12:         }
  13:         ~CalculatorService()
  14:         {
  15:             Console.WriteLine("Service object is finalized.");
  16:         }
  17:  
  18:         public void Dispose()
  19:         {
  20:             Console.WriteLine("Service object is disposed.");
  21:         }
  22:         public double Add(double x, double y)
  23:         {
  24:             Console.WriteLine("Operation method is invoked.");
  25:             return x + y;
  26:         }
  27:     }
  28: }

为了演示GC对服务实例的回收,在进行服务寄宿的时候,通过System.Threading.Timer使GC每隔10毫秒强制执行一次垃圾回收。

   1: using System;
   2: using System.ServiceModel;
   3: using System.Threading;
   4: using Artech.WcfServices.Services;
   5: namespace Artech.WcfServices.Hosting
   6: {
   7:     public class Program
   8:     {
   9:         private static Timer GCScheduler;
  10:  
  11:         static void Main(string[] args)
  12:         {
  13:             GCScheduler = new Timer(
  14:                 delegate
  15:                 {
  16:                     GC.Collect();
  17:                 }, null, 0, 100);
  18:             using (ServiceHost serviceHost = new ServiceHost(typeof(CalculatorService)))
  19:             {               
  20:                 serviceHost.Open();                
  21:                 Console.Read();
  22:             }
  23:         }
  24:     }
  25: }

通过一个控制台应用程序对服务进行成功寄宿后,客户端通过下面的代码,使用相同的服务代理对象进行两次服务调用。

   1: using System;
   2: using System.ServiceModel;
   3: using Artech.WcfServices.Contracts;
   4: namespace Artech.WcfServices.Clients
   5: {
   6:     class Program
   7:     {
   8:         static void Main(string[] args)
   9:         {
  10:             using (ChannelFactory<ICalculator> channelFactory = new ChannelFactory<ICalculator>("calculatorservice"))
  11:             {
  12:                 ICalculator calculator = channelFactory.CreateChannel();
  13:                 Console.WriteLine("x + y = {2} when x = {0} and y = {1}", 1, 2, calculator.Add(1, 2));
  14:                 Console.WriteLine("x + y = {2} when x = {0} and y = {1}: {3}", 1, 2, calculator.Add(1, 2));
  15:             }
  16:         }
  17:     }
  18: }

从运行后服务端的输出可以看出,对于两次服务调用请求,服务端先后创建了两个服务实例,在操作方法成功执行后,Dispose方法得以执行。而终止化器(Finalizer)是被GC在后台执行的,所以执行的时机不能确定。不过有一点可以从中得到证实:当服务操作执行时,服务实例变成了“垃圾”对象,并可以被GC回收以腾出占据的内存空间。

Service object is instantiated.
Operation method is invoked.
Service object is disposed.
Service object is instantiated.
Operation method is invoked.
Service object is disposed.
Service object is finalized.
Service object is finalized.

三、 服务实例上下文的释放

如果服务实例须要引用一些非托管资源,比如数据库连接、文件句柄等,须要及时将其释放。在这种情况下,我们可以通过实现IDisposable接口,在Dispose方法中进行相应的资源回收工作。在单调实例上下文模式下,当服务操作执行时,Dispose方法会自动被执行,这一点已经通过上面的案例演示得到证实。

对于实现了IDisposable接口的Dispose方法,有一点值得注意的是:该方法是以与操作方法同步形式执行的。也就是说,服务操作和Dispose方法在相同的线程中执行。认识这一点很重要,因为无论采用怎样的实例模式,在支持会话(Session)的情况下如果服务请求来自于同一个服务代理,服务操作都会在一个线程下执行。对于单调模式就会出现这样的问题:由于Dispose方法同步执行的特性,如果该方法是一个比较耗时的操作,那么来自于同一个服务代理的服务后续调用请求将不能得到及时执行。WCF只能在上一个服务实例被成功释放之后,才能处理来自相同服务代理的下一个服务调用请求。为了让读者体会到同步方式释放服务实例在应用中的影响,并证明同步释放服务实例的现象,我们对上面的案例略加改动。

在CalculatorService中,通过线程休眠的方式模拟耗时的服务实例释放操作(5秒)。在Dispose和Add方法中,除了输出具体操作名称之外,还会输出当前的线程ID和执行的开始时间,代码如下所示。

   1: [ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall)]
   2: public class CalculatorService : ICalculator, IDisposable
   3: {
   4:     public void Dispose()
   5:     {
   6:         Console.WriteLine("Time: {0}; Thread ID: {1}; Service object is disposed.", DateTime.Now, Thread.CurrentThread.ManagedThreadId);
   7:         Thread.Sleep(5000);
   8:     }
   9:     public double Add(double x, double y)
  10:     {
  11:         Console.WriteLine("Time: {0}; Thread ID: {1}; Operation method is invoked.", DateTime.Now, Thread.CurrentThread.ManagedThreadId);
  12:         return x + y;
  13:     }
  14: }

在客户端,我们创建两个不同的服务代理,通过ThreadPool分别对它们进行2次异步调用。下面是相关的服务调用代码。

   1: using (ChannelFactory<ICalculator> channelFactory = new ChannelFactory<ICalculator>("calculatorservice"))
   2: {
   3:     ICalculator calculator = channelFactory.CreateChannel();
   4:     ThreadPool.QueueUserWorkItem(delegate
   5:     {
   6:         Console.WriteLine("{3}: x + y = {2} when x = {0} and y = {1}", 1, 2, calculator.Add(1, 2), DateTime.Now);
   7:     });
   8:     ThreadPool.QueueUserWorkItem(delegate
   9:     {
  10:         Console.WriteLine("{3}: x + y = {2} when x = {0} and y = {1}", 1, 2, calculator.Add(1, 2), DateTime.Now);
  11:     });
  12:     Console.Read();    
  13: } 

从客户端和服务端输出结果的比较,我们可以清晰地看出基于相同服务代理的操作方法和Dispose方法都执行在相同的线程下(线程ID为12),并且两次服务操作的间隔为服务实例释放的时间:5秒。由于服务操作和Dispose方法的同步执行,导致服务端忙于释放上一个服务实例,而不能及时处理来自相同服务代理的下一个服务调用请求。

客户端:

3/6/2009 7:12:34 PM: x + y = 3 when x = 1 and y = 2
3/6/2009 7:12:39 PM: x + y = 3 when x = 1 and y = 2

服务端:

Time: 3/6/2009 7:12:34 PM; Thread ID: 12; Operation method is invoked.
Time: 3/6/2009 7:12:34 PM; Thread ID: 12; Service object is disposed.
Time: 3/6/2009 7:12:39 PM; Thread ID: 12; Operation method is invoked.
Time: 3/6/2009 7:12:39 PM; Thread ID: 12; Service object is disposed.

关于服务实例的同步执行机制,还有一点需要说明是,在Dispose方法中,可以得到当前OperationContext,而OperationContext在会话(Per-Session)实例上下文模式下是不可得的。

四、单调模式与可扩展性

在单调模式下,如果不考虑GC对垃圾对象回收的滞后性,服务实例的数量可以看成是当前正在处理的服务调用请求的数量。相关的资源能够在服务操作执行完毕之后得到及时回收(通过实现IDisposable接口,将资源回收操作实现在Dispose方法中)。所以,单调模式具有的优势是能够最大限度地发挥资源的利用效率,避免了资源的闲置和相互争用。

这里的资源不仅仅包括服务实例本事占据的内存资源,也包括服务实例直接或间接引用的资源。由于单调模式采用基于服务调用的服务实例激活和资源分配方式,所以服务实例或被分配的资源自始至终都处于“工作”状态,不会造成资源的闲置。服务实例在完成其使命之后,能够对资源进行及时的释放,被释放的资源可以及时用于对其他服务请求的处理。

我们将单调模式和后面要讲的会话模式作一个对比,后者采用基于服务代理的实例激活和生命周期管理。也就是说,在不考虑WCF闲置请求策略(当服务实例在超出某个时间段没有被使用的情况下,WCF将其清理)的情况下,服务实例的生命始于通过服务实例进行第一次服务调用,或者调用Open方法开启服务代理之时,服务代理的关闭会通知WCF服务端框架将对应的服务实例进行释放。举一个极端的例子,服务实例在存续期间需要引用一个非托管资源,比如是数据库连接,假设最大允许的并发连接为100。现在,先后100个客户端(或者服务代理)进行服务调用请求,毫无疑问,100个服务实例会被创建并同时存在于服务端的内存之中,并且每一个服务实例引用一个开启状态的数据库连接,那么当来自第101个客户端服务调用请求抵达时,将得不到处理,除非在它的超时时限到达之前,有一个客户端自动将服务代理关闭。

但是,对于相同的场景,如果采用单调的模式,就能应付自如,因为在每次服务调用之后,数据库的连接可以及时地得到关闭和释放。

对于单调模式,很多读者一开始就会心存这样的疑问:服务实例的频繁创建,对性能不会造成影响吗?在前一章中,我们就说过:高性能(Performance)和高可扩展性(Scalability)是软件设计与架构中永远不可以同时兼顾的,原因很简单,高性能往往需要充足的资源,高扩展性又需要尽可能地节约资源。所以我们才说,软件设计与架构是一项“权衡”的艺术,我们的目的不是将各个方面都达到最优,因为这是不可能实现的任务,我们须要做的只是找到一个平衡点使整体最优。关于高扩展性和性能之间的平衡关系,我们很难有一个适合所有场景的黄金法则,这需要对具体场景的具体分析。

较之会话模式,单调模式能够处理更多的并发客户端,提供更好的吞吐量(Throughput)。对于量化我们的服务到底能够处理多少客户端,Juval Lowy在其著作《Programming WCF》中提出了这样一项经验性总结:在一个典型的企业应用中,并发量大概是所有客户端数量的1%(高并发情况下能达到3%),也就是如果服务端能够同时维持100个服务实例,那么意味着能为10 000个客户端提供服务。

关于服务实例的创建过程,其中会使用到诸如反射这样的相对影响性能的操作,但是在WCF应用中,真正影响性能是操作时信道的创建和释放。服务实例的激活和它们比起来,可以说是微不足道。但是,如果在应用中出现对基于相同服务代理的频繁调用,比如服务调用放在一个For循环中调用上百次,服务实例的创建带来的性能损失就不能不考虑了。


作者:蒋金楠 
微信公众账号:大内老A
微博: www.weibo.com/artech
如果你想及时得到个人撰写文章以及著作的消息推送,或者想看看个人推荐的技术资料,可以扫描左边二维码(或者长按识别二维码)关注个人公众号(原来公众帐号 蒋金楠的自媒体将会停用)。
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。
相关文章
|
11月前
|
前端开发
WCF更新服务引用报错的原因之一
WCF更新服务引用报错的原因之一
|
8月前
|
Oracle 关系型数据库 API
C# LIS检验系统源码,接口技术:RESTful API + Http+WCF
LIS检验系统一种专门用于医院化验室的计算机系统,它致力于提高医院化验室的工作效率和检测准确率。LIS系统由多个子系统组成,包括样本管理系统、质控系统、检验结果管理系统、报告管理系统等。体系结构:Client/Server架构 SaaS模式 客户端:WPF+Windows Forms 服务端:C# +.Net 数据库:Oracle 接口技术:RESTful API + Http+WCF
|
10月前
|
C# 数据安全/隐私保护
c#如何创建WCF服务到发布(SqlServer版已经验证)
c#如何创建WCF服务到发布(SqlServer版已经验证)
40 0
|
10月前
|
安全 数据库连接 数据库
WCF服务创建到发布(SqlServer版)
在本示例开始之前,让我们先来了解一下什么是wcf? wcf有哪些特点? wcf是一个面向服务编程的综合分层架构。该架构的项层为服务模型层。 使用户用最少的时间和精力建立自己的软件产品和外界通信的模型。它使得开发者能够建立一个跨平台的安全、可信赖、事务性的解决方案。且能与已有系统兼容写作。 简单概括就是:一组数据通信的应用程序开发接口。
67 0
|
11月前
Visual Studio 2022 创建 WCF服务 找不到
Visual Studio 2022 创建 WCF服务 找不到
|
C++
WCF基础教程(二)——解析iis8和iis8.5+VS2013发布wcf服务问题
WCF基础教程(二)——解析iis8和iis8.5+VS2013发布wcf服务问题
107 0
WCF基础教程(二)——解析iis8和iis8.5+VS2013发布wcf服务问题
WCF使用纯代码的方式进行服务寄宿
服务寄宿的目的是为了开启一个进程,为WCF服务提供一个运行的环境。通过为服务添加一个或者多个终结点,使之暴露给潜在的服务消费,服务消费者通过匹配的终结点对该服务进行调用,除去上面的两种寄宿方式,还可以以纯代码的方式实现服务的寄宿工作。
864 0
|
Windows
WCF服务寄宿到IIS
一.WCF简介: Windows Communication Foundation(WCF)是由微软开发的一系列支持数据通信的应用程序框架,可以翻译为Windows 通讯开发平台。整合了原有的windows通讯的 .net Remoting,WebService,Socket的机制,并融合有HTTP和FTP的相关技术。
1057 0
WCF服务自我寄宿
WCF服务的寄宿方式 WCF寄宿方式是一种非常灵活的操作,可以寄宿在各种进程之中,常见的寄宿有: IIS服务、Windows服务、Winform程序、控制台程序中进行寄宿,从而实现WCF服务的运行,为调用者方便、高效提供服务调用。
1002 0
|
C#
C#面向服务编程技术WCF从入门到实战演练
一、WCF课程介绍 1.1、Web Service会被WCF取代吗? 对于这个问题阿笨的回答是:两者在功能特性上却是有新旧之分,但是对于特定的系统,适合自己的就是最好的。不能哪一个技术框架和行业标准作比较,任何对于二者的比较都是错误的,因为两者根不不在同一个范畴里。
1361 0