商業(yè)市場的快速變化導(dǎo)致企業(yè)尋求不斷加快數(shù)字化轉(zhuǎn)型，不斷推出新的應(yīng)用以吸引客戶并提升用戶滿意度。

為了縮短應(yīng)用開發(fā)和上線周期，他們正在尋求實施持續(xù)交付/持續(xù)集成 (CI/CD) 實踐;并且為了降低成本、提高系統(tǒng)抗風(fēng)險能力，使用著包括裸機(jī)服務(wù)器、虛擬機(jī)和容器在內(nèi)的各種計算基礎(chǔ)設(shè)施，將應(yīng)用從本地擴(kuò)展到跨多個公共云的“數(shù)據(jù)中心”。應(yīng)用開發(fā)人員以及應(yīng)用所有者，希望通過 GitOps 或 CI/CD 流水線方法，自動化地完成應(yīng)用的多次、多位置的重復(fù)部署。但是應(yīng)用最終是運行在“基礎(chǔ)設(shè)施層”之上，在運行和維護(hù)方式上，現(xiàn)代化應(yīng)用層與基礎(chǔ)設(shè)施層之間的差距是巨大的。

應(yīng)用層使用 DevOps 和 CI/CD 方法時，最佳選擇是只需面向一種抽象出來的底層架構(gòu)，而不是面向多種硬件設(shè)備的多種 API。如果應(yīng)用層要做的針對不同的底層設(shè)備 API 進(jìn)行 DevOps 開發(fā)，人員和時間方面耗費巨大;如果出于對多種底層環(huán)境的陌生感而僅適配其中一種，就等于被鎖定在特定的硬件之上——難道以“敏捷應(yīng)用”和“DevOps 和 CI/CD”之名，將應(yīng)用重新拉回“軟硬件一體化”的時代?DevOps 和 CI/CD 需要跨多云環(huán)境的智能自動化和一致的網(wǎng)絡(luò)服務(wù)，以消除由數(shù)據(jù)中心的負(fù)載均衡設(shè)備、云中的虛擬 ADC 或容器網(wǎng)絡(luò)的開源解決方案造成的孤島。

VMware 站在應(yīng)用開發(fā)人員的角度，在應(yīng)用與底層基礎(chǔ)設(shè)施之間定義了“現(xiàn)代應(yīng)用連接”這個虛擬化層，為 DevOps 和 CI/CD 屏蔽了底層設(shè)備的差異，打通了應(yīng)用自動化開發(fā)、部署和維護(hù)之路。NSX 是“現(xiàn)代應(yīng)用連接”解決方案中的重要支柱，自帶了很多自動化元素，可以自頂向下進(jìn)行基于 API 的意圖自定義，而無需定義執(zhí)行細(xì)節(jié);NSX 高級負(fù)載均衡負(fù)責(zé)應(yīng)用交付的自動化。VMware 的方案，將抹平應(yīng)用層與基礎(chǔ)架構(gòu)層之間差異，使現(xiàn)代化應(yīng)用的 DevOps 和 CI/CD 方法可以貫徹到“底”。

對于任何以“設(shè)備”為中心的基礎(chǔ)架構(gòu)，都面臨這樣的困境。隨著虛擬化技術(shù)的普及，“設(shè)備”可能物理盒子，也可能被改造成虛擬機(jī)形態(tài)，但只要它們的工作原理沒有變化，就不支持彈性擴(kuò)縮、自恢復(fù)、自主決策這些真正的“自動化”特點。這個架構(gòu)無法在 DevOps 環(huán)境中，真正支撐業(yè)務(wù)所需的自動化和自助服務(wù)。本文討論的重點是負(fù)載均衡和應(yīng)用交付，因為路由和交換等基礎(chǔ)設(shè)施可以在應(yīng)用發(fā)生更新變化時保持相對的穩(wěn)定性，硬件設(shè)施和軟件策略配置無需隨應(yīng)用頻繁變更。而應(yīng)用交付是直接為應(yīng)用服務(wù)的，是連接客戶與應(yīng)用的必經(jīng)之路，決定著新上線的應(yīng)用是否能夠被客戶穩(wěn)定且安全地使用。

傳統(tǒng)應(yīng)用交付方法的困境

應(yīng)用交付的起源和核心是“負(fù)載均衡”。基于“設(shè)備”概念的構(gòu)建的負(fù)載均衡器欠缺自動故障恢復(fù)功能，也缺乏跨多個云擴(kuò)展的能力和自動化，欠缺根據(jù)流量模式自動擴(kuò)張(或者縮減)負(fù)載均衡的能力，并且需要對每個“設(shè)備”實例進(jìn)行大量的手動配置和單獨管理。參見圖 1。

圖 1：創(chuàng)建虛擬服務(wù)的傳統(tǒng)方法

圖 1 中的架構(gòu)和方法不是為 DevOps 和 CI/CD 的流水線設(shè)計的，因為這樣的環(huán)境非常復(fù)雜、僵化和脆弱，它的使用方法嚴(yán)重地依賴“設(shè)備”——以設(shè)備為中心，而不是以業(yè)務(wù)和應(yīng)用為中心。

VMware NSX 高級負(fù)載均衡(本文中簡化縮寫為 NSX-ALB)使用軟件定義的架構(gòu)，將中央控制平面(控制器)與分布式數(shù)據(jù)平面(服務(wù)引擎)分開。控制器是整個系統(tǒng)的“大腦”，充當(dāng)分布式數(shù)據(jù)平面的智能、管理和控制單點，使其完全自動化并與 CI/CD 管道無縫連接以進(jìn)行應(yīng)用交付。控制器提供基于閉環(huán)遙測的全面可觀察性，并提供易用的深度分析，以根據(jù)應(yīng)用監(jiān)控、端到端計時、可搜索的流量日志、安全分析、日志分析、客戶端分析等信息做出自動化決策、部署和執(zhí)行。

API ≠決策自動化

以應(yīng)用為中心的架構(gòu)需要自動化并向業(yè)務(wù)線提供自助服務(wù)。自動化和自助服務(wù)代表了現(xiàn)代智能網(wǎng)絡(luò)的發(fā)展。很多時候，在為負(fù)載均衡、WAF、GSLB 和容器 Ingress 網(wǎng)絡(luò)等應(yīng)用服務(wù)提供 “API” 和“交付自動化”之間存在巨大鴻溝。問題是在于：人工編寫腳本調(diào)用 API，不是自動化;而讓系統(tǒng)閉環(huán)智能執(zhí)行日常運維的“決策”，才是自動化。NSX-ALB 采用的聲明式“決策自動化”可簡化操作、提高敏捷性并提高安全性。

決策自動化允許管理員設(shè)定網(wǎng)絡(luò)運行的預(yù)期結(jié)果，然后自動部署、配置、按需提供服務(wù)，并管理應(yīng)用服務(wù)的整個生命周期，包括自動故障恢復(fù)。在閉環(huán)機(jī)器學(xué)習(xí)的幫助下，聲明式模型中指定的計劃和策略會自動實施、交付和強(qiáng)制執(zhí)行。這避免了繁重的腳本手動編寫腳本以應(yīng)對特定場景的要求。決策自動化還允許 IT 架構(gòu)師甚至應(yīng)用所有者指定他們的意圖，而無需依賴 IT 工程師手動輸入或編寫專用腳本。見圖 2。

圖 2：任務(wù)腳本與決策自動化

我們可以打一個比方：圖 2 中左側(cè)依靠 API 調(diào)用任務(wù)腳本的方式，就好像是操作提線木偶，一舉一動都離不開人工干預(yù);而真正的人工智能和機(jī)器人，則如圖 2 右側(cè)所示，具備自主決策和自我管理的行動能力。雖然現(xiàn)有的“機(jī)器人”都不完美，但已經(jīng)從本質(zhì)上與“提線木偶”區(qū)別開來。

NSX-ALB 的決策自動化采用軟件定義的、與底層無關(guān)的、基于云原生的架構(gòu)。該架構(gòu)將重點從基礎(chǔ)設(shè)施轉(zhuǎn)移到應(yīng)用，將專有硬件轉(zhuǎn)移到軟件，從手動配置轉(zhuǎn)移到集中策略。它允許調(diào)用程序接口 API ，但更重要的是可以實現(xiàn)更好的自動化、系統(tǒng)交付的結(jié)果并降低運維成本。參見圖 3。

圖 3：Avi 高層架構(gòu)

自動化應(yīng)用交付

使用 NSX-ALB 創(chuàng)建 VIP 的決策自動化

讓我們舉一個網(wǎng)絡(luò)管理員日常工作可能面臨的例子：比如，新業(yè)務(wù)上線，需要在負(fù)載均衡系統(tǒng)中為這個新業(yè)務(wù)的服務(wù)器創(chuàng)建一個新的虛擬服務(wù)。虛擬服務(wù)，就是負(fù)載均衡器后面的業(yè)務(wù)系統(tǒng)的所使用的虛擬 IP 和端口。

對于基于硬件的應(yīng)用交付系統(tǒng)，首先按下面圖中的列表進(jìn)行自查：已有的負(fù)載平衡器是什么?是否配置在正確的網(wǎng)絡(luò)環(huán)境中?它現(xiàn)有的性能水平是否足以正常運行?它有能力滿足業(yè)務(wù)未來增長的需求嗎?除了這些，還有其他依賴條件嗎?

然后，一旦有了這些問題的答案，需要做出設(shè)計決定：是否需要調(diào)整網(wǎng)絡(luò)環(huán)境，是否繼續(xù)沿用現(xiàn)有的硬件，是否需要購買新硬件?如何配置負(fù)載均衡器?為這個應(yīng)用預(yù)留哪一個 IP 地址作為虛擬 IP ?如何配置上下游相關(guān)的防火墻和路由?如何配置統(tǒng)一身份驗證?設(shè)置哪些系統(tǒng)告警?這些需求調(diào)研、設(shè)計、測試、實施的過程需要幾天到幾周的時間，如果需要購買并添加新設(shè)備，則需要幾個月。參見圖 4。

圖 4：創(chuàng)建新虛擬服務(wù)的傳統(tǒng)部署流程

以上步驟顯然不是對現(xiàn)代化應(yīng)用架構(gòu)和 DevOps 流程友好的方式。讓我們看看如何使用 NSX-ALB 做到應(yīng)用發(fā)布的自動化、流程化、敏捷化。

管理員只需在控制器上聲明本次發(fā)布的應(yīng)用所對應(yīng)的虛擬服務(wù)屬性(位置、協(xié)議、端口號、代理模式等)，然后控制器將進(jìn)行完整的自動化策略配置：控制器在所有適配的基礎(chǔ)架構(gòu)環(huán)境中自動找到最佳位置(數(shù)據(jù)中心或公有云)、最佳主機(jī)來自動部署新的服務(wù)引擎、自動從地址池分配 IP 地址、配置網(wǎng)卡、下發(fā)虛擬服務(wù)策略、WAF 策略、安全策略、配置身份驗證和授權(quán)、將虛擬應(yīng)用的 FQDN 注冊到 DNS、自動配置和獲取 SSL 證書……參見圖 5。

圖 5：NSX-ALB 自動化部署創(chuàng)建新的虛擬服務(wù)

自動增加容量和重新平衡

NSX-ALB 的服務(wù)引擎(SE)是工作在數(shù)據(jù)平面的負(fù)載均衡器和 Web 應(yīng)用防火墻 (WAF) ，可提供流量管理和應(yīng)用安全性，同時從流量中收集實時分析。在執(zhí)行應(yīng)用交付任務(wù)時，服務(wù)引擎 SE 可能會遇到資源耗盡的情況。這可能是由于部署了新應(yīng)用或已有應(yīng)用的訪問量提高，導(dǎo)致 CPU 利用率或內(nèi)存利用率或流量出現(xiàn)大幅增長。

從 SE 實時監(jiān)控多個應(yīng)用和網(wǎng)絡(luò)遙測數(shù)據(jù)，控制器實現(xiàn)了在應(yīng)用的整個生命周期中基于決策的 SE 自動化管理和運維。從 SE 的初始部署開始，到根據(jù)需求動態(tài)增加 SE 數(shù)量或跨本地、多云和多區(qū)域部署的自動故障恢復(fù)。見圖 6。

圖 6：彈性 SE 擴(kuò)展——數(shù)量和位置

多生態(tài)集成

借助 NSX-ALB ，企業(yè)可以毫不費力地跨多個云移動工作負(fù)載。通過在流量高峰期間自動將應(yīng)用擴(kuò)展到云上，使企業(yè)能夠使用公有云作為其數(shù)據(jù)中心的自然擴(kuò)展。NSX-ALB 控制器可以在公有云中自動創(chuàng)建應(yīng)用資源，以吸收突增的流量。控制器可以與 vCenter 和公有云的 API 進(jìn)行對話。因此，如果您希望在 任何環(huán)境中部署負(fù)載均衡器或服務(wù)引擎，管理員只需要聲明虛擬服務(wù)屬性“我想將此應(yīng)用部署到xx環(huán)境中”，隨后，控制器可以將負(fù)載均衡自動實例化為服務(wù)引擎 SE，并將虛擬服務(wù)自動配置到 SE 上。

NSX-ALB 本身并不是技術(shù)孤島，它需要與周圍的環(huán)境、周圍的生態(tài)系統(tǒng)相結(jié)合。它可以通過與 Infoblox 或其他 IP 地址管理工具來協(xié)作自動配置 IP, 也可以通過與 Amazon 的 Route53 之類的功能協(xié)作來自動將虛擬服務(wù)注冊到 DNS 中。它是如何工作的，應(yīng)用所有者和開發(fā)者真的不需要知道，他們也不關(guān)心。所以從應(yīng)用所有者的角度來看，就非常簡單，只需要啟動一個應(yīng)用的部署意圖， NSX-ALB 的控制器就會自動實例化它。參見圖 7。

圖 7：生態(tài)系統(tǒng)整合

與自動化工具集成

NSX-ALB 可以通過 Terraform、Ansible、VRO、VRA ，或 Python 腳本輕松構(gòu)建自定義策略，并通過控制器內(nèi)置的決策自動化智能來完成端到端的自動化。參見圖 8。

圖 8 NSX-ALB 與應(yīng)用自動化工具的集成

總結(jié)

VMware 的 NSX 高級負(fù)載均衡通過集成的策略管理器、決策智能中心、應(yīng)用監(jiān)控和分析、安全性、預(yù)測性自動擴(kuò)展和多云部署，提供了自動化的應(yīng)用交付系統(tǒng)，同時實現(xiàn)了現(xiàn)代化應(yīng)用架構(gòu)中的運維流水線。無論應(yīng)用是部署在私有數(shù)據(jù)中心或多個公有云的混合環(huán)境中，都可以提供統(tǒng)一的架構(gòu)和一致的用戶體驗，以及基于集中控制的決策自動化、執(zhí)行自動化和運維自動化。