由于云原生平臺會以容器、Kubernetes （K8S）等技術為基礎，因此可以說，企業未來的 IT，是云化與容器化的天下，這已經是無法逆轉的趨勢了。為什么這些技術現在會這么火，為什么它們已經成為 IT 的潮流和方向，我們還是得從應用交付這項技術的歷史以及它現在面臨的問題和挑戰談起。

企業都需要采購網絡設備、服務器、虛擬化軟件來搭建一套基礎架構平臺，但沒有任何一家企業會為買網絡設備而買網絡設備，也不會為買服務器和虛擬化軟件而去采購。企業有這些采購需求，其原因只有一個，那就是需要安裝、運行應用，并交付出去，讓內部和外部的 end user 使用。這個需求下，催生了一個新的行業的誕生，就叫做“應用交付”。

其實提到應用交付，還有一個更響亮的名稱，就是“負載均衡”。應用交付說白了就是負載均衡發展到一定階段后賦予的新含義。1996 年，隨著互聯網大規模發展，企業發現單臺服務器或小型機無法為這么多互聯網用戶提供服務了，因此需要多臺計算機來提供同一個應用服務。但是如何讓這些計算機比較平均地分攤訪問請求呢？人們很快想到了辦法——互聯網發布的應用都需要通過域名訪問，那在 DNS 服務器上增加輪詢功能，就可以負載平攤了。但是 4 臺提供同一服務的服務器掛了一臺怎么辦？DNS 服務器對后端應用服務器的健康狀況不知情，就會有 25% 的 end user 無法訪問應用。為了解決這個問題，有幾家初創公司開發了一種名為“負載均衡器”的設備，通過“健康檢查”機制，讓負載均衡器監控應用服務器的健康狀況，如果有問題就將其標記為下線，這樣就既解決了負載均衡的問題，又實現了應用高可用性和業務連續性。

負載均衡技術的實現，主要是通過“反向代理”的機制。中國移動的 10086 客服電話總機就是一種典型的反向代理，總機知道我的需求后，然后找一個空閑的且對處理我的需求經驗最豐富的專家接線員來解決。這就是因為總機知曉客戶端和服務端兩端的情況，就能提供最好的服務。負載均衡器其實就像這樣的一臺總機，充當了一個代理人的角色。它知曉客戶端的需求，又知曉服務器端的狀況，因此后來負載均衡技術得到了長足發展，除了負載均衡之外，還能實現會話保持、網頁和圖片壓縮、頁面緩存、終端加速和優化、多鏈路選擇、網頁防篡改、DDoS 防御、SSL 卸載等各種功能。由于負載均衡器已經不再單單實現負載均衡了，因此人們后來一般將其稱為“應用交付控制器”，簡稱 ADC （英文 Application Delivery Controller 的縮寫）。

但是現今，我們的應用已經發生了天翻地覆的變化。比如，遇到一些突發的流量，應用需要自動化的擴容，ADC 就不能通過手動調整配置的方式來應對，因為突發流量經常有，應用需要實現彈性的伸縮，但是 ADC 的自動化配置還難于實現，硬件 ADC 的自動化資源調用則是完全無法實現。應對突發流量，現在經常采用的做法是調用公有云的資源，但是 ADC 如何做到本地和公有云上的交付策略的一致性？其中最大的挑戰在于 end user 在使用應用時遇到了 bug、或者有新的功能建議，因此應用的版本迭代會越來越快，我們如何做到持續調整 ADC 的策略？

在這樣的需求背景下，應用開發模式已經發生了根本變化。在以往，我們一般會使用“瀑布式開發”的模型。瀑布式開發意味著會在應用的代碼設計階段將占到整個應用開發的生命周期的一半以上，并且由于其單體式、緊耦合的架構，會將框架鎖定，之后如果需求變更，就很難修改。這就意味著，現在的企業在需要隨時提升 end user 體驗、快速實現版本迭代的背景下，瀑布式開發就不會再流行了。因此人們需要實現敏捷開發，用松耦合的方式來實現代碼架構。換句話說，人們將大的代碼框架分成了多個模塊或多個服務，一旦需求有變更，只會對一個模塊或服務進行修改，這就規避了瀑布式模型下牽一發而動全身的弊端。敏捷開發的應用也被稱為“敏態應用”。這種架構，對企業的 IT 平臺提出了新的要求。

首當其中的就是微服務

微服務意味著一個應用會由多個甚至無數個服務來組成，每個服務都有自己的代碼開發邏輯，想要調整或迭代版本就會非常便捷和快速。而容器、K8S 技術又是實現微服務的最好的平臺。

其次是云化

應用需要敏捷性、隨需擴展、自動化處理突發流量、自愈等特性，那就必須使用云化平臺作為其底層基礎架構。

再有就是 DevOps

代碼的開發、運維、bug 處理、新版本上線與老版本下線等，將實現一體化。持續集成（CI）、持續部署（CD）將越來越流行?，F在這個概念已經更深入了一步，發展為 DevSecOps，將安全態勢感知和動態調整引入并結合了進來。

在這樣的技術趨勢下，我們的服務創建時間、應用的生命周期將會是秒級，將實現 100% 的自動化，應用是微服務的架構，底層則是通過容器、K8S 搭建的 PaaS 和 CaaS 平臺。我們將這樣的新型應用的模型，稱為現代化應用 “Modern Application”。在這個應用模型下，對網絡提出的挑戰其實更大，容器網絡的互連互通、7 層服務之間調用、外部訪問容器時的入向路由和負載均衡都是我們需要直面的問題。為了實現自動化，我們還需要以應用為中心來驅動網絡作出自動化配置和彈性調整。這套平臺還需要實現更好的可視化功能，這樣才能提前發現問題并調整，最終完成運維和開發的一體化。最終，我們通過這樣的網絡平臺再把現代化應用給交付出去讓 end user 可以使用。為此，我們需要重新定義這樣的現代化應用交付平臺。由于這個平臺不只關注將服務交付（或者說發布）出去，還得關心底層 2-3 層網絡的連接、服務之間如何調用。因此我們在重新定義這樣的現代化應用交付平臺的時候，會稱它為“現代化應用連接平臺”。

敏態應用在云化與容器化的網絡環境中需要實現服務全連接，再安全、靈捷、智能地實現從開發到測試再到交付的一體化。這個平臺的要求是：

l  統一的應用運行

無論應用部署在云端還是本地，是虛擬機搭建的容器環境還是物理機搭建，都需要實現一致的體驗。

l  兼容的基礎架構

我們需要實現云網融合，做到統一的網絡和安全策略，并實現 API 網關的功能。

l  統一的運維和管理

整個平臺將是全自動化的，無論是自動化的配置下發還是自動化的彈性伸縮，以及自愈、自修復能力都是必需的。此外我們需要對應用和網絡實現全可視化和分析功能，才能更好的做到開發、安全和運維一體化。

l  實現無縫的跨云遷移、容災等高級功能

這個平臺對網絡的連接提出的要求則是：

l  物理網絡與虛擬網絡的解耦

1.  由于該平臺需要搭建在云化、容器化的環境上，因此物理網絡和虛擬網絡需要做一層解耦，整合孤立的物理網絡，抽象出網元實現一致的網絡功能，并細顆粒度的安全策略。通過虛擬網絡為虛擬機以及容器 Node 實現底層網絡連通，即虛擬的路由、交換功能。

2.  再為容器 Pod 工作負載提供網絡通訊和安全策略，這是容器 2-4 層網絡功能，我們需要遵循 K8S 容器接口 CNI （Container Network Interface）標準。

l  虛擬網絡和現代化應用服務的解耦

1.  實現微服務實例間的互連、互通。包括全域名的內部服務調用、服務發布與外部域名訪問和負載均衡、多云、不同集群的服務全互連。這是容器 7 層東西向網絡功能，我們一般將這樣的技術稱為 Service Mesh （服務網格）。

2.  將聲明的 Ingress 資源轉換為可被外部訪問的對象并暴露給 end user。我們一般將這樣的技術稱為“入向路由（Ingress Router）”。由于容器內部的服務經常變動或隨時擴展，因此入向路由還需要實現負載均衡以及其它 ADC 的高級功能，讓 end user 更好的訪問現代化應用。

l  基于零信任的安全

1.  南北向服務入口安全，包括安全的服務發布和交付（Web安全防護）、4 層/7 層防火墻策略控制以及入侵檢測和防御（IPS/IDS）、DDOS 安全防護、加密/認證/授權、限速、敏感數據泄漏防護、零日攻擊防護。

2.  東西向微服務網絡安全，包括微服務東西向的安全訪問、K8S 集群內部網絡策略、容器的網絡入侵檢測和防御、異常流量檢測和分析。

3.  API 安全防護，包括 API 之間的微隔離訪問控制、針對 API 的 DDOS 攻擊、針對 API 的漏洞進行攻擊的防護、API 零日和未知威脅防御。

4.  跨云、跨集群和跨平臺的東西向微服務網絡安全及 API 威脅防御

l  可視化和分析，并實現基于零信任的安全態勢感知和自動化變更配置和策略

現代化應用連接平臺的底層物理網絡之上，需要虛擬網絡處理容器環境的 2-4 層流量，包括虛擬機與 Node 的網絡連接、Pod 網絡的連通性、多云和跨集群的網絡連通。對于 7 層應用服務，需要東西向的服務調用以及南北向的服務暴露、發布、負載均衡。整個平臺需要完整的安全策略以及深度的可視化和監控。VMware 是業界唯一能提供完整的解決方案的廠商。

l  底層網絡互連

對于虛擬機、容器 Node 的網絡互連，在非 VMware 環境一般使用的是物理網絡。但是 VMware NSX-T 解決方案可以打通物理網絡的孤島，抽象出網元實現轉控分離的 SDN 架構和一致的網絡功能，甚至打通多中心、多云環境，實現整個虛擬網絡，實現多云、多中心一致的網絡和安全策略。NSX-T 最早來自 VMware 在 2012 年收購的 SDN 鼻祖公司 Nicira，現在已經是非常成熟的解決方案了，有廣泛的客戶在生產環境中使用。

l  容器網絡接口 CNI

由于容器、K8S 開源的屬性，催生了很多開源的網絡解決方案。

容器的最小功能單元叫做 Pod。敏態應用的特點就是版本的快速迭代和上線，因此容器的做法是直接銷毀一個 Pod 并基于新版本拉起一個新的 Pod。加上為了應對突發流量，Pod 隨時可能被復制并調用更多的資源提供服務。因此 Pod 的地址經常變動且經常擴展，傳統網絡的路由和交換協議就不適用了。K8S 容器接口 CNI 的標準，就是為了實現 Pod 互連而提出的。開源的實現主要有 Flannel 和 Calico。Flannel 主要通過各種 NAT 實現交換功能，配置會非常復雜，且不支持多集群、多中心。而 Calico 則通過運營商級別的路由協議 BGP 來實現全路由，但是很少有金融和企業客戶真正把它用好，這是因為底層物理網絡需要配置 BGP 協議來配合，且該協議本身非常復雜，有 13 條選路原則，K8S 的運維人員和應用開發者并非網工出身，就只能尋求網絡部門的幫助，而網絡部門的人又不一定懂容器，不一定懂 Calico。如果用戶同時需要 K8S 路由和交換功能，那么 Flannel 和 Calico 的組合使用會更加復雜。

VMware 有三套解決方案來解決這個問題：

第一個方案叫 NCP，全稱是 NSX Container Plugin。

其實現是將 NSX 的一個插件安裝在容器的 Node 里，由其提取 Pod 的信息交給 NSX 控制器再由 NSX 的數據平面實現全網的路由和交換。這樣做的好處是可以為一些租戶、一些專門的應用集群分配專門的地址段，這個地址段能被外部的物理防火墻等安全設備或流量分析設備所識別。它還消除了復雜的 Flannel 和 Calico 的路由和交換實現，用自上而下的統一的控制器去下發所有的 2-4 層網絡配置，并轉發流量。這個方案一般用于部署在 VMware vSphere 環境上的 K8S 平臺。

第二個方案叫 Antrea。

Antrea 是 VMware 發起的開源項目，它創新地利用了OVS（Open vSwitch）的網絡功能實現了 CNI 的容器網絡標準。由于 OVS 同時支持路由和交換，就不需要 Flannel 和 Calico 的組合，且因為其配置簡單、易于擴展等特性，可以讓 K8S 集群支持到數千 Node 以及數萬 Pod 的規模。目前VMware 自己的 Tanzu 平臺就是通過 Antrea 實現 CNI 網絡功能，而且也有開源 K8S 已經使用 Antrea 了。VMware 的 Antrea 企業版會有更強的功能、更好的可視化，且可以被 NSX-T 的控制器管理和控制。這個方案一般用于 VMware Tanzu 環境或非 vSphere 平臺上的 K8S 如裸機 K8S、公有云等。

此外，我們還可以使用 NCP 和 Antrea 的組合方案。

這個方案下，其實管理和控制平面只有 NSX控制器。通過 NCP 實現更高級的功能，借助 Antrea 實現更強的擴展性。這個方案可以使用在任何 K8S 環境。

l  東西向服務流量

實現容器集群內部服務之間的東西流量的訪問，一般都是通過域名的方式，也是就是純 7 層網絡流量的訪問了，這時候 CNI 的標準已不適用。開源的解決方案是 Istio，它提供了 NameSpace 這種簡單的方式來為已部署的服務建立 Service Mesh 網絡全連接并實現服務隔離，該網絡具有內部負載均衡、服務間認證、監控等功能。

但是 Istio 的 NameSpace 只能實現單集群的 Service Mesh 和隔離。不只是 Istio，大多數服務網格實現只關注服務而忽略了用戶和數據。用戶使用服務來訪問數據，如果應用運行在多集群或多云環境中，就無法集中管理用戶、服務和數據之間的通信和訪問。

為此，VMware 創新的使用 TSM（Tanzu Service Mesh）功能來實現 Global NameSpace （全局命名空間，GNS）。它通過將 Service Mesh 擴展到 K8S 集群之外并提供跨異構平臺和技術（包括虛擬機和其他服務網格）的統一操作層，解決了與分布式微服務應用的挑戰。

TSM 通過將這些對象排列在稱為 GNS 的邏輯組中，為分布式應用中的資源提供服務網格功能。GNS 不綁定到單個集群，而是連接兩個或多個集群之間的資源。每個 GNS 都為其對象管理服務發現、可觀察性、加密、策略和服務級別目標 (SLO)，而不關心它們駐留在何處，無論是在多個集群、邊緣站點還是云端。

l  入向訪問和負載均衡

用戶的應用以 Pod 的形式運行在 K8S 集群的 Node 中。但是由于 Pod 的 IP 地址經常在變化，用戶就無法使用某個固定的 IP 地址來訪問 Pod。另外，Pod 可以以集群的方式橫向擴展的，這就有了服務發現和負載均衡的需求。和傳統的應用類似，部署在 K8S 中的應用除了負載均衡，也需要實現各種應用交付的策略，比如基于 Virtual Host、基于各種策略的消息路由、會話保持、頁面緩存、壓縮和優化、SSL、HTTP Header 的處理、WAF 等等。并且相對于傳統應用來說，K8S 平臺上運行的應用由于其動態性和申明式的特點，其應用交付的方式還有所差別的。

開源的做法是通過 Nginx 或 HA Proxy 來實現，它們將自己的反向代理實例在 Node 里充當一個 Pod 來實現入向路由，但是高級的應用交付功能，需要 K8S 集群外部的傳統 ADC來實現。這樣的實現首先路徑不優化——外部的 ADC 需要隨機找到一個 Nginx 或 HA Proxy 的 Pod，然后 Nginx 或 HA Proxy 再通過內部的機制，找到最優的服務提供給訪問者，流量需要兩層尋址。再者，云化環境中，外部的 ADC 使用硬件已不再合適，但是傳統 ADC 廠商的軟件，和其硬件幾乎沒什么區別，尤其是目前還沒有任何一家傳統 ADC 廠商能在其軟件 ADC 上實現 vMotion、HA、DRS 等功能，這就意味著傳統 ADC 的軟件版本仍然是豎井式、煙囪式的架構，無法實現資源池，也無法靈活調度資源，更無法實現自動化。我們為什么要從小型機轉向虛擬化，為什么要從磁盤陣列轉向超融合，相信讀者都是清楚的——這就是為了消除豎井式的服務器、豎井式的存儲架構，并實現資源池。傳統 ADC 廠商的在云化環境中的軟件版本，仍然走了豎井式、煙囪式的架構的老路。最后就是性能，由于 Nginx 和 HA Proxy 都是自己作為 Pod 安裝在 K8S 集群內部，這樣會消耗 K8S 集群性能，能擴展的 Pod 就會變少，K8S 集群整體性能和擴展性都會受到影響。

VMware 的解決方案是 NSX ALB，全稱是 NSX Advanced Load Balancer，它來自 VMware于 2019 年收購的純軟件 ADC 公司 Avi Networks，因此我們一般簡稱這個產品叫做 Avi。Avi 首先使用了基于 SDN 的轉控分離的架構，配置和部署就變得非常簡單且能實現資源池，有很好的彈性以及自愈的架構，這就解決了我之前提到的豎井式 ADC 架構問題。此外，對于容器的入向路由，Avi 的做法是將 AKO（Avi K8S Operator）或 AMKO（Avi Muti K8S Operator）以插件的形式部署在 K8S Node 內（是不是和 NCP 的實現很像）。這樣做的好處是，AKO 或 AMKO 提取各種 Pod 信息，告訴 Avi 控制器，再由控制器自動下發配置給 Avi 的轉發平面SE（Service Engine）。這樣帶來的優勢是扁平架構，流量無需兩層選路就能找到最優的服務暴露給 End User，其次也解決了 Nginx 和 HA Proxy 的實現帶來的性能問題，因為 AKO 和 AMKO 沒有 K8S 集群內部的性能損耗，Avi 控制器和 SE 又是部署在 K8S 集群外部，充分發揮了云化環境資源池的威力。

Avi 還有自帶的 Waf 功能，一般暴露出來的服務很多都是 Web 服務，Avi 就可以通過 Waf 來保護它們。Avi 還可以實現 DNS 和 GSLB （全局負載均衡）功能，對于 TSM 的多云、多集群的 GNS 功能可以實現很好的配合。

Avi 現在甚至可以被 NSX 控制器管理和控制，這就意味著，整套現代化應用連接平臺的解決方案，從 VM、Node 網絡，到 Pod 互連，到服務暴露和入向訪問、負載均衡，都是可以統一管理的。

Avi 還內置了可視化和分析模塊，甚至能取代一些專業 APM 廠商提供的功能，如每個服務的延時、分析安全事件、分析終端類型和地理位置、智能排錯等，下面幾張圖片分別就是這些功能的截圖。而傳統 ADC 針對應用實現可視化和分析，往往是將 log 吐給專業的分析工具如 ELK 或 Splunk 來實現，這就意味則分析不是實時的，且架構會變得非常復雜。

l  云內生的零信任安全

VMware 還有完整的現代化應用安全解決方案，基于零信任的框架。由于介紹起來篇幅會比較長，我們以后會專門再寫一篇文章來介紹 VMware 針對現代化應用的零信任案解決方案。

l  可視化和分析

關于可視化和分析，我們剛才其實已經提到了，Avi 天生可以實現一些 APM 的功能（該功能是免費的）。而針對 NPM，VMware 同樣有強大的 VRNI 軟件。并且我們還可以通過結合現代化應用零信任安全解決方案，通過安全態勢感知，自動化地觸發策略實現現代化應用連接平臺的配置變更，保護您的應用。

l  整體方案優勢

有了 VMware 現代化應用連接平臺，現代化應用在數據中心內部就可以實現按需擴展，并可以方便的擴展到公有云和服務商邊緣，在業務對外交付、發布的過程中實現全局一致的網絡和安全策略，以及無縫的業務遷移，并可以由 NSX 全局管理跨云的所有網絡服務。應用從開發到上線無需考慮復雜的網絡架構。

平臺有內置的分析和可視化，加上扁平、輕量級的架構，可以提升運維效率，還有基于零信任框架的安全，最終實現 DevSecOps 一體化，助力應用敏捷開發、上線和迭代。