iis服务器(腾讯云服务器)

(一)

【科普一下】

分布式，集群，云计算机，大数据，负载平衡，高并发........................................................................................................................................................

首先从宏观的角度控制自己，然后通过网络科普遇到问题，再站在这些巨人的肩膀上解决问题。

问题:在大型Web应用系统中，由于请求数量过多和并发因素，WEB系统会宕机！

解决方案主要包括以下几个方面:

1.IIS负载平衡。

2.数据库负载平衡。

3.系统架构的优化，如报表服务器和应用服务器的分离。

接下来就是研究解决了。很简单。首先，拿起一个软柿子。根据常识和方案排序，我决定以IIS为操作。

【相逢nginx】

结果我发现了微软在线自带的IIS的负载平衡。经过多次尝试和数据核对，我只能验证成功，却没能管理好IIS！于是我问了雪莉的大牛师兄，不愧是师兄，给了我另一种实现方式，用nginx(百科)。于是何亮亮开启了nginx的探索之路。

首先我在网上查了nginx的相关原理，文字描述感觉没意思，所以我自己总结了两张对比图，如下:

1.一般情况下(不使用nginx服务器进程):

2.使用nginx服务器后的流程【注:此图以一级nginx服务器为例】:

【总结】

根据这两幅图的比较，不难得出以下结论:

使用nginx管理IIS服务器后:

(1)可靠性大大增强:一台或多台IIS服务器宕机，服务不中断！细心的读者发现，如果nginx服务器宕机？当然也可以通过配置多台多层次的nginx服务器来解决。

(2)处理大访问量时，IIS服务器压力大大降低，访问速度提高。

(3)消耗更多的硬件资源:多加一台服务器(nginx在数据量不大的情况下也可以和IIS共用一台服务器)和N台IIS服务器！但在硬件成本不断降低、可靠性高的今天，这种影响对于访问量大的网站来说几乎可以忽略不计。否则不会有这么多用户，比如国内用户:百度、新浪、网易、腾讯等。

是实战的指导，我越来越佩服有这种想法的人。原则到此为止。如有错误，望各位指正！

(二)

【准备工作】

安装一个文本编辑器(这里以Notepad++为例)

下载Nginx(以Nginx-1.4.7为例，其他版本操作方式相同)

创建两个简单的web页面:在文件夹test1中创建一个新的html页面，内容为——我是Test1，在文件夹test2中创建一个新的html页面，内容为——我是Test2)

将上述两个网页分别发布在IIS上的不同端口号上，测试发布成功(这里以IIS6.2为例，在8010端口发布Test1，在8020端口发布Test2)

在IIS上发布图标

测试成功图标

【配置Nginx】

使用文本编辑器编辑Nginx配置文件。

在Nginx中找到配置文件

在Nginx中修改配置(温馨提示:不要用记事本打开修改，否则会乱码)

使用Dos命令进入Nginx文件夹，启动Nginx(这里以c盘根目录下的Nginx文件夹为例)

【实现效果】

现在让我们一起见证奇迹吧！打开浏览器，在地址栏输入刚刚在Nginx中设置的代理(这里是127.0.0.1:8090)

再次刷新(如果有兴趣可以在配置文件中改变权重中的比例看看效果):

【总结】

当我们在研究事物时，小演示可以激发我们的兴趣，激励我们继续研究。我相信经过这些经历，我会在建筑的道路上越走越远。当然，实战中会有更多有趣的故事！伙计们，别走开，接下来的内容更精彩。

(3) 3)

【前言】

《架构之路:在nginx和IIS服务器之间构建集群实现负载均衡(二)》中提到了很多有趣的点。接下来说说我们在深入调研过程中遇到的趣事。

实战寻路问题

探索旅程-找到问题的原因。

解决方案——解决问题

【实战之行】

我在《架构之路:nginx和IIS Server构建集群实现负载均衡(二)》中做了一个小演示。当时做出来后很兴奋，就努力用实战来检验。

实验前我雄心勃勃，Nginx真的走了很长一段路(详情:猛击我)。我坚信这个东西是可以做出来的。

于是我马不停蹄地进入了实战。这个实战是我之前做过的廊坊一中项目进行的。

(1)在IIS上发布两份廊坊一中系统【端口:一中A为8030；B是8040](注:为了做下一个实验，两个网站的首页会有不同的发布——一中A的登录界面和主界面有8030标识，一中B的登录界面和主界面有8040标识)。以下截图:

(2)为了保证接下来实验的正确性，先分别浏览两个网站，确认发布没有问题，如下图截图所示:

(3)配置Nginx。由于配置过程和前面的博客一样，这里就不赘述了。

(4)访问Nginx的监控端口8090。登录界面由网站8030提供。输入用户名和密码，然后单击登录。截图如下:

(5)本来预计会出现系统主界面，但是出现了奇怪的现象，没有进入系统主界面；而是回到8040的登录界面，如下图所示:

【探索之旅】

遇到问题就会冲上去探索解决，往往会有意想不到的收获。

(1)这个实验的基本结构如下:

为什么会出现上述情况，我对自己有限的知识感到不解；根据我之前的探索经验——如果不了解原理，我会猜测并做相应的实验来验证。

于是开始了自己的实验探索之旅。

(2)探索的五个阶段

(1)第一阶段:刚开始因为没有方向，我们改变了盲测的配置Nginx比例的实验，同一台电脑上不同浏览器的实验，不同电脑访问的实验。

(2)第二阶段:总结第一阶段——盲目做这个实验没有好的效果；于是我改变了方向，去网上查，和别人交流。在这个过程中，我们收获了很多知识，比如对Session和Cookie的理解，网站访问的来龙去脉等等。

最后确认这个问题属于会话共享问题。并做一个猜测:由于Nginx服务的比例配置为1:1，所以会依次向客户端提供服务；登录时，相应的会话信息记录在IIS服务器8030中。轮到8040为客户端提供服务时，这个会话信息无法读取，导致实战中遇到的现象。

(3)第三阶段:有了猜想后，根据猜想进行更有针对性的实验:

①刷新8030登录界面--"填写用户A及其对应的密码，点击登录--"进入8040登录界面--"再次输入用户A及其对应的密码，点击登录--"进入8030主界面。

②刷新8030的登录界面--"填写用户A及其对应的密码点击登录--"得到8040的登录界面--"再次输入用户B及其对应的密码点击登录--"得到8030的登录界面。之后用户A只需刷出8040的登录界面即可登录8030的主界面，用户B刷出8030的登录界面即可进入8040的主界面。

通过这两个实验，验证了上述猜想，但具体过程还很模糊。

(4)第四阶段:代码验证。廊坊一中是用MVC做的。下面是对该行日志的代码分析:

①用户输入用户名和密码以访问登录的控制器，如下图所示:

②登录控制器，接受用户名后检查；如果成功，将返回成功标志，如下图所示:

③登录页面收到成功logo后，再次申请访问主页面控制器，如下图所示:

④主页面的控制器首先拦截访问请求，如下图所示:

⑤拦截后，检查是否有对应的会话信息；如果是，进入首页，如果不是，返回登录页面，如下图所示:

(5)第五阶段:将实验与代码结合，原则上再次描述实际情况；图用来重现上面的实验:

【解决之道】

通过探索，了解到问题的根源是会话不共享；

接下来是如何解决问题；通过在网上的搜索和与他人的交流，经过不懈的尝试，我们终于找到了另一个服务器来存储会话，实现会话共享来解决这个问题。

有了以上基础，这次通过原理实现的实验来验证。

(1)原则:

(1)基本架构图变更如下:

(2)一次登陆的来龙去脉如下图所示:

(二)实施:

了解原理上如何解决；接下来就是考虑怎么做了。

通过查阅相关资料，使用SQLServer存储会话，连接网站，实现会话共享。

(1)建立会话数据库的步骤如下:

①执行附带的脚本。Net，如下图所示:

②生成相应的数据库，如下图所示:

③为了保证8030和8040读同一个会话，要修改库中的一个存储过程；见下图:

④启动ASP.Net国服服务(建议设置为自启动)

(2)在8030和8040网站的配置文件中，添加连接库的字符串；如下图所示:

(3)实验验证:

(1)重启两个网站和Nginx服务(重启Nginx命令:Nginx.exe-s reload)-“用浏览器访问Nginx监控端口8090--”出现登录界面--“输入用户名和密码；如下图所示:

(2)点击登录，奇迹出现；见下图:

③刷新主界面，如下图所示:

(4)检查存储在数据库中的会话表的数据；如下图:

【总结】

一路走来，我感受到一个词:痛并快乐着；有时候我心烦了很久，有些效果出来了，就很振奋人心。当然，对它的探索远未停止，接下来的探索将在下一篇博客中继续为您分享，敬请期待！！！

我相信经过反复的探索和自我奋斗，我会在建筑的道路上越走越远。

转自:https://blog.csdn.net/u012829124/article/details/50282951