构建高性能.NET应用之配置高可用IIS服务器

cyc1111

系列文章：
构建高性能.NET应用之配置高可用IIS服务器-第一篇：IIS必须掌握的知识
构建高性能.NET应用之配置高可用IIS服务器-第二篇 IIS请求处理模型

       今天的文章的比较的容易，主要讲述IIS中三个比较重要的组件：协议监听者(Protocol Listeners)，WWW服务(World Wide Web Publishing Service)和WAS(Windows  Process Activation Service)，理解这三个组件的功能，是理解IIS的必须的知识。


       下面，我们首先来看第一个。

协议监听者(Protocol Listeners)

       我们知道，很多不同类型的应用程序都需要它们的客户端以不同的协议与它们进行通信，我们稍微简单的来举几个例子让大家明白：

• Web应用程序采用Http来通信。Web应用程序通过接受Http请求和发送Http响应给客户端的方式来进行通信。
  
• WCF应用程序可以采用很多的协议来进行通信，包括：HTTP, NET.TCP, NET.PIPE, 和 NET.MSMQ
  

       在这里各种不同类型的应用中，协议监听者就是一个负责监听特定协议的请求，然后把请求传递给IIS的组件。每一个协议都有它自己的监听者。IIS7中包括了四个协议的监听者：HTTP.SYS，NET.TCP，NET.PIPE和NET.MSMQ。如果要对其他的协议进行监听，那么可以采用PlugIn的方式写新协议的监听者组件，然后插入到IIS7中（就是采用所谓的“插件式”方式）。

       IIS 7中采用了HTTP.SYS来对HTTP请求进行监听，同时在安全性方面也有了改进，因为它也可以对SSL的请求进行监听。另外，对于HTTP.SYS，在IIS6和IIS7中都支持一下功能：

• HTTP.SYS被实现成为内核模式中的一个组件
  
• HTTP.SYS直接将接受到的HTTP请求传递给请求的处理工作进程，并且在中途不会出现任何的进程间通信的开销。在IIS6的之前的版本中，HTTP请求首先被用户模式中的进程inetinfo.exe接受，这个进程再把请求转发给IIS中的工作进程，这个过程就涉及到了工作进程与IIS之前跨进程通信了。
  
• 每一个应用程序池都有自己的基于内核模式的请求队列。当没有足够的工作进程来处理HTTP请求的时候，HTTP.SYS就把新来的请求放在队列中。之后，工作进程会直接从队列中拿出请求进行处理，在过程中不会涉及到进程间通信的开销。
  
• HTTP.SYS会把请求的输出的响应缓存在内核缓存中，方便对后续的请求进行快速的响应。
  

下面，我们来看第二个组件。

WAS(Windows  Process Activation Service)

       WAS的主要的职责就是去读取applicationHost.config配置文件中的配置项。有些配置项是用来配置协议监听者的。在之前我们讨论过，每一个协议都有一个监听者（在IIS6中，可以支持的协议只有HTTP协议，在IIS7中因为引入了插件式的协议监听者的方式，所以可以处理很多的协议，如果大家还记得话，要把WCF部署在IIS6中，那么就只能通过HTTP协议）。

       如果WAS直接与每个特定的协议监听者交互，那么WAS就与这些协议的监听者仅仅的耦合在了一起，不能与其他的协议监听者交互（因为我们无法修改WAS的代码，除非微软发布新的版本）。所以在IIS7中，在这里就引入了协议监听适配器，其实就是采用了adapter模式了。让WAS依赖抽象，而不是依赖具体的实现。

       协议监听适配器将WAS与具体的协议的监听者隔离。那么每一个协议都有一个协议的适配者。例如HTTP协议的适配者知道如何去适配HTTP.SYS，如果对设计模式比较熟悉的朋友，应该非常清楚这一点了。

       WAS读取applicationHost.config配置文件中的配置信息，然后把这些信息用在协议监听适配者上。协议监听适配者采用这些配置的信息来监听特定通道的请求。

       WAS除了读取配置信息以外，它还负责其他一些比较重要的职责：

• 使用applicationHost.config配置文件的配置信息来配置和启动应用程序池，来处理请求。
  
• 根据applicationHost.config配置文件的配置信息来监控，重启，关闭和管理应用程序池以及相关的工作进程。
  

       理解了上面的内容之后，那么现在应该就非常清楚IIS中请求的处理流程了：

• 当请求达到的时候，协议监听程序开始运行。
  
• 特定的协议监听适配者被创建，并且通知特定的应用程序池请求到达。
  
• WAS检查是否已经有一个工作进程在应用程序池中运行，如果没有，WAS就在应用程序池中创建一个新的工作进程，然后把请求交给这个工作进程来处理，并且这个进程也随后去处理应用程序池的请求队列中的请求。
  

系列文章链接：
IIS负载均衡-Application Request Route详解第一篇：ARR介绍  
IIS负载均衡-Application Request Route详解第二篇：创建与配置Server Farm
IIS负载均衡-Application Request Route详解第三篇：使用ARR进行Http请求的负载均衡（上）
IIS负载均衡-Application Request Route详解第三篇：使用ARR进行Http请求的负载均衡（下）
IIS负载均衡-Application Request Route详解第四篇：使用ARR实现三层部署架构



负载均衡原理与实践详解 第一篇（重新整理）   
负载均衡原理与实践详解 第二篇（重新整理）   
负载均衡原理与实践详解 第三篇 服务器负载均衡的基本概念-网络基础   
负载均衡原理与实践详解 第四篇 使用负载均衡器的服务器群    
负载均衡原理与实践详解 第五篇 负载均衡时数据包流程详解   
负载均衡原理与实践详解 第六篇 健康检查机制详解（上）   
负载均衡原理与实践详解 第七篇 健康检查机制详解（下）   
负载均衡原理与实践详解 第八篇 网络地址转换（上）
负载均衡原理与实践详解 第八篇 网络地址转换(下)
负载均衡原理与实践详解 第九篇 服务器负载均衡技术进阶-会话保持（上）