服务（Service）的本质就是提供服务消费者期望的某种功能，服务的价值体现在两个方面：服务本身的质量和寄宿服务的平台应付消费者的数量，并发（Concurrency）的关注的是第二个要素。WCF服务寄宿于资源有限的环境中，要实现服务效用的最大化，需要考虑如何利用现有的资源实现最大的吞吐量（Throughput）。提高吞吐量就某个寄宿的服务实例（Service Instance）来说，一个重要的途径就是让它能够同时处理来自各个客户端（服务代理）的并发访问。WCF实现了一套完整的并发控制体系，为你提供了不同的并发模式。
我经常说软件架构是一门权衡的艺术，需要综合考虑各种相互矛盾的因素，找到一种最优的组合方式。提高单个服务实例允许的并发访问量能够提高整体吞吐量，这样的理论依赖于一种假设，那就是服务端所能使用的资源是无限。我们知道，这种假设无论在什么情况下都不会成立。如果我们并发量超出了服务端所能承受的临界点，整个服务端将会崩溃。所以，WCF一方面需要允许让单个服务实例并发处理接收到的多个请求，同时也需要设置一道闸门控制并发的数量。WCF的流量限制（Throttling）体系为你创建了这道闸门。
[第1篇] WCF 并发（Concurrency）的本质：同一个服务实例上下文（InstanceContext）同时处理多个服务调用请求
并发的含义就是多个并行的操作同时作用于一个相同的资源或者对象，或者说同一个资源或者对象同时应付多个并行的请求。对于WCF的并发来说，这里将的“资源或者对象”指的就是承载服务操作最终执行的服务实例（Service Instance）。而WCF将服务实例封装在一个称为实例上下文（InstanceContext）对象中，所以WCF中的并发指的是同一个服务实例上下文同时处理多个服务调用请求。
WCF服务端框架一个主要的任务是将接收到的服务调用请求分发给激活的服务实例，调用相应的服务操作并返回执行结果。也就是说，服务操作的执行最终还是会落实到某个具体的服务实例上。《WCF技术剖析（卷1）》的第9章对WCF的实例化机制进行了深入的剖析，从中我们知道在WCF服务端框架体系中，激活的服务实例并不是单独存在的，而是被封装在一个被称为实例上下文（InstanceContext）对象中。WCF提供了三种不同的实例上下模式（Per-Call、Per-Session和 Single）实现了不同的服务实例上下文提供机制。 所以，WCF并发框架体系解决的是如何有效地处理被分发到同一个服务实例上下文的多个服务调用请求，这些并行的调用请求可能来自不同的客户端（服务代理），也可能相同的客户端。
在《WCF 并发的本质》中，我们谈到了WCF提供的三种不同的并发模式，使开发者可以根据具体的情况选择不同的并发处理的策略。对于这三种并发模式，Multiple采用的并行的执行方式，而Single和Reentrant则是采用串行的执行方式。串行执行即同步执行，在WCF并发框架体系中，这样的同步机制是如何实现的呢？
[第3篇]实践重于理论——创建一个监控程序探测WCF的并发处理机制
于WCF的并发是针对某个封装了服务实例的InstanceContext而言的（参考《并发的本质》《并发中的同步》），所以在不同的实例上下文模式下，会表现出不同的并发行为。接下来，我们从具体的实例上下文模式的角度来剖析WCF的并发处理机制，如果对WCF实例上下文模式和实例上下文提供机制不了解的话，请参阅《WCF技术剖析（卷1）》第9章。
为了使读者对采用不同实例上下文对并发的影响有一个深刻的认识，会创建一个简单的WCF应用，并在此基础上添加监控功能，主要监控各种事件的执行时间，比如客户端服务调用的开始和结束时间，服务操作开始执行和结束执行的时间等等。读者可以根据实时输出的监控信息，对WCF的并发处理情况有一个很直观的认识。 [源代码从这里下载]
[第4篇] 并发与实例上下文模式: WCF服务在不同实例上下文模式下具有怎样的并发表现
由于WCF的并发是针对某个封装了服务实例的InstanceContext而言的，所以在不同的实例上下文模式下，会表现出不同的并发行为。接下来，我们从具体的实例上下文模式的角度来剖析WCF的并发，如果对WCF实例上下文模式和实例上下文提供机制不了解的话，请参阅《WCF技术剖析（卷1）》第9章。
在《实践重于理论》一文中，我写一个了简单的WCF应用，通过这个应用我们可以很清楚了监控客户端和服务操作的执行情况下。借此，我们可以和直观地看到服务端对于并发的服务调用请求，到底采用的是并行还是串行的执行方式。接下来，我们将充分地利用这个监控程序，以实例演示加原理分析相结合的方式对不同实例上下文模式下的并发实现机制进行深度剖析。
[第5章] 回调与并发: 通过实例剖析WCF基于ConcurrencyMode.Reentrant模式下的并发控制机制
对于正常的服务调用，从客户端发送到服务端的请求消息最终会被WCF服务运行时分发到相应的封装了服务实例的InstanceContext上。而在回调场景中，我们同样将回调对象封装到InstanceContext对象，并将其封送到客户端。当服务操作过程中执行回调操作的时候，回调消息最终也是分发到位于客户端封装回调对象的InstanceContext。从消息分发与并发处理的机制来看，这两种请求并没有本质的不同。接下来，我们通过《实践重于理论》中的实例，综合分析WCF对并发服务调用和并发回调的处理机制。
[第6篇] ConcurrencyMode.Multiple 模式下的WCF服务就一定是并发执行的吗：探讨同步上下文对并发的影响[上篇][下篇]
《上篇》通过一个具体的实例演示了WCF服务宿主的同步上下文对并发的影响，并简单地介绍了同步上下文是什么东东，以及同步上下文在多线程中的应用。同步上下文在WCF并发体系的内部是如何影响服务操作的执行的呢？这实际上涉及到WCF的一个话题，即线程的亲和性（Thread Affinity），下篇将为你剖析WCF线程亲和机制的本质。
[第7篇] 控制并发访问的三道屏障: WCF限流(Throttling)体系探秘[上篇][下篇]
WCF是一个基于多线程的消息监听、接收和处理框架体系，能够同时应付来自相同或者不同客户端的服务调用请求，并提供完善的同步机制确保状态的一致性。一方面，我们期望WCF服务端能够处理尽可能多的并发请求，但是资源的有限性决定了并发量有一个最大值。如果WCF不控制进入消息处理系统的并发量，试图处理所有抵达的并发请求，一旦超过了这个临界值，整个服务端将会由于资源耗尽而崩溃。
所以，我们需要在WCF的消息接收系统和消息处理系统之间设置一道道屏障，将流入消息处理系统的请求控制到一个最佳的范围，以实现对现有资源的有效利用，从而达到确保服务的可用性和提高整体吞吐量的目的。WCF的流向限制（Throttling）为你设置了这些屏障，你可以根据现有的软硬件环境对该闸门准入的并发流量进行动态的配置。
