从负载均衡到云原生应用服务

生来简单Load Balancing

上世纪九十年代，Internet的快速发展催生了大量在线网站，Web访问量迅速提升。在当时，一个朴实的诉求是如何提高Web网站的访问速度与能力。

彼时，在西雅图市中心斜坡上的Six Arms酒吧里，每晚都有几个年轻人在这里热烈的讨论着他们的创业梦想，他们沉迷于人机接口，研究如何突破沉浸式虚拟现实的极限。Michael Almquist便是其中的一个，他发现当时的服务器满足不了他们的需求，于是他们研究使用负载均衡来帮助解决他们遇到的问题。

1996年，F5 Labs在西雅图塔五楼的一个破旧办公室里成立，Michael Almquist是创立人。这样一个技术被投资人发现，将F5 Labs从虚拟现实技术领域带入到了一个帮助实现无故障、高效互联网通信的世界。

与F5同一年成立的还有Alteon与Radware，只是这两家公司在十多年后才彼此发生了故事。Juniper也在这一年成立，与F5在后续的几年里曾有过一致的市场。

在互联网泡沫破灭以前，这个领域基本是围绕如何对Web网站进行负载均衡与优化。因而在早期，也会有“Web交换机”的说法。其基本思想是通过将连接分发到更多的不同服务器上来实现更大访问能力，当一台服务器宕机后，用户依然可以访问其他可用服务器。核心技术即为Load Balancing，并附加了一些Web优化能力。技术部署形态基本如下：

1997年F5发布了BIG-IP产品。BIG-IP最早的命名实际叫BIG/IP，源自于TCP/IP这一叫法，BIG则表达了一个超级IP代表众多背后服务IP的意思。就在BIG-IP发布的同一年，一个叫ArrowPoint的公司成立，主要面向Web优化。

1998年F5发布了3DNS产品。论Load Balancing，DNS一直是一个本源技术，3DNS产品在DNS轮询解析这一基础技术之上扩展空间（源、目标）、时间（可用性）的概念，形成了three dimensions（3D），这也是3DNS命名的由来，后来名称改为Global Traffic Management(GTM)，近几年则又命名为DNS以表达完善全面的企业DNS架构。我们从名称的变化其实可以看出不同阶段市场方向的重点。使用智能DNS技术帮助进一步提升了Web访问体验，使得用户可以及时访问到最近可用站点。3DNS所用的技术理念直至今日依然被广泛使用，无论是全局流量管理还是企业基础DNS。同年，业界还成立了两家公司，uRoam和Netscaler。一家后来被F5收购，一家则是F5的同领域公司。

成在纷繁 ADC

2000年互联网泡沫达到了鼎盛，而这一年也是该领域相关厂商成立最多的一年。Fineground，一个web优化、应用加速与安全厂商；应用前端优化厂商Redline；广域网优化厂商Peribit。应用安全厂商Magnifire。同时Array也在这一年成立。如果翻阅资料我们会发现在这个阶段市场关于产品会有很多名词。除了上述提到的“Web交换机”，还有“内容（content）交换机”、四层交换机、七层交换机。不同技术背景的厂商正在进行一场暗自角力。

2001年，美股重挫，互联网公司泡沫挤破。仅仅依赖给互联网Web网站做简单Load Balancing的生意模型不再能够持续。梳理2000-2005年间这个领域的收购，可以看出市场开始变得纷繁复杂，大量厂商成立与大量厂商收购：

• 2000年，Cisco收购了ArrowPoint，同年创建的Fineground也同样被思科在2005年收购，通过这样的收购思科最终完成了其应用内容网络（AON）技术产品的构建。
• 2003年，F5收购了uRoam，构建了后来面向SSL VPN及访问身份与策略管理的APM模块。
• 2004年，F5收购了Magnifire，构建WAF产品能力。即目前的Advance WAF模块。
• 2005年，F5收购了Swan Labs来丰富广域网加速方面的能力，即后来的WOM模块。
• 2005年，Citrix收购了Netscaler，成为其后来的应用交付类产品。
• 2005年，Juniper通过收购Peribit与Redline打造其面向应用的产品线。

而在这狂乱的背后，一个标准化的市场领域正在被塑造。从上述各家厂商的收购技术方向可以看出，在当时技术趋势已经比较清晰，市场正在围绕如何更快、更安全的访问应用，并确保应用可用进行构建。

2003年Gartner第一次定义了Application Delivery Controller(ADC)概念。在早期，ADC的定义依然主要是负载均衡技术与卸载类技术的组合，并面向Web。当前最新的定义则为:

应用交付控制器 (ADC)部署在数据中心，通过卸载服务器、提供深度有效负载检查和充分利用复杂协议来优化应用性能、安全性和资源效率。它们最初部署用于面向外部的 Web 应用程序，现在用于为多种类型的业务应用程序和协议提供服务。

可以看出，后来的ADC产品更加面向企业复杂应用的处理。这也是为什么有论点认为ADC应该成为一种平台，它有类似于中间件的属性，来帮助企业更好的交付应用。

股灾使得这个领域企业开始考虑将技术应用场景从互联网Web网站转向企业应用。2002年对F5来说是最为关键的一年，这一年F5确立了TMOS（Traffic Management Operating System）作为BIG-IP的基础。这一实时的事件驱动的流量操作系统奠定了后来F5在应用交付网络（ADN）领域的领军地位。而2003，2004，2005的连续三次收购则帮助快速形成了完整的ADC产品线。

2004年TMOS V9版本发布，将市场带入了一个新的发展轨道。2005年中期，Gartner宣布F5已获得最高ADC市场份额。

2006是ADC市场成熟的标志。以F5为代表的ADC技术已经形成了领域的事实标准，产品形成了连接管理，协议控制，SSL卸载，Web压缩与优化，流量整形，DoS防护，Web安全，IPv6，链路负载，GSLB等丰富的应用交付方面能力。技术架构部署上，基本类似于下图：

巩固一个成熟的市场并不是一件容易的事情，需要不断的进行技术研发投入以确保在行业的竞争力。2006至2008间是历史上F5研发投入增长非常高的阶段。尽管当时正值全球经济危机期间，研发投入季度同比增长保持在了30%-40%之间。

而此时，同领域的几个大型企业在研发投入与市场收入上却不成比例。无论是因为缺乏投入还是因为技术路线问题，他们最终因缺乏技术竞争力而逐步退出市场。

• 2008年Juniper放弃其DX产品线，宣布退出
• 2009年Nortel终结，Radware收购Alteon资产
• 2010年Cisco停止销售AON以及ACE XML网关产品
• 2012年Cisco正式停止ACE研发

Nortel，Cisco，Juniper的失败案例充分说明ADC领域是一个高技术投入的市场。需要不断的技术积累，也需要不断的技术突破。一直以来，F5的年研发投入占收入比基本都在17%-18%左右，高于软件及互联网行业的15.7%均值。年研发投入额接近F5中国市场同年收入的5倍。不断的高研发投入确保了F5在行业的技术领军地位。

正是因为ADC产品的成熟，在2009年左右，市场一度发出Load Balancing已死的论调，以强调企业应重视ADC产品的能力。F5 ADC类产品具有丰富的面向应用的能力，例如丰富且深度的协议控制、基于事件的可编程架构、面向连接的精细化管理，免reload的高动态性配置、全面的自动化及API接口、丰富的可观测能力。企业可以充分开放这些能力将其提供给应用团队、中间件团队。

在ADC产品快速发展的的这一阶段，另一个领域也在不断的发展，这就是以NGINX、HAproxy为代表的软负载领域。

NGINX从2004年9月开始发展，HAproxy从2005年12月开始发展，这两个产品的源起与F5的源起类似，都是因为自身业务的实际需要而开发。NGINX为了解决网站的高并发问题，而HAproxy则是为了解决作者本身所在安全公司的一个应用会话保持的问题。最终逐步演化为了如今典型反向代理软件。

时间上看，从ADC类硬件产品在2003年确立开始，软负载类产品就与硬件ADC类产品一同发展。云以及头部互联网公司对软负载的使用加速了软负载产品场景的应用，将其更加曝光于大众，从而被更多人了解。无论是LVS，Tengine，Openresty，ELB等。

2016年则是企业市场对于软负载认知拐点。伴随着企业对数字化转型，DevOps，双模IT，弹性架构，企业私有云的进一步深入，软负载开始被普遍提及并应用。

基于对软负载市场的理解，F5从2009年开始发布TMOS的Virtual Edition（VE），积极构建相关产品的云中初始化能力、加强DevOps类工具生态建设如Ansible/Terraform模块等，开放命令式与声明式接口实现更多Gitops能力。这些能力可以让企业更快更好的部署F5 VE软ADC产品以适应业务的需要。有一个有趣的数字，F5利用19年时间在中国部署了5万套硬件设备，平均每年2600余台。而仅在2020春节疫情期间，就快速帮助用户部署了3000套软件ADC。软负载易于部署的优势得到了极大的发挥。

随后，2019年F5收购了NGINX进一步加强软负载领域市场。

归于简单 Service Proxy

随着应用架构的发展，应用正从传统的单体应用转变为分布式或微服务。无论是分布式还是微服务架构，其核心是将一个应用的多个服务拆分，形成相对独立的服务工作单元。而拆分的直接结果就是需要有一套额外的机制来确保这些独立的工作单元能够协调统一的工作，这离不开分布式计算、存储、消息等。当这些独立的服务单元需要相互通信时，就需要思考如何让这些通过网络进行通信的服务之间运行的更可靠、更安全、更优化。这本就是应用交付领域所关注的，只是从原来面向用户、面向网络转变为了面向服务。我们称之为Service Proxy。

分布式内的接入网关，或者微服务的API网关都是典型的ADC类需求，如身份识别、SSL卸载、内容路由、应用安全、限流限速、DDOS等。这些场景很长时间以来是由开发者驱动，由于软件的特性，使得开发者更加容易接触到类似NGINX这类软件产品。这是一个相对于传统ADC产品，用户角色的一个典型变化。

在微服务、云原生等环境下，服务与服务之间的通信接口更加简单与统一，这使得对反向代理类软件的技术需求也开始变得简单，不再需要如此复杂丰富的特殊协议支持，不再需要复杂的网络技术特性需求。需要的是让软负载类产品能够具备更加高动态性的配置，能够与注册中心、配置中心联动实现服务的发现与策略的导入，需要产品足够轻量易部署且能适合虚机、容器等多种场景的使用，需要性能上足够的快，需要提供足够的可观测数据，需要足够的弹性部署能力等等。

（云原生下我们已很难直接看到一个具象存在的负载均衡器）

2017年左右，伴随着云原生的发展，Service Proxy开始大量出现。围绕Ingress Controller，Sidecar, API网关的产品层出不穷，如Linkerd, Envoy,Gloo,Mosn等等。从传统ADC到如今以服务为中心的现代轻量级解耦式Service Proxy，技术正在回归到类似面向Web的简单的负载均衡时代，客户端负载均衡或服务端负载均衡。

2017年底，F5推出了基于Istio的商业服务网格解决方案产品Aspen Mesh。帮助用户更可靠的使用服务网格技术。

2019年，F5收购NGINX。基于NGINX打造现代应用API网关，K8S Ingress Controller，云原生应用保护，NGINX服务网格等产品方案。

2021年，F5收购初创公司Volterra。帮助企业基于K8S技术实现多云及边缘应用管理。

这些产品的推出使得F5快速覆盖了云原生 Service Proxy发展的三个方向。

（云原生下的Service Proxy发展的三个方向）

面向当下 Enterprise Cloud Native Application Service

当我们回到企业的实际场景，用一张图来表达这个相关领域的变化时候，可以看到相关领域产品的部署位置在不断的提升，从基础的网络硬件变成了云化环境下的一个服务组件以，以及成为云原生环境下的一个逻辑资源对象。从看得见摸得着变成了看得见摸不着，从看得见摸不着变成了看不见摸不着。企业应充分重视能够覆盖所有场景的软负载类产品选型，确保企业能够在统一的技术与专业服务下演进企业应用架构，避免技术风险。

（负载均衡，一个不断提升的位置）

云原生架构是企业未来的方向，然而企业的云原生架构并不会一蹴而就。它必然是在企业现有IT基础设施之上慢慢演进，在这样一个演进的进程中，企业正在建设的云原生环境需要利用企业的已有基础设施。企业的已有基础设施也要面向云原生环境进行改变，两者之间需要相互融合。

基础设施如此，人员亦如此。随着企业基于平台能力构建的提升，我们可以清晰的看到I&O人员正在成为未来数据中心技术创新的主力。该领域的主导角色人员从网络人员变成了开发人员，而最终变成了平台人员。

总结

可以看出，从1996到2006，再到2016。应用交付领域每一个10年变化都呼应了市场的需求变化，切合了应用架构的变革。从单纯的Web负载均衡到复杂的企业应用交付，从单体应用到分布式、微服务架构。所面向的人群也从网络人员到应用人员到如今的平台、基础架构人员。无论是ADC功能的纷繁复杂，还是Service Proxy的简单高效，应用交付领域的产品已成为企业最重要的基础设施组件。