码/视频评论后加前端学习群470593776
知识点:原生js动画效果 ,重力系统+元素弹跳算法, 递归在特效中的应用,
两种定时器配合使用,编程思想与解决方案思维
由于现在面试中,对于原生JS的要求越来越高,所以本次分享,都是使用的原生js来实现效果!
源码/视频评论后加前端学习群470593776
源码/视频评论后加前端学习群470593776
TML 5虽然只是一个技术标准,但是眼下更多承载着颠覆苹果与谷歌移动生态的理想。我并不想单纯从技术角度谈论HTML5的现实处境,因为技术从来不会成为发展的绝对瓶颈,尤其是HTML 5本身就不存在任何重大的技术难题。反而“商业”成了HTML 5发展无法逾越的鸿沟。只可惜“商业”从来都掺杂大量的投机成分,当然也有商业政治的成分。
HTML5所谓的“标准定稿”在我看来只是一场公众秀。HTML 5标准自始至终就不是W3C组织一家的自留地,更不是唯一的代言人。原本W3C组织对外宣传“要到2022年才会完成HTML 5正式标准的颁布”,现在为何又如此匆忙的定稿?这种定稿真的会对移动开发产生多大影响?
最纠结的10%
真正一直关心HTML 5的人会记得2012年7月的一个重大新闻,HTML5的两个标准组织W3C和WHATWG因为“理念不合”决定分道扬镳,这被看成一场IT界的商业政治事件。二者的根本理念差异是WHATWG认为HTML 5应该成为一个动态的标准既Living Standard,而W3C则认为应该形成一个固定的标准。导致这场事件升级的真正原因并不是“理念”这么简单,而是二者各自代表的利益集团背后的推手。WHATWG向W3C叫板的底气,正是来自Mozilla、苹果和Opera的支持。W3C则选择了微软。
HTML5标准本身涉及的技术并无任何障碍,但是之前迟迟无法定案的原因则是错综复杂,缓慢的进度除了再一次证明这些组织是超级低效机构之外,所谓的利益和政治博弈才是直接导致了进度缓慢的真正原因。实际上截止2013年90%以上的HTML 5的标准早已完成,剩下的部分恰恰是各大利益集团博弈的重点,此次W3C代为发声,明显生米煮成熟饭的意味,这真的会奏效么?答案是完全否定的!因为各大金主不会因为一场PR活动就放弃自己的利益。
那么对开发者和技术用户而言,W3C所谓的标准定案到底意味着什么?是否可以从中获益?到底该如何看待这一“进步”?
这一切还要从W3C与WHATWG的分歧开始,动态标准还是固定的标准更适合开发者?我想,答案或许是WHATWG的Living Standard!因为没有动态的标准,就不会有HTML 5的未来。未来HTML5想得到真正的发展,核心问题并不是标准哪天定稿亦或是浏览器性能不足,关键在于两点,一是持续改进,二是生态。
龟速迭代
如果没有一个持续改进的标准和为此而不断努力的组织,HTML 5就只能把颠覆App生态当成一句口号,永远充当配角。因为生态革新速度要远大于开发者的行动速度。
IT world已经完全不是10年前的样子,Cloud/Client“云与端”快速蚕食着传统B/S架构(浏览器到服务器)的空间。端不特指“手机端”而是更广泛的包含“pad端”“PC端”甚至“手表端”“汽车端”“家电端”等等。而相比PC时代,更多端的出现,代表着更多的硬件组合以及更多业务场景和功能。我们一直诟病W3C等标准组织行动缓慢,这次标准的公布很明显没有解决任何“云与端”复杂性的解决方案。我们设想一下:
场景A:以iphone的touchID为代笔的生物识别功能在各种端上兴起,继而产生了大量新的API,甚至可能今后带有硬解的虹膜识别、声纹识别等终端能力,在一个固定的HTML5标准下如何解决?HTML5附带的device API甚至只涵盖了feature phone时代的基础通讯录、摄像头等功能,今天出现的touchID均无法有效调动,更何况2、3年后我们无法认知的新功能的标准配套实现。这种情况下不发展的HTML 5标准代表着“弱功能”
场景B:智能硬件的发展对蓝牙和wifi使用以及驱动的需求迅猛增长,而HTML 5配套的对蓝牙3.0驱动的支持标准何在?可以遵照标准的HTML 5亦或是配套的标准以及协议在浏览器内连接大部分的智能硬件么?答案当然也是全然否定的。这种未来最常见的常见之一都无法实现,那些大谈HTML 5将会取代APP的人恐怕又会说“这些不是HTML 5擅长的,这种举例毫无疑义”。那请问HTML 5擅长的只是排版布局和阅读类亦或者一些低价游戏的APP么?更不要说对于NFC等很快可能成为终端标配的系统新能力,所以定稿后不发展的HTML 5标准代表着“弱扩展”
其实,这一切基于HTML 5的论点并非没有明确的解决方案,简单来说所谓的HTML 5定稿只是闹剧和PR,如果真正期盼HTML 5挑战App生态,一定要出现一个不停发展的动态标准,才能够具备上场参赛的基础。只是这倚重的是标准背后的“推手”和“金主”,那些想打造自己生态王国的大玩家。作为WHATWG的重要支柱,苹果公司一直在低调中快速发展着自身的Web App技术,到今天为止,在iOS中已经有比Android和其他操作系统更成熟和完美的围绕HTML 5和Web App的支持,只是遗憾的是苹果公司只是把HTML 5当成技术,而没有为打造HTML 5的生态做出任何其他的努力。
推不动的生态
2013年是HTML 5最低调的一年,因为在此前一年,众多打击接踵而至,除了用户对HTML 5普遍负面的反馈之外,最严重的一次事件就是Facebook的彻底反水!
扎克伯格:我们过去最大的错误就是在HTML 5上面赌太大!
曾几何时,面对HTML5扎克伯格野心勃勃的推动着“复制Facebook在PC端生态和霸权计划”。众所周知,苹果的生态系统是相当封闭的,Android虽然开放但是也全面复制着苹果的玩法iOS->Developer->APP->Appstore->User。所以Facebook全面推进HTML 5,妄图跳开移动操作系统的掌控,拥抱HTML5和www的开放流量体系。
但是即便是Facebook如此重量级的玩家,最后也认栽了。无独有偶,Linkedin作为又一风向标,在2013年也同样放弃了HTML 5重新拥抱APP。到今天,难道短短的一年多,世界就发生了彻底的改变,HTML 5又重新具备了王者的气质?当然是不可能的,世界上各个IT王国都没有改变,改变的只是时间。
根据Flurry的报告,相比去年,2014年用户在移动端的使用APP的份额进一步上升突破80%,而手机网站的使用情况进一步被挤压。这说明用户市场没有将APP升级和下载当成多大的困难(至少没你想像的那么困难),并且随着App store更加人性和智能化的帮助用户在wifi环境下自动升级等机制的普及,APP在使用上对用户来说门槛越来越低,反而基于HTML5的Web App的使用和获取倒是成了用户的障碍。手机浏览器的用户留存和使用情况越来越不乐观,这个最重要的HTML 5的载体正在失去活力,反而大家寄望于超级APP,微信在中国眼下成了一根救命稻草。
当然想基于超级APP的形式打造自身闭环生态的厂商不止Facebook一家,反观国内试水的大公司也很多,但均以鸣金收兵结尾。从UC的web app商店到百度的轻应用,构建基于移动web流量的生态系统无一成功。目前造成这种局面原因众多,例如浏览器性能不足、HTML 5标准未定稿、无有效的web app发行渠道等等,但是正如我3年前说的,最核心的问题是移动开放流量体系和原生生态系统的对抗。
目前用户从App store去搜索和下载app,在桌面存留app入口点击使用,这已经成了iOS与Android生态系统下的固定模式。反而让用户进入超级APP,再通过搜索或连接的方式进入一个第三方web app,无论是从操作流程还是用户最终体验都无法和操作系统层级的体验抗衡。而HTML 5标准定稿没有为这种生态的困难带来任何一点的改变,所以说HTML 5在W3C操纵下的所谓标准定稿,只是一场PR的闹剧,虽然搅动了市场,但是也刺激了一批从业者充当炮灰。
期待新玩家
打造移动开放平台和生态系统,微信是佼佼者,并且成功将部分App的流量转化成了Web app的流量。微信也一路创新了导流手段,没有选择用户网址输入、也没有选择用户搜索进入web app,而是把账号变成网址并且直接收藏的方式,形成了一个特殊的“web app浏览器”。在打通了流量后又恰当的加入了支付手段,不但盘活了流量也让流量变得更加有价值。
这给HTML 5开发者带来了希望,不过很快又很失望,因为开发者发现微信对流量的管控超乎预期。这让我想到了SNS时代开放平台玩死众多social game厂商的过去。中国有大的互联网开放平台,曾经的腾讯、人人甚至淘宝。但是总结规则无一不是“貔貅原则”流量只进不出,所谓的盘活流量只是为自身生态服务,虽然这样无可厚非,只是对于开发者来说把自己的梦想嫁接在“中国版的开放平台上”无异于“与虎谋皮”。因此HTML 5生态的建立或许可以借助开放平台,但是真正可以对抗原生生态的HTML 5需要的是类似于WebOS这种更彻底的变革。
开发者对于HTML5的定稿,心态大可保持平和,短期内不会带来任何的实质性改变。浏览器特别是操作系统厂商也不会因为W3C标准的定稿而放弃一直维护的自身利益,该支持的早已经支持,不该支持的也不会遵照标准去支持。只是HTML 5作为进步的一代标准,抛开利益和政治的博弈,还是会给开发者带来更多的价值。只要不盲从,以学习的心态积极对待,仍会从中获益。
HTML 5和配套的web开发技术具有跨平台、低门槛的特性,目前大量的APP中广泛使用了HTML5配合native development原生开发,极大的降低了APP整体的开发成本,更有一些移动应用引擎使用Javascript和HTML 5开发跨平台native app,在不触碰iOS与Android生态利益的前提下,发挥实用的价值。因此只要回归到技术本身,把HTML 5技术应用到可以使用的场景中充分发挥价值,就可以逐步迎接更光明的未来。
2年前,移动开发领域掀起过一次行业大辩论“web app和native app谁死谁活”的问题。今天这个问题依然是一个有价值的问题。所以下一篇是,HTML 5盛宴(二):再论Web app和Native app的未来。
本文作者刘鑫,移动云服务APICloud创始人兼CEO,从SP梦网时代就开始持续关注移动Web开发,个人邮箱hi.seanliu@yahoo.com
除非注明,本站文章均为原创或编译,转载请注明: 文章来自 36氪
36氪官方iOS应用正式上线,支持『一键下载36氪报道的移动App』和『离线阅读』立即下载!
今,在各种互联网应用中,随着站点对硬件性能、响应速度、服务稳定性、数据可靠性等要求也越来越高,单台服务器也将难以无法承担所有的访问需求。
图片来自 Pexels
当然了,除了使用性价比高的设备和专用负载分流设备外,还有一些其他选择来帮你解决此问题,就是搭建集群服务器通过整合多台普通的服务器设备并以同一个地址对外提供相同的服务。
今天就带大家学习企业中常用的一种群集技术 LVS:
什么是 LVS?
LVS 是 Linux Virtual Server 的简写,也就是 Linux 虚拟服务器,是一个虚拟的服务器集群系统,本项目在 1998 年 5 月由章文嵩博士成立,是中国国内最早出现的自由软件项目之一。
官方网站:http://www.linuxvirtualserver.org,LVS 实际上相当于基于 IP 地址的虚拟化应用,为基于 IP 地址和内容请求分发的负载均衡提出了高效的解决方法,现在 LVS 已经是 Linux 内核标准的一部分。
使用 LVS 可以达到的技术目标是:通过 LVS 达到的负载均衡技术和 Linux 操作系统实现一个高性能高可用的 Linux 服务器集群,具有良好的可靠性、可扩展性和可操作性,从而以低廉的成本实现最优的性能。
LVS 是一个实现负载均衡集群的开源软件项目,LVS 架构从逻辑上可分为调度层、Server 集群层和共享存储层。
为什么要用 LVS?
那为什么还需要用 LVS 呢?随着 Internet 的爆炸性增长以及日常生活中的日益重要的作用,Internet 上的流量速度增长,以每年 100% 以上的速度增长。
服务器上的工作负载压力也迅速增加,因此服务器在短时间内将会过载,尤其是对于受欢迎的网站而言。
为了克服服务器的过载压力问题,有两种解决方案:
构建服务器集群的方法如下:
基于 DNS 的负载均衡集群:DNS 负载均衡可能是构建网络服务群集的最简单方法。
使用域名系统通过将域名解析为服务器的不同 IP 地址来将请求分发到不同的服务器。
当 DNS 请求到达 DNS 服务器以解析域名时,DNS 服务器将基于调度策略发出服务器 IP 地址之一,然后来自客户端的请求使用相同的本地缓存名称服务器将在指定的名称解析生存时间(TTL)中发送到同一服务器。
但是,由于客户端和分层 DNS 系统的缓存特性,很容易导致服务器之间的动态负载不平衡,因此服务器很难处理其峰值负载。在 DNS 服务器上不能很好地选择名称映射的 TTL 值。
如果值较小,DNS 流量很高,而 DNS 服务器将成为瓶颈;如果值较大,则动态负载不平衡将变得更糟。
即使 TTL 值设置为零,调度粒度也是针对每个主机的,不同用户的访问模式可能会导致动态负载不平衡,因为有些人可能从站点中拉出很多页面,而另一些人可能只浏览了几页然后转到远。
而且,它不是那么可靠,当服务器节点发生故障时,将名称映射到 IP 地址的客户端会发现服务器已关闭。
基于分派器的负载平衡集群:分派器,也称为负载平衡器,可用于在群集中的服务器之间分配负载,以便服务器的并行服务可以在单个 IP 地址上显示为虚拟服务,并且最终用户可以像单个服务器一样进行交互不知道群集中的所有服务器。
与基于 DNS 的负载平衡相比,调度程序可以按精细的粒度(例如每个连接)调度请求,以实现服务器之间的更好负载平衡。一台或多台服务器发生故障时,可以掩盖故障。
服务器管理变得越来越容易,管理员可以随时使一台或多台服务器投入使用或退出服务,而这不会中断最终用户的服务。
负载均衡可以分为两个级别,即应用程序级别和 IP 级别。例如,反向代理和 pWEB是用于构建可伸缩 Web 服务器的应用程序级负载平衡方法。
他们将 HTTP 请求转发到群集中的其他 Web 服务器,获取结果,然后将其返回给客户端。
由于在应用程序级别处理 HTTP 请求和答复的开销很高,我相信当服务器节点数增加到 5 个或更多时,应用程序级别的负载均衡器将成为新的瓶颈,这取决于每个服务器的吞吐量服务器。
LVS 与 Nginx 功能对比如下:
LVS 的组成及作用
LVS 由两部分程序组成:
作用如下:
负载均衡的由来及所带来的好处
在业务刚起步时,一般先使用单台服务器对外进行提供服务。随着后期的业务增长,流量也越来越大。
当这单台服务器的访问量越大时,服务器所承受的压力也就越大,性能也将无法满足业务需求,超出自身所指定的访问压力就会崩掉,避免发生此类事情的发生。
我们将采取其他方案,将多台服务器组成集群系统从而来提高整体服务器的处理性能,使用统一入口(流量调度器)的方式通过均衡的算法进行对外提供服务,将用户大量的请求均衡地分发到后端集群不同的服务器上。
因此也就有了负载均衡来分担服务器的压力。使用负载均衡给我们所带来的好处:提高系统的整体性能、提高系统的扩展性、提高系统的高可用性。
LVS 负载均衡集群的类型
负载均衡群集:Load Balance Cluster,以提高应用系统的响应能力,尽可能处理更多的访问请求、减少延迟为目标,从而获得高并发、高负载的整体性能。
高可用群集:High Availability Cluster,以提高应用系统的可靠性,尽可能的减少终端时间为目标、确保服务的连续性,达到高可用的容错效果。
高性能运算群集:High Performance Computer Cluster,以提高应用系统的 CPU 运算速度、扩展硬件资源和分析能力为目标、从而获得相当于大型、超级计算机的高性能计算能力。
DNS/软硬件负载均衡的类型
①DNS 实现负载均衡
一个域名通过 DNS 解析到多个 IP,每个 IP 对应不同的服务器实例,就完成了流量的调度,这也是 DNS 实现负载均衡是最简单的方式。
使用该方式最大的优点:实现简单,成本低,无需自己开发或维护负载均衡设备。
不过存在一些缺点:服务器故障切换延迟大,升级不方便、流量调度不均衡,粒度大、流量分配策略较简单,支持的算法较少、DNS 所支持的 IP 列表有限制要求。
②硬件负载均衡
硬件负载均衡是通过专门的硬件设备从而来实现负载均衡功能,比如:交换机、路由器就是一个负载均衡专用的网络设备。
目前典型的硬件负载均衡设备有两款:F5 和 A10。不过话说,能用上这种硬件负载均衡设备的企业都不是一般的公司,反而普通业务量级小的其他企业基本用不到。
硬件负载均衡的优点:
硬件负载均衡的缺点:
③软件负载均衡
软件负载均衡有如下几种:
软件负载均衡的优点:简单、灵活、便宜(直接在 Linux 操作系统上安装上述所使用的软件负载均衡,部署及维护较简单,4 层 和 7 层负载均衡可根据业务进行选择也可根据业务特点,比较方便进行扩展及定制功能)。
LVS 集群的通用体系结构
第一层:负载调度器:Load Balancer,它是访问整个群集系统的唯一入口,对外使用所有服务器共有的虚拟 IP 地址,也成为群集 IP 地址。
负载均衡器:是服务器群集系统的单个入口点,可运行 IPVS,该 IPVS 在 Linux 内核或 KTCPVS 内部实现 IP 负载均衡技术,在 Linux 内核中实现应用程序级负载平衡。
使用 IPVS 时,要求所有服务器提供相同的服务和内容,负载均衡器根据指定的调度算法和每个服务器的负载将新的客户端请求转发到服务器。无论选择哪个服务器,客户端都应获得相同的结果。
使用 KTCPVS 时,服务器可以具有不同的内容,负载均衡器可以根据请求的内容将请求转发到其他服务器。
由于 KTCPVS 是在 Linux 内核内部实现的,因此中继数据的开销很小,因此仍可以具有较高的吞吐量。
第二层:服务器池 Server Pool,群集所提供的应用服务,比如:HTTP、FTP 服务器池来承担,每个节点具有独立的真实 IP 地址,只处理调度器分发过来的客户机请求。
服务器群集的节点可根据系统所承受的负载进行分担。当所有服务器过载时,可添加多台服务器来处理不断增加的工作负载。
对于大多数 Internet 服务(例如Web),请求通常没有高度关联,并且可以在不同服务器上并行运行。因此,随着服务器群集的节点数增加,整体性能几乎可以线性扩展。
第三层:共享存储 Shared Storage,为服务器池中的所有节点提供稳定、一致的文件存储服务,确保整个群集的统一性,可使用 NAS 设备或提供 NFS (Network File System)网络文件系统共享服务的专用服务器。
共享存储:可以是数据库系统,网络文件系统或分布式文件系统。服务器节点需要动态更新的数据应存储在基于数据的系统中,当服务器节点并行在数据库系统中读写数据时,数据库系统可以保证并发数据访问的一致性。
静态数据通常保存在网络文件系统(例如 NFS 和 CIFS)中,以便可以由所有服务器节点共享数据。
但是,单个网络文件系统的可伸缩性受到限制,例如,单个 NFS / CIFS 只能支持 4 到 8 个服务器的数据访问。
对于大型集群系统,分布式/集群文件系统可以用于共享存储,例如 GPFS,Coda 和 GFS,然后共享存储也可以根据系统需求进行扩展。
LVS 负载均衡的基本原理
Netfilter 的基本原理
在介绍 LVS 负载均衡基本原理之前,先说一下 Netfilter 的基本原理。因为 LVS 是基于 Linux 内核中 Netfilter 框架实现的负载均衡系统。
Netfilter 其实很复杂也很重要,平时说的 Linux 防火墙就是 Netfilter,不过我们操作的还是 iptables,iptables 和 Netfilter 是 Linux 防火墙组合工具,是一起来完成系统防护工作的。
iptables 是位于用户空间,而 Netfilter 是位于内核空间。iptables 只是用户空间编写和传递规则的工具而已,真正工作的还是 Netfilter。
两者间的区别:Netfilter 是内核态的 Linux 防火墙机制,它作为一个通用、抽象的框架,提供了一整套的 hook 函数管理机制,提供数据包过滤、网络地址转换、基于协议类型的连接跟踪的功能,可在数据包流经过程中,根据规则设置若干个关卡(hook 函数)来执行相关操作。
它共设置了 5 个点,包括:
iptable 是用户层的工具,提供命令行接口,能够向 Netfilter 中添加规则策略,从而实现报文过滤,修改等功能。
通过下图我们可以来了解下 Netfilter 的工作机制:
当数据包通过网络接口进入时,经过链路层之后进入网络层到达PREROUTING,然后根据目标 IP 地址进行查找路由。
如目标 IP 是本机,数据包会传到 INPUT 上,经过协议栈后根据端口将数据送到相应的应用程序;应用程序将请求处理后把响应数据包发送至 OUTPUT 里,最终通过 POSTROUTING 后发送出网络接口。
如目标 IP 不是本机,并且服务器开启了 FORWARD 参数,这时会将数据包递送给 FORWARD,最后通过 POSTROUTING 后发送出网络接口。
LVS 的基本原理
LVS 基于 Netfilter 框架,工作在 INPUT 链上,在 INPUT 链上注册 ip_vs_in HOOK 函数,进行 IPVS 相关主流程。
详细原理概述如下:
①当客户端用户访问 www.baidu.com 网站时,用户访问请求通过层层网络,最终通过交换机进入 LVS 服务器网卡进入内核空间层。
②进入 PREROUTING 后通过查找路由,确定访问目的 VIP 是本机 IP 地址的话,数据包将进入 INPUT 链中。
③因为 IPVS 工作在 INPUT 链上,会根据访问的 VIP 和端口判断请求是否为 IPVS 服务,是的情况下,则调用注册的 IPVS HOOK 函数,进行 IPVS 相关流程,并强制修改数据包的相关数据,并将数据包发往 POSTROUTING 链中。
④POSTROUTING 链收到数据包后,将根据目标 IP 地址服务器,通过路由选路,将数据包最终发送至后端真实服务器中。
上面就是我们所介绍的 LVS 的工作原理,那么 LVS 负载均衡还包括三种工作模式,且每种模式工作原理都有所不同,适用于不同应用场景,其最终目的都是能实现均衡的流量调度和良好的扩展性。
LVS 负载均衡的三种工作模式
群集的负载调度技术,可基于 IP、端口、内容等进行分发,其中基于 IP 的负载均衡是效率最高的。
基于 IP 的负载均衡模式,常见的有地址转换(NAT)、IP 隧道(TUN)和直接路由(DR)三种工作模式。
NAT 模式
地址转换:Network Address Translation,简称:NAT 模式,类似于防火墙的私有网络结构,负载调度器作为所有服务器节点的网关,作为客户机的访问入口,也是各节点回应客户机的访问出口,服务器节点使用私有 IP 地址,与负载调度器位于同一个物理网络,安全性要优于其他两种方式。
NAT 实现原理过程如下:
①客户端发出的请求数据包经过网络到达 LVS 网卡,数据包源 IP 为 CIP,目的 IP 为 VIP。
②然后进入 PREROUTING 链中,根据目的 IP 查找路由,确定是否为本机 IP 地址,随后将数据包转发至 INPUT 链中,源 IP 和 目的 IP 不变。
③到达 LVS 后,通过目的 IP 和目的 PORT 查找是否为 IPVS 服务,如是 IPVS 服务,将会选择一个 RS 来作为后端服务器,数据包的目的 IP 地址将会修改为 RIP,这时并以 RIP 为目的 IP 去查找路由,确定下一跳及 PORT 信息后,数据包将会转发至 OUTPUT 链中。
④被修改过的数据包经过 POSTROUTING 链后,到达 RS 服务器,数据包源 IP 为 CIP,目的 IP 为 RIP。
⑤RS 服务器经过处理后,将会把数据包发送至用户空间的应用程序,待处理完成后,发送响应数据包,RS 服务器的默认网关为 LVS 的 IP,应用程序将会把数据包转发至下一跳 LVS 服务器,数据包源 IP 为 RIP,目的 IP 为 CIP。
⑥LVS 服务器收到 RS 服务器响应的数据包后,查找路由,目的 IP 不是本机 IP并且 LVS 服务器开启了 FORWARD 模式,会将数据包转发给它,数据包不变。
⑦LVS 服务器收到响应数据包后,根据目的 IP 和 目的 PORT 查找相应的服务,这时,源 IP 为 VIP,通过查找路由,确定下一跳信息并将数据包发送至网关,最终回应给客户端用户。
NAT 模式的优点:
NAT 模式的缺点:
NAT 模式的使用场景:对 Windows 操作系统的用户比较友好,使用 LVS ,必须选择 NAT 模式。
TUN 模式
IP 隧道:IP Tunnel,简称:TUN 模式,采用开放式的网络结构,负载调度器作为客户机的访问入口,各节点通过各自的 Internet 连接直接回应给客户机,而不经过负载调度器,服务器节点分散在互联网中的不同位置,有独立的公网 IP 地址,通过专用 IP 隧道与负载调度器相互通信。
TUN 实现原理过程如下:
①客户端发送数据包经过网络后到 LVS 网卡,数据包源 IP 为 CIP,目的 IP 为 VIP。
②进入 PREROUTING 链后,会根据目的 IP 去查找路由,确定是否为本机 IP,数据包将转发至 INPUT 链中,到 LVS,源 IP 和 目的 IP 不变。
③到 LVS 后,通过目的 IP 和目的 PORT 查找是否为 IPVS 服务,如是 IPVS 服务,将会选择一个 RS 后端服务器, 源 IP 为 DIP,目标 IP 为 RIP,数据包将会转发至 OUTPUT 链中。
④数据包根据路由信息到达 LVS 网卡,发送至路由器网关,最终到达后端服务器。
⑤后端服务器收到数据包后,会拆掉最外层的 IP 地址后,会发现还有一层 IP 首部,源 IP 为 CIP,目的 IP 为 VIP,TUNL0 上配置 VIP,查找路由后判断为本机 IP 地址,将会发给用户空间层的应用程序响应后 VIP 为源 IP,CIP 为目的 IP 数据包发送至网卡,最终返回至客户端用户。
TUN 模式的优点:
TUN 模式的缺点:
TUN 模式的使用场景:如对转发性要求较高且具有跨机房需求的,可选择 TUN 模式。
DR 模式
直接路由:Direct Routing,简称 DR 模式,采用半开放式的网络结构,与 TUN 模式的结构类似,但各节点并不是分散在各个地方,而是与调度器位于同一个物理网络,负载调度器与各节点服务器通过本地网络连接,不需要建立专用的 IP 隧道。它是最常用的工作模式,因为它的功能性强大。
DR 实现原理过程如下:
①当客户端用户发送请求给 www.baidu.com 网站时,首先经过 DNS 解析到 IP 后并向百度服务器发送请求,数据包经过网络到百度 LVS 负载均衡服务器。
这时到达 LVS 网卡时的数据包包括:源 IP 地址(客户端地址)、目的 IP 地址(百度对外服务器 IP 地址,也就是 VIP)、源 MAC 地址(CMAC / LVS 连接路由器的 MAC 地址)、目标 MAC 地址(VMAC / VIP 对应的 MAC 地址)。
②数据包到达网卡后,经过链路层到达 PREROUTING 链,进行查找路由,发现目的 IP 是 LVS 的 VIP,这时就会发送至 INPUT 链中并且数据包的 IP 地址、MAC 地址、Port 都未经过修改。
③数据包到达 INPUT 链中,LVS 会根据目的 IP 和 Port(端口)确认是否为 LVS 定义的服务。
如是定义过的 VIP 服务,会根据配置的服务信息,从 RealServer 中选择一个后端服务器 RS1,然后 RS1 作为目标出方向的路由,确定下一跳信息及数据包通过具体的哪个网卡发出,最好将数据包通过 INET_HOOK 到 OUTPUT 链中。
④数据包通过 POSTROUTING 链后,目的 MAC 地址将会修改为 RealServer 服务器 MAC 地址(RMAC)源 MAC 地址修改为 LVS 与 RS 同网段的 IP 地址的 MAC 地址(DMAC)此时,数据包将会发至 RealServer 服务器。
⑤数据包到达 RealServer 服务器后,发现请求报文的 MAC 地址是自己的网卡 MAC 地址,将会接受此报文,待处理完成之后,将响应报文通过 lo 接口传送给 eth0 网卡然后向外发出。
此时的源 IP 地址为 VIP,目标 IP 为 CIP,源 MAC 地址为 RS1 的 RMAC,目的 MAC 地址为下一跳路由器的 MAC 地址(CMAC),最终数据包通过 RS 相连的路由器转发给客户端。
DS 模式的优点:
DS 模式的缺点:
DS 模式的使用场景:对性能要求高的,可首选 DR 模式,还可透传客户端源 IP 地址。
NAT 模式:只需一个公网 IP 地址,是最易用的一种负载均衡模式,安全性较好。
TUN 模式 和 DR 模式:负载能力强大、适用范围广、节点安全性较差。
LVS 的十种负载调度算法
LVS 的十种负载调度算法如下:
①轮询:Round Robin,将收到的访问请求按顺序轮流分配给群集中的各节点真实服务器中,不管服务器实际的连接数和系统负载。
②加权轮询:Weighted Round Robin,根据真实服务器的处理能力轮流分配收到的访问请求,调度器可自动查询各节点的负载情况,并动态跳转其权重,保证处理能力强的服务器承担更多的访问量。
③最少连接:Least Connections,根据真实服务器已建立的连接数进行分配,将收到的访问请求优先分配给连接数少的节点,如所有服务器节点性能都均衡,可采用这种方式更好的均衡负载。
④加权最少连接:Weighted Least Connections,服务器节点的性能差异较大的情况下,可以为真实服务器自动调整权重,权重较高的节点将承担更大的活动连接负载。
⑤基于局部性的最少连接:LBLC,基于局部性的最少连接调度算法用于目标 IP 负载平衡,通常在高速缓存群集中使用。
如服务器处于活动状态且处于负载状态,此算法通常会将发往 IP 地址的数据包定向到其服务器;如果服务器超载(其活动连接数大于其权重),并且服务器处于半负载状态,则将加权最少连接服务器分配给该 IP 地址。
⑥复杂的基于局部性的最少连接:LBLCR,具有复杂调度算法的基于位置的最少连接也用于目标 IP 负载平衡,通常在高速缓存群集中使用。
与 LBLC 调度有以下不同:负载平衡器维护从目标到可以为目标提供服务的一组服务器节点的映射。对目标的请求将分配给目标服务器集中的最少连接节点。
如果服务器集中的所有节点都超载,则它将拾取群集中的最少连接节点,并将其添加到目标服务器群中;如果在指定时间内未修改服务器集群,则从服务器集群中删除负载最大的节点,以避免高度负载。
⑦目标地址散列调度算法:DH,该算法是根据目标 IP 地址通过散列函数将目标 IP 与服务器建立映射关系,出现服务器不可用或负载过高的情况下,发往该目标 IP 的请求会固定发给该服务器。
⑧源地址散列调度算法:SH,与目标地址散列调度算法类似,但它是根据源地址散列算法进行静态分配固定的服务器资源。
⑨最短延迟调度:SED,最短的预期延迟调度算法将网络连接分配给具有最短的预期延迟的服务器。
如果将请求发送到第 i 个服务器,则预期的延迟时间为(Ci +1)/Ui,其中 Ci 是第 i 个服务器上的连接数,而 Ui 是第 i 个服务器的固定服务速率(权重) 。
⑩永不排队调度:NQ,从不队列调度算法采用两速模型。当有空闲服务器可用时,请求会发送到空闲服务器,而不是等待快速响应的服务器。
如果没有可用的空闲服务器,则请求将被发送到服务器,以使其预期延迟最小化(最短预期延迟调度算法)。
LVS 涉及相关的术语及说明
上述内容中涉及到很多术语或缩写,这里简单解释下具体的含义,便于理解:
总结
回顾下,通过本文你可学习到什么是 LVS、为什么要用 LVS、LVS 的组成及工作原理等。
参考文献:
*请认真填写需求信息,我们会在24小时内与您取得联系。