Windows 进程激活服务 (WAS) 的功能

作者:Thomas Deml

IIS 7 的 Windows 进程激活服务 (WAS) 是为 Web 应用程序和 Web 服务提供进程模型和配置功能的关键组件。 WAS 的主要任务是管理应用程序池。 应用程序池是表示 URL 组的托管环境的配置容器。

当 HTTP 客户端请求 URL 时,HTTP.SYS 会将请求映射到应用程序池请求队列。 WAS 生成应用程序池请求队列的工作进程,工作进程执行发送响应所需的代码。 WAS 的主要任务之一是管理它生成的工作进程,即 WAS 监视工作进程的健康状况,在必要时回收工作进程,并确保工作进程消耗的资源不会多于相应 AppPool 配置中指定的资源。 WAS 还是运行时和状态数据(例如性能计数器、站点和应用程序池状态)的仲裁器和收集器。

体系结构关系图

IIS 7.0 Architecture

进程模型功能

支持在同一台物理计算机上托管 10000 个或更多网站是当今大规模托管环境的核心要求。 这些网站上运行的代码通常没有经过充分测试(如果有)。 为了支持这些需求,WAS 需要提供强大的流程模型和高效的资源管理。

高效的资源管理

按需激活

在多租户方案中,RAM 和 CPU 等资源很少。 仅当对特定网站或 Web 应用程序的请求到达后,WAS 才会启动 IIS 工作进程。

空闲超时

由于资源通常稀缺,WAS 可以根据可配置的空闲超时关闭 Web 应用程序。

运行状况监视

为了确保其健康状况,WAS 会监视其生成的工作进程。 健康状况消息定期发送到每个正在运行的工作进程。 如果工作进程未在可配置的时间段内响应,则工作进程将被回收或终止。 这样可以通过重启工作进程自动修复工作进程中未检测到的死锁。

启动限制

快速失败保护功能的一部分是启动限制。 如果工作进程未在可配置的启动限制内向 WAS 报告,则该进程将被终止,并且快速失败保护计数器会递增。 如果快速失败保护计数器在可配置的时间限制内达到可配置的限制,应用程序池将停止,即不再尝试重启工作进程。 这样可以避免工作进程在启动期间挂起或崩溃的情况。

关闭限制

工作进程还必须在可配置的限制内关闭。 如果此时未发生关闭,则由 WAS 终止工作进程。 这样可以避免由于进程在关闭阶段挂起而导致的资源过度使用。 当关闭未在指定时间内完成时,其他关闭设置允许启动可执行文件(例如调试程序)。

CPU 相关性

配置设置允许 WAS 启动与一个或多个 CPU 关联的工作进程。 这样可以避免租户在共享同一台物理计算机时相互干扰。

用户配置文件

WAS 可以在加载或不加载用户配置文件的情况下启动工作进程。

安全性

应用程序池标识

IIS 工作进程可以作为自定义帐户、内置帐户(LocalService、LocalSystem、NetworkService)或应用程序池标识(默认)运行。 建议使用应用程序池标识,因为它不需要密码管理,并且应用程序池标识已遵守最低特权原则。 内置帐户也不需要密码管理。 如果使用自定义用户标识,密码将自动加密。 通过跨计算机共享配置加密密钥,可以将配置设置复制到多台计算机。

作业对象功能

作业对象允许管理员将工作进程限制为特定的 CPU 限制。 如果超出此 CPU 限制,则会执行可配置操作。 作业对象还将确保由工作进程生成的进程被终止。

配置隔离和安全性

WAS 在启动应用程序池及其工作进程之前,会为此应用程序池生成唯一的配置文件。 应用程序池还具有配置设置,可以在唯一标识下运行应用程序池。 但是,即使使用相同的标识,也可以实现隔离。 WAS 为每个应用程序池创建唯一的安全标识符 (SID)。 然后,应用程序池配置文件将使用此唯一的 SID 进行保护。 这样可以确保应用程序池配置文件只能由管理员和应用程序池本身读取。 甚至可以使用此唯一 SID 配置文件权限。

诊断和监控

事件日志记录

有关工作进程的无效配置、回收、启动或关闭的事件将报告到系统事件日志。

当前正在执行的请求

WAS 公开了一个运行时和状态控制界面,允许脚本和工具查询特定工作进程当前正在执行的请求。 这对于查找挂起的请求或需要很长时间才能完成的请求非常有用。

性能计数器

所有 IIS 性能计数器都会通过 WAS。 WAS 收集这些性能计数器,因为 IIS 计数器是基于站点的,Web 应用程序可以位于不同的应用程序池中。

回收利用

回收允许刷新工作进程,而不会因停机而丢失单个请求。 这是通过一项名为“重叠回收”的功能完成的。

重叠回收

WAS 通过生成一个与仍在处理请求的旧工作进程并行的新工作进程来执行此操作。 新工作进程启动后,将开始从请求队列中选取请求,而旧工作进程则根据 WAS 的指示停止选取请求。 旧工作进程完成所有执行请求后将关闭。 此功能称为“重叠回收”。 它可以确保回收期间不会丢失任何请求。

回收配置

回收参数可在 IIS 配置系统中进行配置。

计划回收

客户可能希望定期回收其应用程序。 可以通过配置设置定期计划回收,例如 每 4 小时、每天凌晨 1 点等。

基于内存消耗的回收

随着时间的推移,应用程序内存可能会泄漏。 WAS 可以监视每个工作进程的内存消耗,以确保没有工作进程使用超过其预配置的限制。 达到配置的虚拟或专用内存阈值将触发工作进程回收。

基于请求数的回收

还可以根据处理的特定工作进程的请求数来配置回收。

自定义回收

自定义代码可以自定义健康状况统计信息,并通过 API 调用 WAS 运行时和状态 API 触发回收。

进程孤立

某些错误仅在生产环境中发生。 终止工作进程可以确保正常运行时间,但排除这些错误变得很困难,例如需要调试失败的工作进程。 WAS 中的进程孤立功能允许在不终止失败工作进程的情况下回收工作进程。 现在它可以附加一个调试程序。 如果发生孤立操作,其他进程孤立设置允许执行进程(例如调试程序)。

应用程序池状态管理

应用程序池可以通过公开可用的 API 停止、回收或启动,例如,如果应用程序必须脱机,或者必须根据与 applicationhost.config 文件中可配置的参数不同的参数进行回收。

其他 WAS 功能

负载均衡器功能

HTTP.SYS 仍然侦听网络,如果应用程序池未选取请求,将返回 500 HTTP 错误消息。 发生此问题的原因是,对于 5 级负载均衡器 (TCP/IP),500 HTTP 错误看起来像是有效的 TCP/IP 连接。 WAS 配置设置可以使 HTTP.SYS 拒绝连接而不是发送 HTTP 响应。

WAS 可以配置为使用以下设置启动工作进程:

WoW64 支持

WAS 可以启动 32 位或 64 位工作进程。

.NET Framework 预加载

WAS 可以配置为预加载特定版本的 .NET Framework。 这可以使版本冲突的故障排除变得更加容易。

Web 花园

Web 花园是其中运行多个工作进程的应用程序池的术语。 使用轮循机制在这些工作进程实例之间分配请求。

WAS 多协议支持

WAS 不仅托管 HTTP 堆栈。 它还可以通过其侦听适配器和工作进程框架托管其他协议。 WCF 服务利用 WAS 多协议支持。 WCF 协议附带其自己的侦听器(例如 NET.TCP、NET.MSMQ 或 NET.PIPE 侦听器)。 这些侦听器使用 WAS 提供的侦听器适配器接口连接到 WAS。

利用此基础结构的应用程序协议可以将自定义应用程序代码托管到与常规 ASP.NET 应用程序相同的 .NET 应用程序域中。 它们还可以利用 ASP.NET 托管环境提供的独立于协议的服务,例如按需编译、配置支持等。