文章來源：F5 Point官網

從負載均衡到雲原生應用服務
從 Web 時代開始至雲原生時代的應用服務交付的市場，技術與人的變化。

PART.01生來簡單 Load Balancing

上世紀九十年代，Internet 的快速發展催生了大量在線網站，Web 訪問量迅速提升。 在當時，一個樸實的訴求是如何提高 Web 網站的訪問速度與能力。

彼時，在西雅圖市中心斜坡上的 Six Arms 酒吧里，每晚都有幾個年輕人在這裡熱烈的討論著他們的創業夢想，他們沉迷於人機介面，研究如何突破沉浸式虛擬實境的極限。 Michael Almquist 便是其中的一個，他發現當時的伺服器滿足不了他們的需求，於是他們研究使用負載均衡來幫助解決他們遇到的問題。

1996年，F5 Labs 在西雅圖塔五樓的一個破舊辦公室里成立，Michael Almquist 是創立人。 這樣一個技術被投資人發現，將F5Labs從虛擬實境技術領域帶入到了一個幫助實現無故障、高效互聯網通信的世界。

與 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 發佈的同一年，一個叫Arrow Point 的公司成立，主要面向 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 的同領域公司。

PART.02成在紛繁 ADC

2000年互聯網泡沫達到了鼎盛，而這一年也是該領域相關廠商成立最多的一年。 Fine Ground，一個Web 優化、應用加速與安全廠商;應用前端優化廠商 Redline;廣域網優化廠商 Peribit。 應用安全廠商Magnifire。 同時 Array 也在這一年成立。 如果翻閱資料我們會發現在這個階段市場關於產品會有很多名詞。 除了上述提到的”Web交換機”，還有”內容（content）交換機”、四層交換機、七層交換機。不同技術背景的廠商正在進行一場暗自角力。

2001年，美股重挫，互聯網公司泡沫擠破。 僅僅依賴給互聯網 Web 網站做簡單 Load Balancing 的生意模型不再能夠持續。 梳理2000-2005年間這個領域的收購，可以看出市場開始變得紛繁複雜，大量廠商成立與大量廠商收購：

1. 2000年，Cisco 收購了Arrow Point，同年創建的Fine Ground也同樣被思科在2005年收購，通過這樣的收購思科最終完成了其應用內容網路（AON）技術產品的構建。
2. 2003年，F5 收購了 uRoam，構建了後來面向 SSL VPN 及訪問身份與策略管理的 APM 模組。
3. 2004年，F5 收購了Magnifire，構建WAF產品能力。 即目前的 Advance WAF 模組。
4. 2005年，F5 收購了 Swan Labs 來豐富廣域網加速方面的能力，即後來的 WOM 模組。
5. 2005年，Citrix 收購了 Netscaler，成為其後來的應用交付類產品。
6. 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年的連續三次收購則説明 F5 快速地形成了完整的 ADC 產品線。

2004年TMOSV9版本發佈，將市場帶入了一個新的發展軌道。 2005年中期，Gartner 宣佈 F5 已獲得最高 ADC 市場份額。

2006年是 ADC 市場成熟的標誌。 以F5為代表的 ADC 技術已經形成了領域的事實標準，產品形成了連接管理，協定控制，SSL 卸載，Web 壓縮與優化，流量整形，DoS 防護，Web 安全，IPv6，鏈路負載，GSLB 等豐富的應用交付方面能力。 技術架構部署上，基本類似於下圖：

鞏固一個成熟的市場並不是一件容易的事情，需要不斷的進行技術研發投入以確保在行業的競爭力。2006至2008間是歷史上 F5 研發投入增長非常高的階段。 儘管當時正值全球經濟危機期間，研發投入季度同比增長保持在了30%-40%之間。

而此時，同領域的幾個大型企業在研發投入與市場收入上卻不成比例。 無論是因為缺乏投入還是因為技術路線問題，他們最終因缺乏技術競爭力而逐步退出市場。

1. 2008年 Juniper 放棄其 DX 產品線，宣佈退出
2. 2009年 Nortel 終結，Radware 收購Alteon資產
3. 2010年 Cisco 停止銷售 AON 以及 ACE XML 閘道產品
4. 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 進一步加強軟負載領域市場。

PART.03歸於簡單 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 發展的三個方向。

（雲原生下的ServiceProxy發展的三個方向）

當前，伴隨著雲、PaaS 的發展。 已經到了基礎架構（I&O）引導創新的階段，企業基礎架構正在變為支撐企業業務創新的核心引擎，Service Proxy 作為這類 Infrastructure 元件，正在扮演這越來越重要的角色。 它決定了企業的基礎架構是否能夠更好、更優、更安全的運行。

PART.04面向當下 Enterprise Cloud Native Application Service

當我們回到企業的實際場景，用一張圖來表達這個相關領域的變化時候，可以看到相關領域產品的部署位置在不斷的提升，從基礎的網路硬體變成了雲化環境下的一個服務元件，以及成為雲原生環境下的一個邏輯資源物件。 從看得見摸得著變成了看得見摸不著，從看得見摸不著變成了看不見摸不著。 企業應充分重視能夠覆蓋所有場景的軟負載類產品選型，確保企業能夠在統一的技術與專業服務下演進企業應用架構，避免技術風險。

（負載均衡，一個不斷提升的位置）

雲原生架構是企業未來的方向，然而企業的雲原生架構並不會一蹴而就。 它必然是在企業現有IT基礎設施之上慢慢演進，在這樣一個演進的進程中，企業正在建設的雲原生環境需要利用企業的已有基礎設施。 企業的已有基礎設施也要面向雲原生環境進行改變，兩者之間需要相互融合。

基礎設施如此，人員亦如此。 隨著企業基於平臺能力構建的提升，我們可以清晰的看到 I&O 人員正在成為未來數據中心技術創新的主力。 該領域的主導角色人員從網路人員變成了開發人員，而最終變成了平台人員。

總結

可以看出，從1996到2006，再到2016。 應用交付領域每一個10年變化都呼應了市場的需求變化，切合了應用架構的變革。 從單純的 Web 負載均衡到複雜的企業應用交付，從單體應用到分散式、微服務架構。 所面向的人群也從網路人員到應用人員到如今的平臺、基礎架構人員。 無論是 ADC 功能的紛繁複雜，還是 Service Proxy 的簡單高效，應用交付領域的產品已成為企業最重要的基礎設施元件。

企業如何在雲原生進程中走的更順，如何讓雲原生環境應用交付更加平滑。 企業需要一套真正能夠面向企業當下實際環境的雲原生應用服務方案。