服务器负载均衡(架构之路)

(一)【科普一下】分布式,集群,云计算机、大数据、负载均衡、高并发······当耳边响起这些词时,做为一个菜鸟程序猿无疑心中会激动一番(或许这是判断是否是一个标准阿猿的标准吧,参考【如何快速定位自己热爱的工作】)!首先自己从宏观把控一下,通过上网科普自己遇到问题,然后再站在这些巨人的肩膀上解决问题。问题:在大型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为例,其他版本操作相同)·建两个简单网页:在文件夹test1新建一个html页内容为——我是Test1,在文件夹test2新建一个html页内容为——我是Test2)·将上面建两个网页分别发布在IIS上不同端口号,并测试发布成功(这里以IIS6.2为例,将Test1发布在8010端口上,将Test2发布在8020上)IIS上发布图示测试成功图示【配置Nginx】·使用文本编辑器编辑Nginx配置文件找到Nginx中配置文件修改Nginx中配置(温馨提示:不要用记事本打开修改否则会乱码)·使用Dos命令进入Nginx文件夹并启动Nginx(这里以将Nginx文件夹放在C盘根目录下为例)【实现效果】现在让我们一起见证奇迹吧!打开浏览器,在地址栏中输入刚才在Nginx中设置的代理(这里是127.0.0.1:8090)再刷新一次(大家如果有兴趣可以更改配置文件中Weight中的比例来看效果):【总结】当我们在研究东西的时候,小Demo可以激发我们的兴趣,可以激励我们继续研究下去。相信经过这些历练,自己会在架构的路上越走越远。当然在实战中会有更多有趣的故事!大家伙儿别走开,接下来的内容更加精彩。(三)【前言】在《架构之路:nginx与IIS服务器搭建集群实现负载均衡(二)》中提到有好多有趣的地方,接下来就为大家一块儿讲讲在深入研究过程中遇到那些有趣的事情。·实战之行——发现问题·探索之旅——寻找问题原因·解决之道——解决问题【实战之行】在《架构之路:nginx与IIS服务器搭建集群实现负载均衡(二)》中做了小Demo,当时做出来后很兴奋,于是一鼓作气,用实战来检验。实验前就雄心勃勃,Nginx确实大有来头(详情:猛击me),坚信这个东西可以弄成。于是马不停蹄进入实战,这次实战是拿之前做的廊坊一中项目来进行的。(1)在IIS上将廊坊一中系统发布两份【端口:一中A为8030;一中B为8040】(注:为了做接下来实验,将发布两个网站首页进行了区别—一中A的登录界面以及主界面有8030标识,一中B登录界面以及主界面有8040标识)如下截图:(2)为了保证接下来实验正确性,先单独浏览两个网站确认发布没有问题,如下截图:(3)配置好Nginx,由于和上篇博客配置过程一样,在此不再赘述。(4)访问Nginx的监控端口8090——》出的登录界面是8030网站提供的——》输入用户名和密码点击登录;如下截图:(5)预想是出现系统主界面,但是奇怪的现象发生,没有进入系统的主界面;而是返回8040的登录界面,如下图所示:【探索之旅】遇到问题就冲上去去探索去解决,往往能有意想不到的收获。(一)本实验的基本架构如下图:为什么会出现上述那种情况,由于学到的知识有限自己百思不得其解;根据自己之前的探究经验——想不明白原理情况下就去做猜想并做相应的实验去验证。于是乎就开始了自己实验的探索之旅。(二)探索五阶段(1)第一阶段:开始的时候因为没有方向,就改配置瞎测试——改Nginx比重实验、同一台电脑不同浏览器实验、不同电脑来访问的实验。(2)第二阶段:总结第一阶段——盲目地这样做实验并没有好的效果;于是乎就改变方向,去网上查和别人交流。在这个过程中收获许多知识,比如:对Session和Cookie的理解,网站访问的来龙去脉等等。最后确认这个问题属于Session共享问题。并做出猜想:由于Nginx服务比重配置为1:1,则轮流给客户端提供服务;当登录时将相应Session信息记录在IIS服务器8030时,当轮到8040给客户端提供服务时读不到这个Session信息而导致实战中遇到现象。(3)第三阶段:有了猜想后,根据猜想做了比较有针对性的实验:①刷新出8030的登录界面——》填写用户A和其对应密码点击登录——》得到8040的登录界面——》再次输入用户A和其对应密码点击登录——》进入8030的主界面。②刷新出8030的登录界面——》填写用户A和其对应密码点击登录——》得到8040的登录界面——》再次输入用户B和其对应密码点击登录——》得到8030的登录界面。此后只要刷出8040的登录界面就能用用户A登录到8030的主界面,刷出8030登录界面用用户B就能进入8040的主界面。通过这两个实验验证上面自己的猜想,不过针对具体的过程自己还是比较模糊。(4)第四阶段:通过代码来验证,廊坊一中是用MVC来做的,下面就是登录这条线的代码分析:①用户输入用户名和密码后去访问登录的Controller,如下图示:②登录Controller接受住用户名后进行校验;若成功则返回成功标识,如下图所示:③登录页面接受到成功标识后再次申请访问主页面Controller,如下图所示:④主页面的Controller对来访问的请求先进行拦截,如下图所示:⑤拦截后,检查是否有相应的Session信息;若有则进入主页,若没有则返回登录页面,如下图:(5)第五阶段:实验和代码相结合,再次从原理上描述出现实战中的情况;用图来对上述实验进行再现:【解决之道】通过探索明白了问题产生的根本在于Session没有共享;接下来就是如何去解决该问题;通过上网查找以及和别人交流,经过不懈的尝试最终找到了利用另外一台服务器来存储Session从而实现Session共享来解决这个问题。有了上面的基础这次从 原理——》实现——》实验验证(一)原理:(1)基本架构图改成如下所示:(2)一次登陆的来龙去脉如下图所示:(二)实现:原理上明白如何解决;接下来就是考虑如何去做?通过查阅相关资料用SQLServer来做session的存储,让网站连上,从而实现Session共享。(1)建立session数据库步骤如下:①执行.Net自带的脚本,如下图所示:②生成相应的数据库,如下图:③为保证8030和8040读到是同一个Session需将,该库中的一个存储过程做修改;见下图:④启动ASP.Net State Service服务(建议将其设为自启动)(2)在8030和8040的网站的配置文件中,添加连接该库的字符串;如下图所示:(三)实验验证:(1)重启两个网站和Nginx服务(重启Nginx命令:nginx.exe -s reload)——》用浏览器访问Nginx监听端口8090——》出现登录界面——》输入用户名和密码;如下图所示:(2)点击登录,奇迹出现;见下图:(3)刷新主界面,见下图:(4)查看数据库中存储Session表的数据;如下图:【总结】这一路走来感觉一句话:痛并快乐着;有时候苦恼半天,当出来点效果后又振奋人心;当然对它的探索远没有停止,接下来的探索会在下篇博客中继续为大家分享,敬请期待!!!相信经过一次次的探索,经过自己的奋斗,相信自己会在架构路上会越走越远。转自:https://blog.csdn.net/u012829124/article/details/50282951

本文出自快速备案,转载时请注明出处及相应链接。

本文永久链接: https://www.175ku.com/26723.html