為了真正能夠在任何地方提供數(shù)字能力，企業(yè)必須放棄熟悉的“直接遷移”并轉(zhuǎn)向 CNP（Cloud-NativePlatform，云原生平臺）。CNP 運用云計算的核心能力，向使用互聯(lián)網(wǎng)技術(shù)的技術(shù)創(chuàng)造者提供可擴(kuò)展的彈性IT相關(guān)能力“即服務(wù)”，從而加快價值實現(xiàn)時間并降低成本。因此，Gartner 預(yù)測到 2025 年，云原生平臺將成為 95% 以上新數(shù)字倡議的基礎(chǔ)，而在 2021 年這一比例只有不到 40%。

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

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

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

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

　　但是現(xiàn)今，我們的應(yīng)用已經(jīng)發(fā)生了天翻地覆的變化。比如，遇到一些突發(fā)的流量，應(yīng)用需要自動化的擴(kuò)容，ADC 就不能通過手動調(diào)整配置的方式來應(yīng)對，因為突發(fā)流量經(jīng)常有，應(yīng)用需要實現(xiàn)彈性的伸縮，但是 ADC 的自動化配置還難于實現(xiàn)，硬件 ADC 的自動化資源調(diào)用則是完全無法實現(xiàn)。應(yīng)對突發(fā)流量，現(xiàn)在經(jīng)常采用的做法是調(diào)用公有云的資源，但是 ADC 如何做到本地和公有云上的交付策略的一致性？其中最大的挑戰(zhàn)在于 end user 在使用應(yīng)用時遇到了 bug、或者有新的功能建議，因此應(yīng)用的版本迭代會越來越快，我們?nèi)绾巫龅匠掷m(xù)調(diào)整 ADC 的策略？

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

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

　　應(yīng)用需要敏捷性、隨需擴(kuò)展、自動化處理突發(fā)流量、自愈等特性，那就必須使用云化平臺作為其底層基礎(chǔ)架構(gòu)。

　　代碼的開發(fā)、運維、bug 處理、新版本上線與老版本下線等，將實現(xiàn)一體化。持續(xù)集成（CI）、持續(xù)部署（CD）將越來越流行。現(xiàn)在這個概念已經(jīng)更深入了一步，發(fā)展為 DevSecOps，將安全態(tài)勢感知和動態(tài)調(diào)整引入并結(jié)合了進(jìn)來。

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

　　敏態(tài)應(yīng)用在云化與容器化的網(wǎng)絡(luò)環(huán)境中需要實現(xiàn)服務(wù)全連接，再安全、靈捷、智能地實現(xiàn)從開發(fā)到測試再到交付的一體化。這個平臺的要求是：

　　無論應(yīng)用部署在云端還是本地，是虛擬機(jī)搭建的容器環(huán)境還是物理機(jī)搭建，都需要實現(xiàn)一致的體驗。

　　我們需要實現(xiàn)云網(wǎng)融合，做到統(tǒng)一的網(wǎng)絡(luò)和安全策略，并實現(xiàn) API 網(wǎng)關(guān)的功能。

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

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

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

　　由于容器、K8S 開源的屬性，催生了很多開源的網(wǎng)絡(luò)解決方案。

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

　　

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

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

　　第二個方案叫 Antrea。

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

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

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

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

　　但是 Istio 的 NameSpace 只能實現(xiàn)單集群的 Service Mesh 和隔離。不只是 Istio，大多數(shù)服務(wù)網(wǎng)格實現(xiàn)只關(guān)注服務(wù)而忽略了用戶和數(shù)據(jù)。用戶使用服務(wù)來訪問數(shù)據(jù)，如果應(yīng)用運行在多集群或多云環(huán)境中，就無法集中管理用戶、服務(wù)和數(shù)據(jù)之間的通信和訪問。

　　為此，VMware 創(chuàng)新的使用 TSM（Tanzu Service Mesh）功能來實現(xiàn) Global NameSpace （全局命名空間，GNS）。它通過將 Service Mesh 擴(kuò)展到 K8S 集群之外并提供跨異構(gòu)平臺和技術(shù)（包括虛擬機(jī)和其他服務(wù)網(wǎng)格）的統(tǒng)一操作層，解決了與分布式微服務(wù)應(yīng)用的挑戰(zhàn)。

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

　

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

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

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

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

　　Avi 現(xiàn)在甚至可以被 NSX 控制器管理和控制，這就意味著，整套現(xiàn)代化應(yīng)用連接平臺的解決方案，從 VM、Node 網(wǎng)絡(luò)，到 Pod 互連，到服務(wù)暴露和入向訪問、負(fù)載均衡，都是可以統(tǒng)一管理的。

　　

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

　　

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

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

　　有了 VMware 現(xiàn)代化應(yīng)用連接平臺，現(xiàn)代化應(yīng)用在數(shù)據(jù)中心內(nèi)部就可以實現(xiàn)按需擴(kuò)展，并可以方便的擴(kuò)展到公有云和服務(wù)商邊緣，在業(yè)務(wù)對外交付、發(fā)布的過程中實現(xiàn)全局一致的網(wǎng)絡(luò)和安全策略，以及無縫的業(yè)務(wù)遷移，并可以由 NSX 全局管理跨云的所有網(wǎng)絡(luò)服務(wù)。應(yīng)用從開發(fā)到上線無需考慮復(fù)雜的網(wǎng)絡(luò)架構(gòu)。

　　平臺有內(nèi)置的分析和可視化，加上扁平、輕量級的架構(gòu)，可以提升運維效率，還有基于零信任框架的安全，最終實現(xiàn) DevSecOps 一體化，助力應(yīng)用敏捷開發(fā)、上線和迭代。

　　本文從應(yīng)用交付的歷史談起，介紹了現(xiàn)代化應(yīng)用開發(fā)的特點、現(xiàn)代化應(yīng)用連接平臺以及 VMware 的解決方案。該解決方案為您在的容器化的環(huán)境中帶來全新的應(yīng)用連接和交付體驗。

　　如果您想了解更多技術(shù)細(xì)節(jié)，歡迎與我們的銷售或售前工程師聯(lián)系。謝謝。

　　范恂毅

　　VMware 大中華區(qū) Avi 產(chǎn)品經(jīng)理

　　14 年 IT 行業(yè)經(jīng)驗，持有安全、語音、數(shù)據(jù)中心三個方向 CCIE 認(rèn)證，曾在 F5、Nutanix 等知名 IT 公司擔(dān)任技術(shù)顧問，現(xiàn)任 VMware 大中華區(qū) Avi 產(chǎn)品經(jīng)理，負(fù)責(zé) VMware 應(yīng)用交付業(yè)務(wù)的推廣和銷售工作。