- 浏览: 482071 次
- 性别:
- 来自: 北京
文章分类
最新评论
-
alvin198761:
renzhengzhi 写道我参与过12306余票查询系统的开 ...
别给12306 辩解了 -
renzhengzhi:
我参与过12306余票查询系统的开发,用户请求被前面3层缓存拦 ...
别给12306 辩解了 -
renzhengzhi:
写的很好。
JAVA线程dump的分析 -
liyonghui160com:
说好的附件呢
分布式服务框架 Zookeeper -- 管理分布式环境中的数据 -
ghpaas:
orbeon作为xforms标准的实现,不论其设计器还是运行时 ...
XForms 1.1 中文翻译—第1章 关于XForms标准
文 / 李晓栋 记得上大学时,我和好友老郭讨论最多的话题便是:“像新浪这样的网站是如何支撑如此巨大的访问量?”也曾通过各种手段,猜测新浪服务器的数量、操作系统和应用软件的版本……一切都是那么神秘。毕业那年,有幸加入新浪,终于一点点地揭开了这层神秘的面纱。2004年某厂商设备介绍会上,我初次接触到了负载均衡技术。之后的几年时间,可以说是负载均衡设备在网站推广的黄金爆发期。 发展到今天,一方面硬件设备依然保持了强劲的实力,另一方面以LVS、Haproxy为代表的软件负载均衡也异军突起,被人们所认可。在新浪,软、硬件负载均衡并存的格局已有三年多的历史了,除了既往积累的经验外,近一年来,我们也看到了负载均衡所面临的一些新挑战,在此跟大家分享。 挑战一:Web应用对七层交换的依赖度越来越大,显著增加了负载均衡器的压力。 七层交换技术的引入,极大地解放了架构师和程序开发人员,同时也使我们越来越习惯依赖于它,甚至直呼上瘾。很难想象,如果没有负载均衡器的话,现有Web架构中的大量需求应该如何实现? 在充分享受其便利性的同时,我们也看到了一些隐忧。一方面越来越多的流量正从四层交换转为七层交换;另一方面七层交换的规则也越来越趋于复杂。在双重作用下,负载均衡器的压力急剧上升。对于任何一台负载均衡器来说:支撑相同的请求量,七层交换所消耗的CPU要远远高于四层交换。特别是在瞬间高并发连接的突发流量面前,负载均衡器面临着严峻的挑战。 挑战二:微博等互联网新兴产品的出现,对负载均衡器的运维工作提出了更高的要求。 微博不仅改变着亿万网民的生活,而且也正悄然推动着运维体系的建设。 首先,与传统的新闻、博客相比,微博用户对服务质量的敏感度更高,而且这种敏感度会伴随着一次次的“@”和“转发”传播扩散。在过去,当用户访问新浪服务感到慢时,反映的渠道多是打客户电话。而现在只需要在微博上一个简单的“@” 就可以与新浪的客服和技术人员直接沟通。作为流量进出的一个关卡,当微博等线上关键业务出现访问异常或故障时,工程师们都迫切地想知道:是负载均衡器的问题吗?此时故障诊断的效率显得至关重要。在实际工作中我们发现:单纯依靠负载均衡器提供的CPU、内存、连接数等统计信息,还不足以发现一些隐蔽问题。传统的抓包分析耗时耗力且效果不佳,再加上有些故障现象与客户端、后台服务器上的某些特殊设置有着千丝万缕的联系,所有这些交织在一起,给我们故障诊断带来了不小的挑战。例如有次我们发现:负载均衡器偶尔会给客户端返回HTTP 5xx的响应,当时特想快速地知道究竟是什么样的HTTP请求会触发这样的现象。但可惜的是,负载均衡器上仅有统计数字而没有请求的完整记录。在花了很大力气抓包分析后,最终定位到是由于后台一个PHP程序不小心给页面设置了一个错误的HTTP Header,导致Web Server的HTTP响应不能被负载均衡器所接受,最终给客户端返回5xx。因此在故障诊断方面,我们需要有更先进的理念和手段。 其次,微博在国内正处于快速成长期,会随时根据访问量来灵活调整服务器的数量和系统架构。在这种快速灵活的变化面前,负载均衡器相关的配置调整工作也随之增加:频繁的上下线服务器、变更七层规则等。面对这种情况,我们需要思考:如何能更加快速安全地完成好这些变更、如何能避免工程师每天被动地陷入这些重复烦琐的工作中等。目前一些硬件设备提供了API接口,像增删Server、调整Server 权重等这类风险性极低的操作可通过API接口操作,以达到提高效率的目的。而Haproxy、LVS则缺乏这样的 API接口,需要单独开发。 除此之外,关键应用对负载均衡器的监控也有越来越多的新需求。比如:有些应用希望当负载均衡器检测到服务器池中活跃的服务器数量少于一定比例后,便提前给系统管理员作出预警;及时发现服务器池中权重等设置不合理的问题等。 挑战三:多核处理器时代下,Haproxy等用户态的软件负载均衡正面临新的性能瓶颈。 近几年来CPU发展进入了多核时代,CPU由过去的单核发展到四核、六核、八核、十二核,甚至更多,而主频则变化不大。在这种趋势下,充分利用多核特性显得尤为重要。但在我们研究中发现,像Haproxy这类基于用户态的软件负载均衡,其对CPU主频的依赖度要远远高于CPU核数。换言之,在高主频、核数少CPU下的性能很有可能要优于低主频、核数多的CPU。这一点,在Haproxy服务器选型时尤为重要。据我们分析,这主要是由于操作系统对多核(多CPU)下的并发支持度还不够好。 挑战四:软件负载均衡发展路上的“鸡蛋-篮子”理论的艰难选择。 硬件负载均衡器往往以单台高性能著称,而Haproxy、LVS为代表的软件负载均衡的优势则在于成本低廉、可灵活定制,其性能与服务器CPU、网卡等硬件直接相关(当然特殊的优化也很重要)。正如前面提到的,当七层交换流量越来越大时,我们究竟是该投入成本让单台LVS、Haproxy足以支撑如此大的流量,还是让更多中等性能的服务器共同分担这些流量呢?这就是所谓的经典的“鸡蛋-篮子”理论:究竟该不该将鸡蛋放到一个篮子里呢? 其实不同的选择各有利弊。2~3年前,我比较赞同将流量分摊到多台软件负载均衡器上,当时主要考虑到风险的分散。而现在,我更倾向于将流量集中于一台上。之所以这样,是从以下四个角度考虑的。 第一,目前国内IDC内每个机架所放服务器数量跟电力配额直接相关。而负载均衡由于其特殊性,往往是两台为一组,这样每增加一组都会增加额外的电力开销,特别是在电力资源紧张的IDC内,提高单台软件负载均衡器的承载能力可以为关键业务腾出更多的机架来。 第二,从服务稳定角度考虑,我们通常会将LVS、Haproxy直连核心交换机,如此一来,每增加一组,就意味着会占用更多的核心交换机端口资源。 第三,是基于管理成本的考虑。LVS、Haproxy之所以能在新浪得到广泛应用,较低的管理成本是重要原因之一。在新浪我们通过一套集中管理平台和快速初始化的办法实现了运维成本的非线性增加。但不可否认的是,每新增一组,运维成本或多或少总会增加一些。之前也曾设计过一套“同机房内负载均衡器的集群池方案”,即:在一个机房内主备机的数量比不再固定为1:1, 虚拟IP(VIP)会根据集群池中每台Haproxy/LVS的负载状况,动态地“漂”在其中某台上。但后来发现这个“听起来很美”的方案,在实际运行中遇到了种种问题,运维成本不降反升。最终我们又回归了传统的1台Active+1台Standby的模式,正所谓简单即是美。 第四,目前硬件负载均衡器正朝着“更高的性价比”方向发展,换句话来讲,如果我们不提升软件负载均衡器的单机支撑能力,则终有一天,其与硬件设备相比的成本优势将会淡去。 挑战五:在新时期下,如何找到负载均衡的最佳软硬结合之道? 朋友、同行聚会时,常有人问我:“你们有了Haproxy、LVS后,会不会不买硬件设备了?”、“你最近又在山寨什么?”每次听到这些,我都会微微一笑。如前文所述,Haproxy、LVS这类的软件负载均衡和硬件设备各有优势,在我看来,负载均衡的“软”、“硬”解决方案并非水火不容,只要找到最佳的软硬结合之道,鱼和熊掌还是可以兼得的。下面是我们在长期摸索中,总结出来的一些经验。 软件负载均衡可优先承担四层交换流量,让硬件设备更专注于七层交换:由于工作方式和原理的不同,专注于四层交换的LVS在稳定性、单机支撑能力、易维护性、管理成本等多方面均要大大优于Haproxy。特别是在DR模式(即单臂)下, 单台LVS足以应对绝大多数业务的访问量。 优先保障“明星”产品占用宝贵的硬件设备资源:这里指的“明星产品”是指那些用户群正处于快速增长,并被广泛追捧的热点互联网产品,例如微博。考虑到负载均衡器一旦发生异常或宕机后,将对产品的美誉度和用户体验产生一定程度的影响,这属于无形成本的损失。正所谓“好钢要用在刀刃上”,我们可以优先将这类流量放到硬件负载均衡器上。 对于必须采用七层交换的重点服务来说,尽量避免同一重点服务的流量全部放在软件负载均衡器上。例如某重点服务分布于四个IDC内,则可考虑两个IDC内使用Haproxy,另外两个IDC使用硬件设备。这样一方面可以在一定程度上规避使用Haproxy可能带来的风险,另一方面也方便对软、硬件负载均衡器的稳定性、响应时间等进行长期对比观察。 要充分利用好同一IDC内的软、硬件负载均衡器,当一方负载高时,另一方可协助其分担流量,缓解燃眉之急。 总而言之,在负载均衡方面的支出正所谓该花则花、该省则省,合理使用可以让你在保障服务稳定的前提下,获得最佳的投入产出比。 挑战六:软件负载均衡器的资源复用,在降低成本的同时,同时也面临着一定的运维风险。 目前我们的软件负载均衡器分布于全国各地,其中一些中小规模IDC内的软件负载均衡器的负载并不是特别高,而这些机房普遍又需要VPN、自动安装等服务,单独为这些服务再放1~2组服务器显得很不划算。因此我们想到对软件负载均衡器进行资源的复用,即:在软件负载均衡器上同时运行VPN等服务。在实际中发现,这种资源复用面临两方面的风险:一是VPN、自动安装、负载均衡可能分属于不同的管理员,这样大家对同台服务器进行操作会增大因配置冲突、操作不当等导致的服务间互相影响的概率;二是非负载均衡的服务可能会突发占用过多的CPU或网络资源,对正常的负载均衡服务造成了一定的影响。由于LVS、Haproxy服务的特殊性,像Xen这类通过虚拟化来实现资源隔离的办法又不太适用;对服务器流量进行QOS设置,虽然可以起到一定的效果,但配置方面还是有些烦琐。还有更好的办法吗?这确实值得我们思考。 当然除了以上六方面挑战外,负载均衡领域还有很多值得研究之处。不同网站有不同的实际情况,希望本文能对大家起到抛砖引玉的作用。 作者简介: 李晓栋,新浪网研发中心基础架构部技术经理、集团金牌讲师。在新浪有6年多的系统、网络、安全相关工作经验,现负责新浪网络设备和操作系统相关研发工作。自2007年9月以来带领团队研发了新浪DDOS防火墙、广域网加速器、软件负载均衡管理系统、网页挂马检测系统等重要产品, 为公司节约成本上千万元。 (本文来自《程序员》杂志10年11期)
发表评论
-
高性能、高流量Java Web站点打造的最佳实践
2013-12-24 11:23 2812从2005年-2013年,Ashwanth Fernando ... -
高性能、高流量Java Web站点打造的最佳实践
2013-12-24 11:01 4从2005年-2013年,Ashwanth ... -
20行实现javascript模板引擎
2013-12-23 10:35 150820行实现javascript模板引擎 我仍然在用Abs ... -
标题怎么办
2012-03-25 23:50 21.首先在这里 下载Selenium RC,解压到C盘。 ... -
Google Page Speed应用上线,移动设备也在支持之列
2011-04-05 21:23 855Google已经将Page Speed应用到线上,并且加强 ... -
浏览器的加载与页面性能优化
2011-02-16 11:23 1315本文将探讨浏览器渲染的loading过程,主要有2 ... -
使用 JAWS 测试 Web 应用的技巧
2010-10-31 23:34 1633屏幕阅读器简介 屏幕阅读器(S ... -
How We Evaluate the Experiences We Engineer
2010-10-26 14:38 7159 and how we measured (and co ... -
研究显示:众多网上零售商未遵循Web优化基本准则
2010-10-26 10:25 696Web优化专家Joshua Bixby最近在博客中披露,在 ... -
Testing sites with Browser Mode vs. Doc Mode
2010-10-22 10:07 1066With site developers verifying ... -
Common Security Mistakes in Web Applications
2010-10-22 10:02 1693Web application developers toda ... -
A (somewhat) brief history of the performance landscape
2010-10-21 10:44 1710I’d like to enlist your help. ... -
Best Practices for Speeding Up Your Web Site
2010-10-20 10:40 1205Minimize HTTP Requests tag: ... -
Web Performance Optimization Use Cases – Part 1 Benchmarking
2010-10-19 14:40 939Web Performance Optimizatio ... -
Google WebP——让图片更小,让页面访问速度更快
2010-10-12 13:14 1586Google日前对外宣布了一种新的图片压缩格式WebP,可 ... -
剖析IE浏览器子系统的性能权重
2010-09-02 13:23 873最近,InfoQ中文站报道了Web 2.0应用客户端性能问 ... -
Performance: Profiling how different web sites use browser subsystems
2010-09-02 00:41 1205When we first showed IE9 at t ... -
Measuring Browser Performance: Understanding issues in benchmarking and performa
2010-09-02 00:40 945Measuring Browse ... -
Ajax应用开发:实践者指南
2010-08-10 21:13 977目前的Web应用开发基本上都是围绕富互联网应用(Rich ... -
全面提升 Web 2.0 应用程序的性能,第 3 部分: 浏览器渲染时间分析
2010-08-03 11:10 1039谁在调用运行时间最长的方法? 简化的浏览器响应时间 ...
相关推荐
负载均衡技术可以应用于各种类型的网站,包括静态网站、动态网站、门户网站、电商网站等。 负载均衡技术的优点: 1. 提高网站的可用性:通过分配访问负载,减少了单个服务器的负载,从而提高了网站的可用性。 2. ...
六、负载均衡的挑战与解决方案 1. 会话保持(Session Persistence):保持用户会话在同一服务器上,通常通过cookie或IP哈希实现。 2. 避免单点故障:通过集群部署,即使主负载均衡器故障,也能切换到备用。 3. 健康...
随着云计算和容器化技术的普及,软件定义的负载均衡(如Kubernetes的Service)成为了新的趋势,它允许在虚拟化环境中动态调整资源分配,实现自动扩展和收缩,极大地提高了系统的弹性和可管理性。此外,基于AI和机器...
负载均衡技术是一种网络架构策略,旨在优化系统性能和可用性,通过分散网络流量,确保没有单一设备承受过重的工作负载。该技术广泛应用于Web服务器、FTP服务器和其他关键任务服务器,以提高Internet服务器程序的可...
天融信负载均衡配置手册 一、负载均衡的概念 在讨论天融信负载均衡系统之前,我们需要了解什么是负载均衡。负载均衡是指将incoming网络流量分布到多个服务器上,以提高服务器的可用性、可靠性和灵活性。负载均衡...
讨论了云计算下负载均衡技术,讨论了云计算下负载均衡技术,讨论了云计算下负载均衡技术,讨论了云计算下负载均衡技术,讨论了云计算下负载均衡技术,讨论了云计算下负载均衡技术
负载均衡是一种有效提升网站性能和稳定性的技术,尤其在应对云环境和大数据所带来的挑战时。它能够通过将网络或应用流量分配到多个服务器,提高系统的响应速度和吞吐量,同时避免单点故障。在介绍负载均衡技术之前,...
负载均衡技术是一种广泛应用的技术,目的在于将服务的并发请求平均分配到后端多个具有相同处理能力的服务节点上进行处理,从而以一种廉价且有效透明的方式扩展网络设备或服务的带宽,增加吞吐量,增强服务的整体处理...
负载均衡技术是现代软件工程和架构设计中的关键组成部分,尤其对于构建高可用、高性能的网站系统至关重要。在本文中,我们将深入探讨负载均衡的基本概念、重要性以及如何通过实际应用来优化网站性能。 首先,我们...
《实用负载均衡技术:网站性能优化攻略》这本书深入探讨了如何通过负载均衡技术提升网站的性能和稳定性。负载均衡是现代互联网架构中的关键组件,它能够有效地分散服务器压力,提高服务可用性,确保用户访问体验。...
负载均衡技术是一种用于优化网络性能、提高可用性和扩展性的关键技术。...随着技术的发展和互联网应用的普及,负载均衡技术越来越成熟,应用也日益广泛,对于保障大规模网站的稳定运行起到了重要作用。
负载均衡技术是网络架构中的重要组成部分,其主要目标是确保网络服务的稳定性和高可用性。通过对网络流量的管理和分配,负载均衡可以在多台服务器之间有效地分摊工作负载,提高系统的处理能力,同时减少单个服务器的...
服务器负载均衡技术是一种网络优化策略,旨在通过将网络流量分散到多台服务器上,提高系统的稳定性和可用性,同时增强处理大规模并发请求的能力。负载均衡技术的核心思想是将客户端的请求均匀分配到服务器集群,避免...
在构建大型网站时,负载均衡是一项至关重要的技术,它能够有效地分发网络流量,提高系统的可用性和响应速度,同时还能确保服务的连续性。本文将深入探讨负载均衡的原理、类型以及在实际应用中的实现方式。 一、负载...