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

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 的最佳协同者，云科通明湖同时也是信创负载均衡的领先品牌。

信创就选云科通明湖。

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

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

“一直游到海水变蓝。”