2.1 部署Web应用需要考虑的几个问题

在部署Web服务器之前，需要首先了解清楚网站部署后使用账号的类型、保存会话数据的方式以及如何保证部署的内容一致，这三个问题会极大地影响部署模式的设计。

2.1.1 账号类型

目前在IIS上可以用来运行Web应用程序的账号主要有以下几种：本机Windows账号、应用程序池服务账号和活动目录域账号。

所谓本机Windows账号就是日常Windows用户用于登录Windows操作系统的账号。此类账号可以隶属于本机的各种内置安全组中，以便于控制对本机资源的访问。但是这类账号在访问跨计算机的资源时是没有权限的，如访问位于另一台计算机的SQL SERVER数据库时，只能在连接字符串中指明访问数据的用户名和密码。

其实Windows还为IIS的Web网站创建了一类内建系统账号，这类账号的特点是没有密码，并且已经预置了安全的权限。在IIS 6.0时代，这个账号的名字是NetworkService。Windows已经为NetworkService这个应用程序池的启动账号限制了它的权限。例如，这个账号只能读取注册表而不能改写注册表，只能给某个Windows事件源添加事件而不能创建事件源，只能在本网站的目录和子目录创建文件而不能在网站目录以外的地方读写文件，等等。这保证了即使网站被黑客攻陷也无法接管整个计算机。这样就完美了吗？不一定。这是因为在一台Web服务器上运行多个站点的情况下使用同一个系统内建账号运行有可能引起互相干扰，例如，某个网站需要在系统盘某个目录下拥有写文件的权限，当管理员配置完成后，实际上所有NetworkService账号运行的网站都有对这个文件夹拥有写文件的权限。在IIS 7.0以后，一类新的系统内建账号ApplicationPoolIdentity应运而生。这种账号是一种虚拟的系统内建账号，会根据应用程序池的名称一对一地创建，每个应用程序池都用自己各自独立的账号来运行，可以很好地避免互相干扰的问题。同普通Windows账号一样，此类账号也无法跨计算机访问资源。

活动目录域账号是在活动目录域内创建的，是可以在域内跨计算机访问的一类账号。目录服务就是为了管理局域网内的网络资源而诞生的，微软活动目录（Active Directory）仅是目录服务的一种实现。使用活动目录域账号可以访问域内计算机的本地资源和远程数据库服务等资源，同时，域账号也便于域管理员对其进行管理和限制，账号验证安全机制安全完善。

在典型的负载平衡环境中，推荐Web网站相关的全部计算机都加入域，使用域账号来运行Web网站。

2.1.2 Web站点状态数据的存储方式

Web站点的状态数据主要是指Web站点的会话对象（Session）中存储的数据。在默认模式下，会话数据是保存在Web服务器本机工作进程内的。在网络负载平衡环境下，尤其是轮询调度模式下，会话数据保存在Web服务器进程内，且无法被另外一个Web服务器工作进程访问。因此，有必要把会话数据进行集中存储，常见的备选方案有以下几种：

1. SQL SERVER

在%SystemRoot%\Microsoft.NET\Framework或Framework64文件夹对应的.NET版本子文件夹内有一个名为InstallSqlState.sql的SQL脚本文件。在SQL SERVER服务器上执行这个脚本文件会安装一个名为ASPState的数据库，同时脚本会在tempdb临时数据库上创建一个ASPStateTempSessions表来保存Web应用程序的会话数据，最后SQL脚本会在ASPState数据库下创建一个名为ASPState_Job_DeleteExpiredSessions的存储过程，通过定期执行这个存储过程删除ASPStateTempSessions表中已经过期的会话数据。

2. ASP.NET State Service

这个服务是在安装.NET Framework时一并安装的Windows服务。ASP.NET State Service服务使用服务器的内存作为会话保存的空间，默认端口号是42424，如果需要修改默认端口，则需要修改服务所在服务器的注册表键值：

HKLM\SYSTEM\CurrentControlSet\Services\aspnet_state\Parameters\Port

3. Redis Cache

这是一种基于键值对结构且使用ANSI C编写的高效的开源内存数据库服务。使用Redis Cache也可以缓存会话数据，并且Redis可以搭建群集，扩展性较好。使用Redis作会话缓存需要专门的RedisSessionStateProvider组件，这个组件可以在NuGet上下载。

对比以上三种方式，SQL SERVER的效率相对较差，因为每次执行SQL语句在数据表上存取会话数据的代价比直接从内存中直接访问的时间代价大得多。ASP.NET State Service和Redis Cache两种方式都是使用内存作为会话数据的存储方式，但是ASP.NET State Service只能单机部署，容易形成单点故障，Redis Cache通过主动复制功能可以在主从两个节点间同步数据，从而避免了单点故障的风险。当然搭建Redis Cache主从复制模式成本也是最高的。

2.1.3 保证配置和网站内容一致的方法

在网络负载平衡群集环境中，需要保证每台服务器的Web网站运行环境都一样，这样才能使得针对同样的HTTP请求每台Web服务器的运算结果都是一样的，这就是Web网站的部署一致性问题。涉及一致性问题的资源主要有：

（1）Web网站运行账号。

（2）访问本地资源的权限和位置。

（3）IIS配置文件ApplicationHost.config或Metabase.xml等。

（4）Web网站内容文件夹。

（5）.NET Framework配置文件Machine.config。

以上内容有任何不一致，都会导致负载平衡群集环境下运行会出现莫名其妙的问题，并且难以排查。尤其是在Web网站多次版本更新操作后，Web网站内容文件夹和配置文件极有可能出现不一致的情况。如何保证配置和网站内容的一致性是部署前IIS管理员需要仔细考虑的问题。

在实践中，Web服务器管理员可以通过共享文件夹、分布式文件系统（DFS）、源代码管理工具等方式来实现部署一致性，而手工复制往往被认为是最不可靠的。