19个心得,明明白白说Linux下的负载均衡
一、目前网站架构一般分成负载均衡层、web层和数据库层,我其实一般还会多加一层,即文件服务器层,因为现在随着网站的PV越来越多,文件服务器的压力也越来越大;不过随着moosefs、DRDB+Heartbeat的日趋成熟,这问题也不大了.网站最前端的负载均衡层称之为Director,它起的是分摊请求的作用,最常见的就是轮询。
二、F5是通过硬件的方式来实现负载均衡,它较多应用于CDN系统,用于squid反向加速集群的负载均衡,是专业的硬件负载均衡设备,尤其适用于每秒新建连接数和并发连接数要求高的场景;LVS和Nginx是通过软件的方式来实现的,但稳定性也相当强悍,在处理高并发的情况也有相当不俗的表现。
三、Nginx对网络的依赖较小,理论上只要ping得通,网页访问正常,nginx就能连得通,nginx同时还能区分内外网,如果是同时拥有内外网的节点,就相当于单机拥有了备份线路;lvs就比较依赖于网络环境,目前来看服务器在同一网段内并且lvs使用direct方式分流,效果较能得到保证。
四、目前较成熟的负载均衡高可用技术有LVS+Keepalived、Nginx+Keepalived,以前Nginx没有成熟的双机备份方案,但通过shell脚本监控是可以实现的,有兴趣的可具体参考我在51cto上的项目实施方案;另外,如果考虑Nginx的负载均衡高可用,也可以通过DNS轮询的方式来实现,有兴趣的可以参考张宴的相关文章。
五、集群是指负载均衡后面的web集群或tomcat集群等,但现在的集群意义泛指了整个系统架构,它包括了负载均衡器以及后端的应用服务器集群等,现在许多人都喜欢把Linux集群指为LVS,但我觉得严格意义上应该区分开。
六、负载均衡高可用中的高可用指的是实现负载均衡器的HA,即一台负载均衡器坏掉后另一台可以在<1s秒内切换,最常用的软件就是Keepalived和Heatbeat,成熟的生产环境下的负载均衡器方案有Lvs+Keepalived、Nginx+Keepalived。
七、LVS的优势非常多:①抗负载能力强;②工作稳定(因为有成熟的HA方案);③无流量;④基本上能支持所有的应用,基于以上的优点,LVS拥有不少的粉丝;但世事无绝对,LVS对网络的依赖性太大了,在网络环境相对复杂的应用场景中,我不得不放弃它而选用Nginx。
八、Nginx对网络的依赖性小,而且它的正则强大而灵活,强悍的特点吸引了不少人,而且配置也是相当的方便和简约,小中型项目实施中我基本是考虑它的;当然,如果资金充足,F5是不二的选择。
九、大型网站架构中其实可以结合使用F5、LVS或Nginx,选择它们中的二种或三种全部选择;如果因为预算的原因不选择F5,那么网站最前端的指向应该是LVS,也就是DNS的指向应为lvs均衡器,lvs的优点令它非常适合做这个任务。重要的ip地址,最好交由lvs托管,比如数据库的ip、webservice服务器的ip等等,这些ip地址随着时间推移,使用面会越来越大,如果更换ip则故障会接踵而至。所以将这些重要ip交给lvs托管是最为稳妥的。
十、VIP地址是Keepalived虚拟的一个IP,它是一个对外的公开IP,也是DNS指向的IP;所以在设计网站架构时,你必须向你的IDC多申请一个对外IP
十一、在实际项目实施过程中发现,Lvs和Nginx对https的支持都非常好,尤其是LVS,相对而言处理起来更为简便。
十二、在LVS+Keepalived及Nginx+Keepalived的故障处理中,这二者都是很方便的;如果发生了系统故障或服务器相关故障,即可将DNS指向由它们后端的某台真实web,达到短期处理故障的效果,毕竟广告网站和电子商务网站的PV就是金钱,这也是为什么要将负载均衡高可用设计于此的原因;大型的广告网站我就建议直接上CDN系统了。
十三、现在Linux集群都被大家神话了,其实这个也没多少复杂;关键看你的应用场景,哪种适用就选用哪种,Nginx和LVS、F5都不是神话,哪种方便哪种适用就选用哪种。
十四、另外关于session共享的问题,这也是一个老生长谈的问题了;Nginx可以用ip_hash机制来解决session的问题,而F5和LVS都有会话保持机制来解决这个问题,此外,还可以将session写进数据库,这也是一个解决session共享的好办法,当然这个也会加重数据库的负担,这个看系统架构师的取舍了。
十五、我现在目前维护的电子商务网站并发大约是1000左右,以前的证券资讯类网站是100左右,大型网上广告大约是3000,我感觉web层的并发越来越不是一个问题;现在由于服务器的强悍,再加上Nginx作web的高抗并发性,web层的并发并不是什么大问题;相反而言,文件服务器层和数据库层的压力是越来越大了,单NFS不可能胜任目前的工作,现在好的方案是moosefs和DRDB+Heartbeat+NFS;而我喜欢的Mysql服务器,成熟的应用方案还是主从,如果压力过大,我不得不选择oracle的RAC双机方案。
十六、现在受张宴的影响,大家都去玩Nginx了(尤其是作web),其实在服务器性能优异,内存足够的情况下,Apache的抗并发能力并不弱,整个网站的瓶颈应该还是在数据库方面;我建议可以双方面了解Apache和Nginx,前端用Nginx作负载均衡,后端用Apache作web,效果也是相当的好。
十七、Heartbeat的脑裂问题没有想象中那么严重,在线上环境可以考虑使用;DRDB+Heartbeat算是成熟的应用了,建议掌握。我在相当多的场合用此组合来替代EMC共享存储,毕竟30万的价格并不是每个客户都愿意接受的。
十八、无论设计的方案是多么的成熟,还是建议要配置Nagios监控机来实时监控我们的服务器情况;邮件和短信报警都可以开启,毕竟手机可以随身携带嘛;有条件的还可以购买专门的商业扫描网站服务,它会每隔一分钟扫描你的网站,如果发现没有alive会向你的邮件发警告信息或直接电话联系。
十九、至少网站的安全性问题,我建议用硬件防火墙,比较推荐的是华赛三层防火墙+天泰web防火墙,DDOS的安全防护一定要到位;Linux服务器本身的iptables和SElinux均可关闭,当然,端口开放越少越好。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
ArchSummit分享 | 高德地图App架构演化与实践
讲师介绍 郝仁杰,高德地图无线开发专家。在7月13日落幕的2019年ArchSummit峰会上就高德地图近几年的App架构演化和实践进行了分享。 背景概述 高德是国内领先的数字地图内容、导航和位置服务解决方案提供商,端上分手机和车机两条主线。近年来,高德业务迅猛发展,人员规模急速扩张,代码量急剧膨胀,如何提高团队高效并行作战的能力,端架构在一致性和动态性方面做了很多尝试:从最初的双端原生单体架构,到地图引擎下沉C++,再到动态UI框架的建设,收到了一定的成效,但面对业务持续的高速发展,依然还有很多方面需要继续完善。 为了让业务开发有节奏的进行,项目上每年会制定一些公车计划。公车就是每个App版本,货物就是对应的产品功能,货物组装就是功能开发,公车计划即每年的发版计划,公车按照指定的时间来,把组装好的货物拉走。但由于双端代码差异较大、耦合严
- 下一篇
Visual Studio Code 远程开发探秘
摘要: IDE新时代! 作者:SHUHARI 的博客 原文:Visual Studio Code 远程开发探秘 Fundebug按照原文要求转载,版权归原作者所有。 在以前的文章 有趣的项目 - 在浏览器中运行 Visual Studio Code, 我介绍过 Coder 开发团队将 Visual Studio Code 搬到浏览器里的尝试。这是一个有趣的项目,不过没有想到的是,这之后不久微软官方就推出了 VSCode 的远程开发扩展,这简直是官方逼死同人的节奏。从 Coder 官网 的信息来看,他们似乎已将精力主要放到企业版本,这应该算一个生不逢时的产品吧。今天我们来介绍一下微软自己基于 VSCode 的远程开发平台。 工作原理 从原理上讲,VSCode 远程开发扩展相当于把开发者自己机器上的 VSCode 原样拷贝到作为目标机器(Remote Host)上,以服务的形式运行,而本地的 VSCode 作为客户端,两者之间通过远程通讯协议彼此协调合作,实际上的开发工作主要是在服务端完成的。这个架构特别之处在于,我们日常所使用的扩展也被分成两个阵营:和界面定制相关的部分,主要包括样式、主...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- Red5直播服务器,属于Java语言的直播服务器
- CentOS8安装Docker,最新的服务器搭配容器使用
- Docker安装Oracle12C,快速搭建Oracle学习环境
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- CentOS7设置SWAP分区,小内存服务器的救世主
- CentOS7安装Docker,走上虚拟化容器引擎之路
- CentOS7,8上快速安装Gitea,搭建Git服务器
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题