写点什么

消失与存续——应用交付行业的跌宕演进

作者:云科通明湖
  • 2022-10-28
    北京
  • 本文字数:6468 字

    阅读完需:约 21 分钟

消失与存续——应用交付行业的跌宕演进

1996 年,一家名为 Foundry Networks 的公司在硅谷成立,主要研发售卖交换机、路由器等网络硬件产品。


那年是“互联网泡沫”形成的初期,美国 IT 行业的新公司如雨后春笋。可以想象,当时这家公司的成立,也许并没有溅起太大的水花。


但在短短三年后,Foundry 就在纳斯达克上市,并创下多项纪录,成为华尔街最受瞩目、最具成长潜力的初创企业,甚至入选过美国 500 强。


转眼又几年,时局突变。2008 年,Foundry 被 Brocade 以大约 26 亿美元的价格收购,这场收购案兜兜转转数月才最终敲定,还因为股票价格下跌而被压价。到如今,Foundry 已泯然众人。


扛住了泡沫破裂,却没扛得住收购。


当初决定减少 4-7 层交换机产品投入的 Foundry 创始人 Bobby Johnson,看到与 Foundry 同年成立、现在如日中天的老对手 F5,不知会作何感想。


4-7 层交换机这个词,对于初入网络行业的朋友可能比较少见,今天,大家或许更习惯它的另一个称呼——负载均衡。


作为最早推出负载均衡设备的厂商,当年的 Foundry 前程似锦。按照一般的剧本,由负载均衡概念演进而来的应用交付,理应是他们的拿手好戏。


但变化是永恒的,历史总会走上一条多数人未曾设想的道路——包括技术本身。

如何理解应用交付

随着数字化进程不断被推动,应用大量涌现、访问量飙升,为了保证应用和内容的安全高效访问,应用交付技术便应运而生。


应用交付部署在网络和应用之间,将两者深度结合、有效协同,致力于将应用以高效、安全、稳定的方式交付给最终用户。为了实现这一目标,应用交付融合了负载均衡、应用安全管理、应用加速、流量控制等多种技术。


在 IT 应用架构中,应用交付位于互联网与数据中心之间的咽喉要道,因此拥有重要的战略价值。


责任越大,挑战越大。对于企业来说,这种挑战可能更多在于如何更好地、合理地发挥应用交付的价值,为业务应用赋能。而对于应用交付本身来说,挑战则在于如何更好地把握技术发展方向。


当我们希望对未来趋势有一些洞察时,回顾应用交付的发展历程,是很有必要的。

在应用交付之前

在互联网的古早时期,用户访问量少之又少,往往只靠单台服务器就能满足对外服务需求。但随着互联网的普及,越来越多的用户接入网络,业务流量也自然水涨船高。


当单台服务器无法应对流量增长、支撑服务运行的时候,通常有两种解决办法:


  1. 换更好的服务器

  2. 加更多的服务器


也就是我们常说的纵向扩展(提升单台服务器的计算、存储、网络等资源配置)和横向扩展(通过增加多台服务器同时工作,满足大型应用处理需求)。


第一种方法也许够简单粗暴,但单机性能总是有上限的,而且多数情况下,机器性能的提升与价格并非呈正比。因此,以多台服务器组成集群,同时承载业务应用,作为一种更实际的解决方案被大家普遍接受。


但此时又面临一个新的问题,业务负载如何分配?多台服务器之间如何协调?首先我们看看若不做协调会发生什么?业务流量到达后端时得不到有效控制,出现工作分配不均的现象:有的服务器已经超负荷运转,有的却处于空闲状态。这不但造成了极大的资源浪费,同时也会影响用户的访问体验。


负载均衡的出现,就是为了解决这一问题。它可以构建在现有的网络结构之上,作为流量入口,对流量进行调度,将其均衡地分配到集群中的不同机器上。


DNS 负载均衡实现

最初,实现负载均衡采用的是 DNS(Domain Name System,域名系统)方法。


DNS 本质上是一个分布式数据库,能够将域名和 IP 地址相互映射,使互联网访问更方便——人们在访问网站时,只需记住网站的域名即可,而无需记住复杂的 IP 地址。


利用 DNS 实现负载均衡,是通过 DNS 服务中的随机名字解析来实现的,在 DNS 中为多个域名地址配置同一个名字,查询到这个名字的客户机将在解析时得到其中一个地址。从而使访问同一网站的不同的客户机得到不同的域名地址,也就访问了不同的服务器,从而达到负载均衡的目的。


这是一种简单而有效的方法,实施容易,无需投入太多成本,而且广泛适用。


但 DNS 方法存在一个致命的问题:它实现的是绝对的平均,将来自互联网的访问请求完全平均地分配给后端服务器。它无法区分服务器的性能差异,也不能反映服务器当前的运行状态。


事实上“均衡”并不等于“平均”,将业务流量平均地分配给服务器而不考虑其性能,并不能从本质上解决负载不均衡的问题。


而且,若其中一台服务器宕机,DNS 是无法获知的,它仍然会将流量分配过去,这将导致客户无法获得响应。


因此,DNS 负载均衡的应用场景比较有限。

基于网络交换技术的负载均衡

为了达到真正意义上的负载均衡,行业把目光转移到了网络交换技术,并基于 OSI 模型(Open System Interconnection Reference Model,开放式系统互联通信参考模型),在不同网络层次上实现负载均衡功能。


OSI 模型由国际标准化组织 1981 年提出,是一个全球通用的网络标准框架,它将计算机网络结构划分为七层:


  1. 物理层

  2. 数据链路层

  3. 网络层

  4. 传输层

  5. 会话层

  6. 表示层

  7. 应用层


根据在 OSI 不同层次上的实现,有以下几类负载均衡:


  1. 二层负载均衡:基于数据链路层,采用虚拟 MAC 地址的方式,外部对虚拟 MAC 地址请求,负载均衡接收后分配后端实际的 MAC 地址响应。

  2. 三层负载均衡:基于网络层,采用虚拟 IP 地址方式,外部对虚拟 IP 地址请求,负载均衡接收后分配后端实际的 IP 地址响应。

  3. 四层负载均衡:基于传输层,主要通过报文中的目标地址和端口,再加上负载均衡设备设置的服务器选择方式,决定最终选择的内部服务器。

  4. 七层负载均衡:基于应用层,也称为“内容交换”,主要通过报文中的真正有意义的应用层内容,再加上负载均衡设备设置的服务器选择方式,决定最终选择的内部服务器。


与二层、三层相比,四 / 七层负载均衡更为常见。如今我们提到负载均衡时,也更多是指后者。


由于实现层次的不同,四层负载均衡与七层负载均衡在性能、安全性、功能性、复杂性等方面有着巨大的区别。


最明显的区别是,四层负载均衡架构相对简单,易于管理,且资源消耗更低,在网络吞吐量及处理能力上更有优势。


而七层负载均衡覆盖了 OSI 模型定义的所有网络层次,它能更灵活、更全面地对网络请求进行修改,实现更智能的负载均衡,且具备更强的安全防护能力。但与之相对的,资源损耗也会更高。

从负载均衡到应用交付

负载均衡出现的时期,正是互联网投机泡沫开始膨胀的时期,许多着力开发相关产品的创业公司纷纷涌现出来,如 Foundry、Alteon、Arrowpoint、NetScaler、F5 等,竞争格局激烈,颇有一股群雄并起的味道。


正如前文所述,Foundry 公司最早提出了四 / 七层交换机概念并推出产品,也就是发布于 1998 年的 ServerIron XL。这款产品在当时拥有很大的热度,以至于,即使在 Foundry 被 Brocade 收购后,也还持续销售了一段时间。


当时的大部分负载均衡初创企业,最终都没有逃过被收购的命运。导致更大区别的原因可能在于,收购是发生在泡沫破裂前还是破裂后。


一个典型的案例是 Alteon 的两度易主:2000 年热度最高时,Nortel 以 78 亿美元的交易总额收购了 Alteon;不到 10 年后,Nortel 又将 Alteon 业务出售给 Radware,虽然双方没有公开交易额,但有传言称,Radware 给 Nortel 开出的价格也不过数千万美元。


时至今日,我们不能武断地将那些企业最终失败的原因,简单归结为互联网泡沫的破裂,但将其视为导火索也许并不为过。


负载均衡的市场空间在于互联网的扩张、流量的增加,而当互联网泡沫破裂时,负载均衡产品销售量大幅下降,让所有厂商都面临着巨大的生存挑战。


由于四 / 七层产品的研发、技术支持投入都远高于架构更为简单的二 / 三层产品,为了度过艰难时期,包括领头羊 Foundry 在内的许多厂商都做出了收缩四 / 七层产品的决定。在资历较老的厂商中,只有和 Foundry 同年成立的 F5 坚持在这一领域持续投入。


当互联网重振旗鼓之时,四 / 七层产品的价值得到广泛认可,市场得以复兴,但此时的 F5 已经没有对手了。


正是这个时期,随着电子商务、流媒体网站等应用的盛行,业务应用对网络提出了更高的要求,单纯的负载均衡已无法满足需求。


通过融合应用加速与优化、流量管理等技术,负载均衡开始向应用交付演进。

应用交付的技术核心

随着架构的发展,应用交付的技术堆栈在负载均衡的基础上得到了极大的丰富,加入了许多新的技术手段,如致力于实现应用加速功能的 TCP 优化、连接复用、缓存压缩、SSL 加速等,以及保障应用安全的 Web 应用防火墙、协议清洗、DDOS 防护、业务加密等。


如此多的复杂名词,可能会让不了解技术的朋友眼花缭乱。事实上,应用交付技术架构的演进始终围绕它的根本目标展开:将应用以高效、安全、稳定的方式交付给用户。


可以说,所有技术手段的使用,都是为了实现这一目标。因此,我们或许可以概括性地将应用交付的核心技术分为以下几个方面:


  1. 应用加速:主要实现广域网优化加速,通过一系列技术来提供跨地域、跨运营商的快速远程网络访问,节约互联网带宽,提高现有网络环境中的应用访问效率。

  2. 应用安全:融合安全网关的功能,通过建立全面的安全规则与策略,覆盖网络层、应用层,实施完备的安全防护,保障应用的安全访问。

  3. 高可用性:以负载均衡为主,同时加入健康检查、会话保持等多种功能,从流量管理的角度实现集群的高可用,确保应用平稳可靠运行。


在应用环境压力不断提升,流量日益加剧的趋势下,应用交付技术基本按照以应用为导向、围绕以上三大核心诉求发展新技术的路线前进。


目前为止,我们所讨论的,都是以本地数据中心部署为主的应用交付。在业内对应用交付的概念达成共识之后,至少主流上维持着这种发展规律——直到云计算开始盛行,又一场巨大变革也因此来袭。

从应用交付到应用发布

进入移动互联网时代,应用数量爆发式增长,企业的竞争环境愈发激烈,需要时刻保持业务创新,不断改善用户体验,并且快速地完成落地,方能激流勇进、实现商业成功。


这对 IT 架构提出了巨大的挑战,包括如何实现应用现代化、如何应对 IT 复杂性等等。与传统数据中心相比,云计算的灵活性、扩展性优势,更能够帮助企业充分应对这种挑战,因此成为主流趋势。


云计算与大数据、人工智能常常被称为数字经济时代的三驾马车,对整个行业的未来发展有着深远的影响。当涉及到应用交付领域,也许是因为云计算更偏向于 IT 底层基础架构的变革,所以对应用交付技术发展的影响最为显著,与之相对的,大数据和人工智能对应用交付的影响,则更多体现在如何提升产品服务能力上。


2019 年,F5 收购了开源 Web 服务器软件 Nginx 的商业化公司。Nginx 在世界上广受欢迎,包括 Instagram、Neflix、Airbnb 等在内的全球大多数网站应用中都有 Nginx 的身影。其优秀的负载均衡、流量控制等能力,在云微服务架构中同样能够发挥巨大价值。F5 收购 Nginx 的意图十分明显——加速自身在软件和云方面的变革,保持在云时代的领先性。


同样是在这一年,云原生基金会(Cloud Native Computing Foundation,CNCF)成立了应用交付领域小组(Application Delivery SIG),希望明确并解决应用交付生命周期的关键环节和核心问题,同时优化云原生场景下的应用架构。CNCF 由谷歌牵头成立,势头正盛的 Kubernetes 就是它的第一个开源项目。CNCF 的下场,从某种角度看,也代表着“云原生应用交付”的加速发展。


而在通明智云总经理吴若松看来,随着云计算和微服务架构的演进,我们将迎来“应用发布”的时代。应用发布起源于应用交付,却又和应用交付有极大不同。

应用发布的技术核心

首先我们可以简单地概括,传统应用交付与应用发布的最大差别,在于两者分别面向的是“稳态”与“敏态”这两种不同的应用场景。


稳态的主要诉求是保证应用能够被高效、可靠、安全地访问,而敏态则在此基础上,希望以更加快速、敏捷、灵活的方式发布应用和服务。


另一方面,两者最直观的区别在于:从整体架构上看,应用交付的两端分别是用户与数据中心,而应用发布的两端则是用户与云。


这也导致了应用交付时代更注重解决南北向通信的压力,而应用发布——出于云服务架构的特性——需要更专注于云计算中的东西向通信。


  1. 南北向通信,解决集群和外部的通信问题,实现核心网的功能。

  2. 东西向通信,解决业务内部各个微服务之间的通信和链路治理。


目前应用发布的核心技术有:


  1. 蓝绿发布 - 在发布某应用的新版本时,并不停止旧版本,若新版本运行稳定,便将流量从老版本切换过来,若新版本出现问题,也可以及时切换回旧版本。这样可以减少版本发布对应用运行的影响。

  2. 灰度发布 - 顾名思义,这是一种黑白之间平滑过渡的应用发布方式。新版本发布后,先将少量流量切换过来,对新版本运行情况进行观察分析,当确认无误后,再逐步将更多的流量切换到新版本上,直到实现 100% 的切换,完全替换旧版本。灰度发布也称为金丝雀发布,是进行 A/B 测试的重要手段。

  3. 熔断机制 - “熔断”一词多出现于股市,应用服务中的熔断机制,本质上与股市并无差异,都是为了控制风险。云微服务之间往往存在依赖关系,如果其中某个服务调用出现高延迟等问题,将导致其他服务也出现问题,甚至可能导致业务系统不可用。实施熔断机制,可及时检测问题,对该服务执行熔断,避免造成更大范围的影响,同时释放资源。

  4. 业务编排 - 通过制定策略控制业务流量的转发,按照策略所定义的顺序,对流量进行调度,以策略化的方式统筹整个网络。


能够看出,以上这些技术的目标,都是为了建立敏态应用环境下的一种更快速、灵活、敏捷的应用发布机制。在云计算趋于成为常态的今天,充分考虑云架构特性,构建“云原生”的应用发布,已成为一大趋势。

应用交付不会退场

但我们始终需要明确的是,“演进”并非“替代”。如果在新的技术理念出现时,就将此前已经成熟稳定的传统技术实践淘汰,不但厂商不答应、企业不答应、市场也不答应。传统应用交付,仍有存在和发展的必要。


站在技术层面,未来应用发布虽然主要面向敏态环境,但如上文所述,它依旧是在稳态基础上实现的。企业对应用加速、应用安全以及高可用性的诉求,并不会因为进入云时代而消失,只会随着技术的发展而不断提高。


产品形态上,传统应用交付设备仍然具有很大的需求空间,特别是在国内。


从“新基建”到“东数西算”,作为 IT 基础设施的关键组成部分,面对全国各地日益增长的网络流量,应用交付设备在流量管理、安全防护等方面的价值,能够在数据中心发挥巨大的作用,为织就全国算力一张网、构建新型算力网络体系贡献力量。


此外,一个重要的现实原因是,出于数据安全、合规性、现有 IT 流程、延迟敏感型应用等各方面的因素考虑,许多国内企业并不能接受公有云——IDC、Gartner 等行业研究机构都曾在其报告中描述过这一现状——而是采用本地私有云部署为主的形式。


即便是在未来,与完全采用公有云相比,混合云更像是一种易于为人们所接受的架构。在私有云环境下,对传统应用交付设备的需求还会持续。


就像负载均衡从未退场一样,应用交付也不会退场。

一直游到海水变蓝

人们常常用“蓝海”和“红海”来形容市场空间的状态,毫无疑问,与已经非常成熟的应用交付相比,应用发布更像是一片蓝海。


但当我们把焦距推向十多年前时,与负载均衡相比,应用交付则是蓝海;往更久远处推,负载均衡也曾是蓝海——从 Foundry 到 F5,不同的时代书写了不同的故事.


但至少我们可以确定,蓝海永远是领先者的,也永远造就领先者。


有趣的是,从负载均衡向应用交付演进的历史来看,深入蓝海的领先者,又似乎必须曾经历红海的洗礼。当然,这里更深层原因是,在红海中锻炼出来的强大“肌肉”——足够雄厚的技术实力。


云科通明湖应用交付网关,立足于应用交付,凭借多年技术实践积累,为许多国内客户构建了安全、高效、可控的应用交付平台。云科通明湖系列产品能实现应用和网络的有效协同,保证应用系统能够被安全、高效、可控地访问,在整个 IT 架构中有着重要的战略价值和丰富的应用场景。作为负载均衡领域全球领先品牌 f5 的最佳协同者,云科通明湖同时也是信创负载均衡的领先品牌。


信创就选云科通明湖。


在不断锻炼自身肌肉的同时,云科通明湖也仰望着未来,向云时代的应用发布前行,致力于打通云管边端,帮助客户完成架构演进、拥抱敏态应用环境。


在数字经济这片充满不确定的瀚海中,我们不但需要时常磨炼自身,也要持续激励自己向更远处游去。


“一直游到海水变蓝。”

用户头像

负载均衡颠覆者,可持续性应用交付新引擎 2022-10-13 加入

还未添加个人简介

评论

发布
暂无评论
消失与存续——应用交付行业的跌宕演进_负载均衡_云科通明湖_InfoQ写作社区