1996 年，一家名为 Foundry Networks 的公司在硅谷成立，主要研发售卖交换机、路由器等网络硬件产品。
那年是“互联网泡沫”形成的初期，美国 IT 行业的新公司如雨后春笋。可以想象，当时这家公司的成立，也许并没有溅起太大的水花。
但在短短三年后，Foundry 就在纳斯达克上市，并创下多项纪录，成为华尔街最受瞩目、最具成长潜力的初创企业，甚至入选过美国 500 强。
转眼又几年，时局突变。2008 年，Foundry 被 Brocade 以大约 26 亿美元的价格收购，这场收购案兜兜转转数月才最终敲定，还因为股票价格下跌而被压价。到如今，Foundry 已泯然众人。
扛住了泡沫破裂，却没扛得住收购。
当初决定减少 4-7 层交换机产品投入的 Foundry 创始人 Bobby Johnson，看到与 Foundry 同年成立、现在如日中天的老对手 F5，不知会作何感想。
4-7 层交换机这个词，对于初入网络行业的朋友可能比较少见，今天，大家或许更习惯它的另一个称呼——负载均衡。
作为最早推出负载均衡设备的厂商，当年的 Foundry 前程似锦。按照一般的剧本，由负载均衡概念演进而来的应用交付，理应是他们的拿手好戏。
但变化是永恒的，历史总会走上一条多数人未曾设想的道路——包括技术本身。
如何理解应用交付
随着数字化进程不断被推动，应用大量涌现、访问量飙升，为了保证应用和内容的安全高效访问，应用交付技术便应运而生。
应用交付部署在网络和应用之间，将两者深度结合、有效协同，致力于将应用以高效、安全、稳定的方式交付给最终用户。为了实现这一目标，应用交付融合了负载均衡、应用安全管理、应用加速、流量控制等多种技术。
在 IT 应用架构中，应用交付位于互联网与数据中心之间的咽喉要道，因此拥有重要的战略价值。
责任越大，挑战越大。对于企业来说，这种挑战可能更多在于如何更好地、合理地发挥应用交付的价值，为业务应用赋能。而对于应用交付本身来说，挑战则在于如何更好地把握技术发展方向。
当我们希望对未来趋势有一些洞察时，回顾应用交付的发展历程，是很有必要的。
在应用交付之前
在互联网的古早时期，用户访问量少之又少，往往只靠单台服务器就能满足对外服务需求。但随着互联网的普及，越来越多的用户接入网络，业务流量也自然水涨船高。
当单台服务器无法应对流量增长、支撑服务运行的时候，通常有两种解决办法：
- 换更好的服务器
- 加更多的服务器
也就是我们常说的纵向扩展（提升单台服务器的计算、存储、网络等资源配置）和横向扩展（通过增加多台服务器同时工作，满足大型应用处理需求）。
第一种方法也许够简单粗暴，但单机性能总是有上限的，而且多数情况下，机器性能的提升与价格并非呈正比。因此，以多台服务器组成集群，同时承载业务应用，作为一种更实际的解决方案被大家普遍接受。
但此时又面临一个新的问题，业务负载如何分配？多台服务器之间如何协调？
首先我们看看若不做协调会发生什么？业务流量到达后端时得不到有效控制，出现工作分配不均的现象：有的服务器已经超负荷运转，有的却处于空闲状态。这不但造成了极大的资源浪费，同时也会影响用户的访问体验。
负载均衡的出现，就是为了解决这一问题。它可以构建在现有的网络结构之上，作为流量入口，对流量进行调度，将其均衡地分配到集群中的不同机器上。
DNS 负载均衡实现
最初，实现负载均衡采用的是 DNS（Domain Name System，域名系统）方法。
DNS 本质上是一个分布式数据库，能够将域名和 IP 地址相互映射，使互联网访问更方便——人们在访问网站时，只需记住网站的域名即可，而无需记住复杂的 IP 地址。
利用 DNS 实现负载均衡，是通过 DNS 服务中的随机名字解析来实现的，在 DNS 中为多个域名地址配置同一个名字，查询到这个名字的客户机将在解析时得到其中一个地址。从而使访问同一网站的不同的客户机得到不同的域名地址，也就访问了不同的服务器，从而达到负载均衡的目的。
这是一种简单而有效的方法，实施容易，无需投入太多成本，而且广泛适用。
但 DNS 方法存在一个致命的问题：它实现的是绝对的平均，将来自互联网的访问请求完全平均地分配给后端服务器。它无法区分服务器的性能差异，也不能反映服务器当前的运行状态。
事实上“均衡”并不等于“平均”，将业务流量平均地分配给服务器而不考虑其性能，并不能从本质上解决负载不均衡的问题。
而且，若其中一台服务器宕机，DNS 是无法获知的，它仍然会将流量分配过去，这将导致客户无法获得响应。
因此，DNS 负载均衡的应用场景比较有限。
基于网络交换技术的负载均衡
为了达到真正意义上的负载均衡，行业把目光转移到了网络交换技术，并基于 OSI 模型（Open System Interconnection Reference Model，开放式系统互联通信参考模型），在不同网络层次上实现负载均衡功能。
OSI 模型由国际标准化组织 1981 年提出，是一个全球通用的网络标准框架，它将计算机网络结构划分为七层：
- 物理层
- 数据链路层
- 网络层
- 传输层
- 会话层
- 表示层
- 应用层
根据在 OSI 不同层次上的实现，有以下几类负载均衡：
- 二层负载均衡：基于数据链路层，采用虚拟 MAC 地址的方式，外部对虚拟 MAC 地址请求，负载均衡接收后分配后端实际的 MAC 地址响应。
- 三层负载均衡：基于网络层，采用虚拟 IP 地址方式，外部对虚拟 IP 地址请求，负载均衡接收后分配后端实际的 IP 地址响应。
- 四层负载均衡：基于传输层，主要通过报文中的目标地址和端口，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。
- 七层负载均衡：基于应用层，也称为“内容交换”，主要通过报文中的真正有意义的应用层内容，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。
与二层、三层相比，四 / 七层负载均衡更为常见。如今我们提到负载均衡时，也更多是指后者。
由于实现层次的不同，四层负载均衡与七层负载均衡在性能、安全性、功能性、复杂性等方面有着巨大的区别。
最明显的区别是，四层负载均衡架构相对简单，易于管理，且资源消耗更低，在网络吞吐量及处理能力上更有优势。
而七层负载均衡覆盖了 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 防护、业务加密等。
如此多的复杂名词，可能会让不了解技术的朋友眼花缭乱。事实上，应用交付技术架构的演进始终围绕它的根本目标展开：将应用以高效、安全、稳定的方式交付给用户。
可以说，所有技术手段的使用，都是为了实现这一目标。因此，我们或许可以概括性地将应用交付的核心技术分为以下几个方面：
- 应用加速：主要实现广域网优化加速，通过一系列技术来提供跨地域、跨运营商的快速远程网络访问，节约互联网带宽，提高现有网络环境中的应用访问效率。
- 应用安全：融合安全网关的功能，通过建立全面的安全规则与策略，覆盖网络层、应用层，实施完备的安全防护，保障应用的安全访问。
- 高可用性：以负载均衡为主，同时加入健康检查、会话保持等多种功能，从流量管理的角度实现集群的高可用，确保应用平稳可靠运行。
在应用环境压力不断提升，流量日益加剧的趋势下，应用交付技术基本按照以应用为导向、围绕以上三大核心诉求发展新技术的路线前进。
目前为止，我们所讨论的，都是以本地数据中心部署为主的应用交付。在业内对应用交付的概念达成共识之后，至少主流上维持着这种发展规律——直到云计算开始盛行，又一场巨大变革也因此来袭。
从应用交付到应用发布
进入移动互联网时代，应用数量爆发式增长，企业的竞争环境愈发激烈，需要时刻保持业务创新，不断改善用户体验，并且快速地完成落地，方能激流勇进、实现商业成功。
这对 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 的下场，从某种角度看，也代表着“云原生应用交付”的加速发展。
而在通明智云总经理吴若松看来，随着云计算和微服务架构的演进，我们将迎来“应用发布”的时代。应用发布起源于应用交付，却又和应用交付有极大不同。
应用发布的技术核心
首先我们可以简单地概括，传统应用交付与应用发布的最大差别，在于两者分别面向的是“稳态”与“敏态”这两种不同的应用场景。
稳态的主要诉求是保证应用能够被高效、可靠、安全地访问，而敏态则在此基础上，希望以更加快速、敏捷、灵活的方式发布应用和服务。
另一方面，两者最直观的区别在于：从整体架构上看，应用交付的两端分别是用户与数据中心，而应用发布的两端则是用户与云。
这也导致了应用交付时代更注重解决南北向通信的压力，而应用发布——出于云服务架构的特性——需要更专注于云计算中的东西向通信。
- 南北向通信，解决集群和外部的通信问题，实现核心网的功能。
- 东西向通信，解决业务内部各个微服务之间的通信和链路治理。
目前应用发布的核心技术有：
- 蓝绿发布 - 在发布某应用的新版本时，并不停止旧版本，若新版本运行稳定，便将流量从老版本切换过来，若新版本出现问题，也可以及时切换回旧版本。这样可以减少版本发布对应用运行的影响。
- 灰度发布 - 顾名思义，这是一种黑白之间平滑过渡的应用发布方式。新版本发布后，先将少量流量切换过来，对新版本运行情况进行观察分析，当确认无误后，再逐步将更多的流量切换到新版本上，直到实现 100% 的切换，完全替换旧版本。灰度发布也称为金丝雀发布，是进行 A/B 测试的重要手段。
- 熔断机制 - “熔断”一词多出现于股市，应用服务中的熔断机制，本质上与股市并无差异，都是为了控制风险。云微服务之间往往存在依赖关系，如果其中某个服务调用出现高延迟等问题，将导致其他服务也出现问题，甚至可能导致业务系统不可用。实施熔断机制，可及时检测问题，对该服务执行熔断，避免造成更大范围的影响，同时释放资源。
- 业务编排 - 通过制定策略控制业务流量的转发，按照策略所定义的顺序，对流量进行调度，以策略化的方式统筹整个网络。
能够看出，以上这些技术的目标，都是为了建立敏态应用环境下的一种更快速、灵活、敏捷的应用发布机制。在云计算趋于成为常态的今天，充分考虑云架构特性，构建“云原生”的应用发布，已成为一大趋势。
应用交付不会退场
但我们始终需要明确的是，“演进”并非“替代”。如果在新的技术理念出现时，就将此前已经成熟稳定的传统技术实践淘汰，不但厂商不答应、企业不答应、市场也不答应。传统应用交付，仍有存在和发展的必要。
站在技术层面，未来应用发布虽然主要面向敏态环境，但如上文所述，它依旧是在稳态基础上实现的。企业对应用加速、应用安全以及高可用性的诉求，并不会因为进入云时代而消失，只会随着技术的发展而不断提高。
产品形态上，传统应用交付设备仍然具有很大的需求空间，特别是在国内。
从“新基建”到“东数西算”，作为 IT 基础设施的关键组成部分，面对全国各地日益增长的网络流量，应用交付设备在流量管理、安全防护等方面的价值，能够在数据中心发挥巨大的作用，为织就全国算力一张网、构建新型算力网络体系贡献力量。
此外，一个重要的现实原因是，出于数据安全、合规性、现有 IT 流程、延迟敏感型应用等各方面的因素考虑，许多国内企业并不能接受公有云——IDC、Gartner 等行业研究机构都曾在其报告中描述过这一现状——而是采用本地私有云部署为主的形式。
即便是在未来，与完全采用公有云相比，混合云更像是一种易于为人们所接受的架构。在私有云环境下，对传统应用交付设备的需求还会持续。
就像负载均衡从未退场一样，应用交付也不会退场。
一直游到海水变蓝
人们常常用“蓝海”和“红海”来形容市场空间的状态，毫无疑问，与已经非常成熟的应用交付相比，应用发布更像是一片蓝海。
但当我们把焦距推向十多年前时，与负载均衡相比，应用交付则是蓝海；往更久远处推，负载均衡也曾是蓝海——从 Foundry 到 F5，不同的时代书写了不同的故事。
但至少我们可以确定，蓝海永远是领先者的，也永远造就领先者。
有趣的是，从负载均衡向应用交付演进的历史来看，深入蓝海的领先者，又似乎必须曾经历红海的洗礼。当然，这里更深层原因是，在红海中锻炼出来的强大“肌肉”——足够雄厚的技术实力。
云科通明湖应用交付网关，立足于应用交付，凭借多年技术实践积累，为许多国内客户构建了安全、高效、可控的应用交付平台。云科通明湖系列产品能实现应用和网络的有效协同，保证应用系统能够被安全、高效、可控地访问，在整个 IT 架构中有着重要的战略价值和丰富的应用场景。作为负载均衡领域全球领先品牌 f5 的最佳协同者，云科通明湖同时也是信创负载均衡的领先品牌。
信创就选云科通明湖。
在不断锻炼自身肌肉的同时，云科通明湖也仰望着未来，向云时代的应用发布前行，致力于打通云管边端，帮助客户完成架构演进、拥抱敏态应用环境。在数字经济这片充满不确定的瀚海中，我们不但需要时常磨炼自身，也要持续激励自己向更远处游去。
“一直游到海水变蓝。”