细数从负载均衡到应用交付的演进历程

网络 网络优化 网络运维
近年来,IT互联网技术发展日新月异,新兴的技术概念层出不穷,有些新兴的技术概念连不少IT业内的从业者都还没来得及理解,便已经步入了广泛深入的应用洪流中,应用交付便是其中之一。

近年来,IT互联网技术发展日新月异,新兴的技术概念层出不穷,有些新兴的技术概念连不少IT业内的从业者都还没来得及理解,便已经步入了广泛深入的应用洪流中,应用交付便是其中之一。

提起应用交付,甚至很多IT经理还颇感陌生,但是提到负载均衡他们却是相当熟悉,当向他们进一步解释应用交付是比负载均衡更全面更系统的网络优化产品时,他们之中的不少人估计都会像小沈阳一样可爱的发问:“这是为什么呢?” 提出这样的疑问可以理解,因为负载均衡的应用时间也还没有多久,就要向着应用交付进化了。

那么,到底是什么促进了网络优化产品如此快速的演进呢?国内新兴应用交付厂商太一星晨对此有着深入的理解。

太一星晨核心技术团队在10年前研发出国内***台***的电信路由器,继而又推出国内***台万兆UTM网关,如今又研发出国内性能***的T比特级应用交付设备,可谓是国内网络优化产品发展历程的资深见证者和研发者。对于,国内网络优化产品的演进历程,太一星晨产品总监于振波先生特别做出了详细的解读。

最初的DNS

在互联网商用初期、专用的负载均衡设备实现商用之前,最常用的实现扩展性和高可用性的技术是DNS轮询。

最初的DNS

所谓DNS轮询,就是依托于域名服务,将用户访问的URL(如www.example.com)转换为机器可识别的IP地址(如192.0.2.11)的服务,它使每个域名解析请求能对应多个IP地址以不同顺序应答。这样,当不同用户请求对应域名时,就自然而然地分配到了不同的服务器上。

于振波表示,虽然从解决扩展性的角度来看,这种方案非常有效,但无论是从提高扩展性还是持续性来说,DNS方案都有一些欠妥。

如果把DNS Sever理解为一位项目经理,那么他实在不是一位有领导力的头儿。比如,每当接到大Boss新任务的时候,这位项目经理只知道硬性分配,把任务一个一个地分发到自己的下属手上,却完全没有考虑过下属的感受:如下属是否善于这些工作,是否有其他安排,是否能保证结果……这些基本没有考虑,结果可想而知。

更郁闷的是,大Boss***次请求是通过项目经理来安排的,但之后,大Boss就会记下下属的名字,然后每次直接找同一个下属完成。于是,同一位下属身上的任务可能越积越多,要么降低了工作效率,要么就直接不堪重负。

由此,归纳下来,DNS轮询作为负载技术的状况下,弊端越积越多:

1.无法知道所列的服务器是否工作,所以用户获得的服务器地址可能已经不工作了。

2.缺乏对不同服务器动态的分配算法。

3.客户端会缓存解析结果,后续访问会始终使用旧的IP地址,导致流量分配不均匀。

4.在对业务可靠性要求不高的环境中,DNS轮询方式因为简单、低廉,依然还被使用。但对可靠性要求较高的业务,就不会科学地分配工作,导致后续出现众多严重问题!

在这样的情况下,网络负载均衡应运而生了。

网络负载均衡

所谓网络负载均衡,从本质上讲,就是负载均衡会对外部展现一个虚拟的服务器地址(如192.0.2.1:80),当用户试图连接时,它会将连接通过双向网络地址转换(NAT)转到最适合的真实服务器上,以完成用户的请求。

网络负载均衡

网络负载均衡的主要核心技术主要有以下三项:

1.健康检查。

2.负载均衡算法。

3.会话保持算法。

基于这三个特定技术,网络负载均衡以优质项目经理的身份,替代了DNS轮询。

首先,在整个工作过程中,聪明的网络负载均衡会不断探测后台服务器的工作状态,看看哪位下属有没有别的事情,哪位下属是否状态不佳,并根据检测到的结果实时分配任务,避免了大Boss的请求被分配到不工作的服务器上。

其次,根据服务器的流量、性能等,网络负载均衡还会以它专有的算法对任务进行分配。这就好比是一位深谙人力资源利用的头儿,当他掌握了自己不同下属的能力后,会因人而异地分配工作,能力强的多担当,能力弱的任务少点儿,以达到人力资源的***化。

再次,针对某些特殊应用,例如要求自始至终一台服务器处理的,网络负载均衡将使用会话保持技术,记住每个用户的身份,以达到让同一用户始终在同一台服务器上操作的目的。例如在网银操作中,网络均衡服务器这位聪明的头儿,会通过用户IP地址、Cookie等数据,指定某一位下属始终为一位用户服务,包括用户的登录、查询、转账等等业务,都始终保持在小弟的这台服务器上操作,保证了任务的顺利完成。

换了这么一位聪明的头儿以后,不但小弟们的工作状态可以通过健康检查得到相关数据,而且还能根据小弟们不同的能力,依靠特定的算法进行任务的分配,并且对于特定的业务需求,可以固定地使用某一位下属去工作。后台服务器得到了***化应用,大Boss自然满意点头。#p#

可是,好日子没过多久,问题又出现了。

随着互联网技术的发展和用户量的激增,无论是网络带宽还是硬件设备的性能都开始大幅提升。但是,在投入大价钱采购硬件设备后,用户终端的应用效果却始终不如人意。比如还是时常会出现打开页面慢、响应时间长、系统效率低等多种不良情况。

那么,这又是哪里出了问题呢? 于振波表示,问题主要出现在以下三个方面。

1.跨运营商访问

国内的移动通信分为“北联通南电信”的格局,而运营商之间在相互访问的时候常常会发生各种效率低下的问题。比如,玩网游时都会有这样感受,在进入游戏之时,若联通用户误入电信大厅,就会因为跨运营商造成网速巨慢而很快就会被别的玩家“踢”出去……

2.地域性限制

地域越远,中间经过的节点越多,造成的损耗就越大,应用效果就越差。最明显的是目前人气超旺的海淘大军——打开国内的百度腾讯等等网站毫不费劲,一旦进入国外购物网站,页面速度慢得恨不得能自己直接飞机跑一趟。

3.宽窄带并存

随着智能终端的普及,同样的应用,家用电脑和智能手机的访问效果截然不同。究其原因,家用电脑走宽带而手机终端用窄带,并且手机信号是有变化的,当信号不好的时候,即使是直通罗马的大道也会慢得叹气。

由此,传统路由、交换设备工作在二三层、负载均衡设备工作在四层。当二三四层都被被各种问题弄得焦头烂额之时,应用交付产品(ADC)顺势而生。

应用交付(ADC)步入快车道

所谓“应用交付”,指的是指应用交付网络(Application Delivery Networking,简称ADN),它利用相应的网络优化/加速设备,确保用户的业务应用能够快速、安全、可靠地交付给内部员工和外部服务群。应用交付的宗旨是保证企业关键业务的可靠性、可用性与安全性。

应用交付(ADC)步入快车道

首先,基于内容的分发是应用交付的一大突出特性。

基于内容的分发,可以举个这样的例子。以前,到银行办理业务还需要自己排队,后来银行引入了自动排号机,这种起到了分发用户作用的设备就类似于网络负载均衡。虽然这样的排号可以让每个人都能按号办理自己想要的业务,但是却难免会出现业务分配不合理、无谓等待时间长、主次业务相混淆等问题。

后来,经过一番改进,银行推出了大堂经理服务,采用“大堂经理+排号机”的组合式服务分配,就与应用交付功能颇为类似。用户取号后,大堂经理会先询问他所需要进行的业务,然后再按照不同的业务指引用户到不同的窗口进行操作:小额存取款直接到柜员机操作,VIP客户可到VIP窗口,银行基金可至基金柜台咨询……基于不同内容进行业务分发,把相同的业务指引到固定的服务器上,这不但大大缩短了用户的操作时间,更提高了应用效率。

与传统的网络负载均衡相比,应用交付工作在应用层,除了基于内容的分发外,应用交付对于负载均衡遇到的几大问题有着智能化的解决方式。

以太一星晨T-force应用交付为例。针对跨运营商访问问题,T-force应用交付平台可以通过内部智能的DNS与智能选路功能,保证用户不会跨运营商访问。即电信用户可以通过电信链路实现访问,而网通来的用户则可以通过网通链路实现访问。

针对宽窄带并存的情况,当用户采用不同的移动终端来访问数据中心核心应用时,T-force应用交付平台可以通过智能客户端识别技术,将移动终端的请求分发到移动终端的服务器上,从而保障每一个用户效率体验。

细数从负载均衡到应用交付的演进历程

针对异地跨区域访问问题,T-force拥有智能DNS解决方案。如一个广东的客户访问核心应用时会发起一个DNS请求,该请求会通过分服务器转发到应用交付设备上,应用交付设备会根据不同数据中心之间的探测与评估,找出最适合该用户访问的数据中心,并将该请求DNS解析出的IP地址指向广州的数据中心。如此,便保证了该用户访问时候的地域就近性,以及网络连通性,有效提升效率。

此外,应用交付依靠对应用协议的加速处理、应用安全的检测,实现了从客户端到服务器的完整的业务交付过程。未来,应用交付可能将提供更智能化的功能,并尽可能以***方式交付应用的所有方面。

责任编辑:林琳 来源: 51CTO.com
相关推荐

2015-11-30 16:02:13

应用交付网络优化

2015-11-11 15:52:36

应用交付负载均衡太一星晨

2022-07-01 08:26:22

区块链去中心化以太坊

2009-04-22 09:41:00

负载均衡设备

2023-08-25 13:32:00

JavaScript虚拟DOM

2010-04-22 14:06:06

负载均衡层次

2024-05-16 07:51:55

分布式系统架构

2015-11-26 10:20:17

F5应用交付

2014-05-30 10:51:56

2015-07-22 17:04:08

应用交付 太一星晨

2010-04-25 17:18:09

TCP负载均衡

2015-11-12 14:28:09

太一星晨负载均衡

2009-04-18 09:14:51

2011-08-29 16:44:08

深信服应用交付

2014-12-08 14:40:20

2014-10-09 15:52:42

ADC

2010-04-23 10:01:02

负载均衡产品

2010-05-10 17:00:38

链路负载均衡

2022-06-02 08:37:10

架构DDDMVC

2013-03-26 10:43:51

负载均衡应用交付产品深信服
点赞
收藏

51CTO技术栈公众号