nginx与IIS服务器搭建集群实现负载均衡(三)

本文涉及的产品
应用型负载均衡 ALB,每月750个小时 15LCU
网络型负载均衡 NLB,每月750个小时 15LCU
传统型负载均衡 CLB,每月750个小时 15LCU
简介: nginx与IIS服务器搭建集群实现负载均衡(三)

强烈推荐一个大神的人工智能的教程:http://www.captainai.net/zhanghan


【前言】


   在《架构之路:nginx与IIS服务器搭建集群实现负载均衡(二)》中提到有好多有趣的地方,接下来就为大家一块儿讲讲在深入研究过程中遇到那些有趣的事情。


   ·实战之行——发现问题


   ·探索之旅——寻出问题原因


   ·解决之道——解决问题


【实战之行】


   在《架构之路:nginx与IIS服务器搭建集群实现负载均衡(二)》中做了小Demo,当时做出来后很兴奋,于是一鼓作气,用实战来检验。


   实验前就雄心勃勃,Nginx确实大有来头(详情:猛击me),坚信这个东西可以弄成。


   于是马不停蹄进入实战,这次实战是拿之前做的廊坊一中项目来进行的。


  (1)在IIS上将廊坊一中系统发布两份【端口:一中A为8030;一中B为8040】(注:为了做接下来实验,将发布两个网站首页进行了区别—一中A的登录界面以及主界面有8030标识,一中B登录界面以及主界面有8040标识)如下截图:


62167fd906ae34766e35ffdba68b97a4_20160310180840878.png


   (2)为了保证接下来实验正确性,先单独浏览两个网站确认发布没有问题,如下截图:


6e69464d72243b1370e68ec246d189e8_20160310180854785.png


   (3)配置好Nginx,由于和上篇博客配置过程一样,在此不再赘述。


   (4)访问Nginx的监控端口8090——》出的登录界面是8030网站提供的——》输入用户名和密码点击登录;如下截图:


168a29f4e2c5bb3e0177d84f31ca01a8_20160310180920660.png


    (5)预想是出现系统主界面,但是奇怪的现象发生,没有进入系统的主界面;而是返回8040的登录界面,如下图所示:


 0760014deb8a20fe05deba0df0aa3982_20160310180940474.png


【探索之旅】


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


  (一)本实验的基本架构如下图:


89e5338146b9872641e01161f9ce574f_20160310181909065.png


    为什么会出现上述那种情况,由于学到的知识有限自己百思不得其解;根据自己之前的探究经验——想不明白原理情况下就去做猜想并做相应的实验去验证。


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


  (二)探索五阶段


   (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,如下图示:


37fc36382dce2bec783110d7bd4a8ef1_20160310201859572.png


     ②登录Controller接受住用户名后进行校验;若成功则返回成功标识,如下图所示:


257779bab9d603f94125762c61ce37f4_20160310202032619.png


     ③登录页面接受到成功标识后再次申请访问主页面Controller,如下图所示:


7a3949a06fdd377cdc8033c1d997a9c6_20160310202100057.png


     ④主页面的Controller对来访问的请求先进行拦截,如下图所示:


0842f8f3bddf4878040d1a562843c447_20160310202317397.png


    ⑤拦截后,检查是否有相应的Session信息;若有则进入主页,若没有则返回登录页面,如下图:


 5165f54c9b9acb15f2246abafce028d2_20160310202459274.png


    (5)第五阶段:实验和代码相结合,再次从原理上描述出现实战中的情况;用图来对上述实验进行再现:


12b2b0e4026edfd4b28cfe0834e9e36c_20160310181933649.png


【解决之道】


    通过探索明白了问题产生的根本在于Session没有共享;


    接下来就是如何去解决该问题;通过上网查找以及和别人交流,经过不懈的尝试最终找到了利用另外一台服务器来存储Session从而实现Session共享来解决这个问题。


    有了上面的基础这次从   原理——》实现——》实验验证


   (一)原理:


   (1)基本架构图改成如下所示:


55d1b8c5cd83028cf0adb806fa31d4c1_20160310205540909.png


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

2cc6e3ae98ea9e96c1ce7635289049f5_20160310212138205.png

     

    (二)实现:


     原理上明白如何解决;接下来就是考虑如何去做?


     通过查阅相关资料用SQLServer来做session的存储,让网站连上,从而实现Session共享。


    (1)建立session数据库步骤如下:


       ①执行.Net自带的脚本,如下图所示:


52738374ecc974cf2a6fb9f0d5dcff42_20160310213512429.png


     ②生成相应的数据库,如下图:


37d2b870b5729b819f6c268e99839262_20160310214229307.png


     ③为保证8030和8040读到是同一个Session需将,该库中的一个存储过程做修改;见下图:


2fb21296b8de801a028f6689f575a8c3_20160310220709657.png


     ④启动ASP.Net State Service服务(建议将其设为自启动)


f645218da5a1f6ffa99e18603e7a42c0_20160310214657537.png


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


15189fe94a361c9a0d2e67bfbdcfecc8_20160310214758976.png


   (三)实验验证:


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


8b343a12e454f50140da0b0eba86daf6_20160310215406843.png


    (2)点击登录,奇迹出现;见下图:


78f36c3b2fefda5c6197da521383fd41_20160310215613767.png


    (3)刷新主界面,见下图:


5d8729cacfe37c08d2ae4188ab96ce1d_20160310215800379.png


     (4)查看数据库中存储Session表的数据;如下图:


36647e1efdb8f8781ba151da949790b7_20160310220002690.png


【总结】


    这一路走来感觉一句话:痛并快乐着;有时候苦恼半天,当出来点效果后又振奋人心;当然对它的探索远没有停止,接下来的探索会在下篇博客中继续为大家分享,敬请期待!!!


    相信经过一次次的探索,经过自己的奋斗,相信自己会在架构路上会越走越远。          


相关实践学习
SLB负载均衡实践
本场景通过使用阿里云负载均衡 SLB 以及对负载均衡 SLB 后端服务器 ECS 的权重进行修改,快速解决服务器响应速度慢的问题
负载均衡入门与产品使用指南
负载均衡(Server Load Balancer)是对多台云服务器进行流量分发的负载均衡服务,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。 本课程主要介绍负载均衡的相关技术以及阿里云负载均衡产品的使用方法。
相关文章
|
2月前
|
负载均衡 监控 应用服务中间件
配置Nginx反向代理时如何指定后端服务器的权重?
配置Nginx反向代理时如何指定后端服务器的权重?
138 61
|
19天前
|
弹性计算 负载均衡 网络协议
ECS中实现nginx4层7层负载均衡和ALB/NLB原SLB负载均衡
通过本文的介绍,希望您能深入理解并掌握如何在ECS中实现Nginx四层和七层负载均衡,以及如何使用ALB和NLB进行高效的负载均衡配置,以提高系统的性能和可靠性。
69 9
|
5月前
|
Java 应用服务中间件 Shell
Nginx+Keepalived+Tomcat 实现Web高可用集群
Nginx+Keepalived+Tomcat 实现Web高可用集群
147 0
|
1月前
|
负载均衡 前端开发 应用服务中间件
负载均衡指南:Nginx与HAProxy的配置与优化
负载均衡指南:Nginx与HAProxy的配置与优化
61 3
|
1月前
|
存储 编解码 应用服务中间件
使用Nginx搭建流媒体服务器
本文介绍了流媒体服务器的特性及各种流媒体传输协议的适用场景,并详细阐述了使用 nginx-http-flv-module 扩展Nginx作为流媒体服务器的详细步骤,并提供了在VLC,flv.js,hls.js下的流媒体拉流播放示例。
150 1
|
3月前
|
监控 网络安全 调度
Quartz.Net整合NetCore3.1,部署到IIS服务器上后台定时Job不被调度的解决方案
解决Quartz.NET在.NET Core 3.1应用中部署到IIS服务器上不被调度的问题,通常需要综合考虑应用配置、IIS设置、日志分析等多个方面。采用上述策略,结合细致的测试和监控,可以有效地提高定时任务的稳定性和可靠性。在实施任何更改后,务必进行充分的测试,以验证问题是否得到解决,并监控生产环境的表现,确保长期稳定性。
137 1
|
3月前
|
弹性计算 负载均衡 算法
负载均衡如何帮助阿里云国际服务器搭建的网站或应用程序?
负载均衡如何帮助阿里云国际服务器搭建的网站或应用程序?
|
3月前
|
存储 数据采集 分布式计算
Hadoop-17 Flume 介绍与环境配置 实机云服务器测试 分布式日志信息收集 海量数据 实时采集引擎 Source Channel Sink 串行复制负载均衡
Hadoop-17 Flume 介绍与环境配置 实机云服务器测试 分布式日志信息收集 海量数据 实时采集引擎 Source Channel Sink 串行复制负载均衡
60 1
|
5月前
|
负载均衡 监控 算法
揭秘负载均衡的五大算法秘籍:让你的服务器轻松应对亿万流量,不再崩溃!
【8月更文挑战第31天】在互联网快速发展的今天,高可用性和可扩展性成为企业关注的重点。负载均衡作为关键技术,通过高效分配网络流量提升系统处理能力。本文介绍了轮询、加权轮询、最少连接及IP哈希等常见负载均衡算法及其应用场景,并提供Nginx配置示例。此外,还探讨了如何根据业务需求选择合适算法、配置服务器权重、实现高可用方案、监控性能及定期维护等最佳实践,助力系统优化与用户体验提升。
97 2
|
5月前
|
负载均衡 算法 应用服务中间件
负载均衡技术在Web服务器集群中的应用
【8月更文第28天】随着互联网的发展和用户对Web服务需求的增长,单台服务器很难满足大规模访问的需求。为了提高系统的稳定性和扩展性,通常会采用Web服务器集群的方式。在这种架构中,负载均衡器扮演着至关重要的角色,它能够合理地分配客户端请求到不同的后端服务器上,从而实现资源的最优利用。
156 2