分布式,集群,云计算机、大数据、负载均衡、高并发······当耳边响起这些词时,做为一个菜鸟程序猿无疑心中会激动一番(或许这是判断是否是一个标准阿猿的标准吧,参考【如何快速定位自己热爱的工作】)!

首先自己从宏观把控一下,通过上网科普自己遇到问题,然后再站在这些巨人的肩膀上解决问题。

问题:在大型WEB应用程系统中,由于请求的数量过大及并发的因素,导致Web系统会出现宕机的现象!

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

1、IIS负载均衡。

2、数据库负载均衡。

3、系统架构优化,比如:报表服务器和应用服务器的分离等。

接下来就是研究与解决,很简单首先捡个软柿子捏,根据常识以及方案排序,决定拿IIS来开刀。

【相逢nginx】
于是乎上网找到了微软自带的IIS负载均衡,经过多次尝试与查资料后只能验证成功但未能实现对IIS管理!于是乎请教文哲大牛师哥,不愧为师哥,给了另外一种实现的方法利用nginx(百科)。于是和亮亮开启了nginx探索之路。

首先上网查资料nginx相关原理,文字性描述感觉很无聊,于是自己总结两张对比图,如下:

1、一般情况下(未使用nginx服务器流程):

架构之路:Nginx与IIS服务器搭建集群实现负载均衡
2、使用nginx服务器后流程【注:本图以一级nginx服务器为例】:

架构之路:Nginx与IIS服务器搭建集群实现负载均衡
【总结】
根据这两张图对比,不难得出以下结论:

利用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上)

架构之路:Nginx与IIS服务器搭建集群实现负载均衡
IIS上发布图示

架构之路:Nginx与IIS服务器搭建集群实现负载均衡
测试成功图示

【配置Nginx】
·使用文本编辑器编辑Nginx配置文件

架构之路:Nginx与IIS服务器搭建集群实现负载均衡
找到Nginx中配置文件

架构之路:Nginx与IIS服务器搭建集群实现负载均衡
修改Nginx中配置(温馨提示:不要用记事本打开修改否则会乱码)

·使用Dos命令进入Nginx文件夹并启动Nginx(这里以将Nginx文件夹放在C盘根目录下为例)

架构之路:Nginx与IIS服务器搭建集群实现负载均衡
【实现效果】
现在让我们一起见证奇迹吧!打开浏览器,在地址栏中输入刚才在Nginx中设置的代理(这里是127.0.0.1:8090)

架构之路:Nginx与IIS服务器搭建集群实现负载均衡
再刷新一次(大家如果有兴趣可以更改配置文件中Weight中的比例来看效果):

架构之路:Nginx与IIS服务器搭建集群实现负载均衡
【总结】
当我们在研究东西的时候,小Demo可以激发我们的兴趣,可以激励我们继续研究下去。相信经过这些历练,自己会在架构的路上越走越远。当然在实战中会有更多有趣的故事!大家伙儿别走开,接下来的内容更加精彩。

(三)

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

·实战之行——发现问题

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

·解决之道——解决问题

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

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

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

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

架构之路:Nginx与IIS服务器搭建集群实现负载均衡
(2)为了保证接下来实验正确性,先单独浏览两个网站确认发布没有问题,如下截图:

架构之路:Nginx与IIS服务器搭建集群实现负载均衡
(3)配置好Nginx,由于和上篇博客配置过程一样,在此不再赘述。

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

架构之路:Nginx与IIS服务器搭建集群实现负载均衡
(5)预想是出现系统主界面,但是奇怪的现象发生,没有进入系统的主界面;而是返回8040的登录界面,如下图所示:

架构之路:Nginx与IIS服务器搭建集群实现负载均衡
【探索之旅】
遇到问题就冲上去去探索去解决,往往能有意想不到的收获。

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

架构之路:Nginx与IIS服务器搭建集群实现负载均衡
为什么会出现上述那种情况,由于学到的知识有限自己百思不得其解;根据自己之前的探究经验——想不明白原理情况下就去做猜想并做相应的实验去验证。

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

(二)探索五阶段

(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的主界面。

通过这两个实验验证上面自己的猜想,不过针对具体的过程自己还是比较模糊。


链接已复制

暂无评论

发送评论 编辑评论


				
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇
下一篇