一次多系统集成部署引发的系列问题

一、部署环境

1、两台WEB服务器，一台数据库服务器；其中一台.net32位，一台.net64位。

2、一台LINUX主机。

3、Negix做负载均衡。

4、Session状态服务器设置在安装有.net64位机器上，也是启动了64位的asp.net state服务。

 

二、本次部署目标

1、将系统部署到两台机器，并用negix做负载均衡，并使用反向代理。

其中三个使用虚拟目录形式，三个使用网站形式（图片服务器，两个应用网站），一个WCF服务；

所有网站均为MVC框架的ASP.NET应用程序。

 

2、负载均衡后的多系统共享同一个Session服务器。（未来将扩展到memcache存储）

即Session Mode="StateServer"

 

3、单点登录各应用系统。

此次使用WCF服务存储客户信息到IIS进程。（未来将扩展到memcache存储）

 

 

 

三、部署过程

1、负载均衡与反向代理由运维人员实现。

     采用Linux+negix实现。

     注：negix同时具有负载均衡与反向代理的功能，之前是使用sqluid实现反向代理。

 

2、应用系统编译与发布由运维人员实现。

     采用CC.Net编译并发布应用系统。

     注：这个工具对项目结构非常严格，VS项目中，有一些未包含的文件以及黄色叹号的文件最终都会影响编译结果。

           （1）如果带有黄色叹号文件下，CC.Net编译与发布会显示成功，但发布后的文件却是被黄色叹号文件中断了，

                   因此发布后的目录会缺少某些文件。

           （2）未包含的文件，CC.Net也是不会发布的，当然，这跟VS工具的发布是一样的原理。

 

3、测试过程。

     测试过程中发生了一系列的问题。

 

 

四、测试问题汇总

1、由于采用了Session StateServer，又使用了负载均衡，所以在不同IP访问Session时，设置上必须增加加密配置节。单台服务器可不增加该配置节，如下：machineKey。

<sessionState mode="StateServer" stateConnectionString="tcpip=192.168.1.20:42424" stateNetworkTimeout="14400" cookieless="false" timeout="240" />
<machineKey validationKey="78AE3850338BFADCE59D8DDF58C9E4518E7510149C46142D7AAD7F1AD49D95D4" decryptionKey="5FC88DFC24EA123C"  validation="SHA1" />

 

2、同样，由于使用了负载均衡，WCF服务也被运维人员设置了负载均衡，但单点登录信息是存储在IIS进程中的，因此在每个请求被负载均衡后，调用的WCF服务也不一样了，所以不能正常获取用户信息。

（1）之前是这样设置WCF服务调用127.0.0.1:8080/service.svc

（2）经修改后为192.168.1.20:8080/service.svc

所有应用系统都指向同一个wcf服务，并且使用固定的IP，而不是使用127.0.0.1。

注：这里有个怪问题，在使用方式一时，即127.0.0.1时，有时也是能获取的，不知道这负载均衡搞了什么东东。

 

3、使用了Session StateServer时，对象存储必须是可序列化。

 

4、业务公共组件的版本问题。

由于使用了负载均衡，运维人员将HTTP500,501,502都设置为不显示具体错误信息，因此带来调试上的麻烦，没有及时发现业务公共组件的错误。（还是在服务器上直接运行应用系统才发现该问题）

 

 

写到这里，还有一个问题未解决：

即将单点登录部署为虚拟目录时，Sesssion StateServer设置后，单点登录进行同目录，不同文件转向时，不能获取上一个页面设置的Session，比较郁闷，先写到这里，WC去，一会回来看看虚拟目录问题。还有这个是HTTPS环境。不知是否有关系。

 

 

莫名其妙，经过一番折腾，虚拟目录与网站形式都可以了。目前可以，但要经过几天的测试使用后，才能完全确定。

 

---

 

本次的经验教训：

1、因为配置文件由运维人员做具体设置，因此有些地方过于信任运维人员，而Session的状态服务器形式也是第一次用，因此没有怀疑运维人员的设置，而怀疑是程序问题，在程序上花费了不少测试时间，包含做测试网站，并配置测试网站。然后才真正怀疑配置问题，才上MSDN查找官方具体配置详细说明，才发现，在不同的服务器访问同一个Session需要使用machineKey。

     看来有些时候，仍然需要自己去确定配置，而不总是信任运维人员。

 

2、自身的问题。由于在查找虚拟目录的过程中，不知道从哪操作，比如：IIS设置session或者web.config直接修改，而导致session的mode="StateServer"配置信息丢失了，然后网站的方式也不行了，就不停的在查找解决方法，因为上午可以，而又信任自己没有修改配置，结果就导致了几个小时都在看技术文章，GOOGLE搜索相关问题，从而浪费了不少时间，直到同事过来一起讨论，才把整个解决问题的思路建立起来，因为之前创建的测试网站是没有问题的，所以从配置文件入手，最后发现少了stateserver配置信息，狂晕，我那个郁闷啊。。。。。。。

     看来有些时候，仍然不能过于信任自己之前的一些行为。过于信任自己之前的行为，导致了思路的不清晰，最终花费了大量时间。