在API超越應(yīng)用的時代，企業(yè)應(yīng)如何持續(xù)推進(jìn)數(shù)字化擴(kuò)展（上）

01

引言-F5應(yīng)用策略現(xiàn)狀

世界依賴應(yīng)用，今天我們每個人的衣、食、住、行都需要應(yīng)用程序。F5的使命是確保運(yùn)行在任何地點、任何環(huán)境的應(yīng)用都可用并且安全。過去10年，F(xiàn)5一直通過和全球領(lǐng)域?qū)＜易劶皢柧碚{(diào)查形成每年的《應(yīng)用策略現(xiàn)狀報告》，供各大組織的CIO、首席架構(gòu)師參考。前段時間我們發(fā)布了2024年《應(yīng)用策略現(xiàn)狀報告》，2024年我們最大的發(fā)現(xiàn)是API時代的來臨，95%的企業(yè)和組織已經(jīng)部署了API網(wǎng)關(guān)平臺，41%的組織反饋他們所管理的API的數(shù)量超過所管理的應(yīng)用的數(shù)量。

結(jié)合過去4年應(yīng)用策略現(xiàn)狀的調(diào)研，API的爆發(fā)與組織數(shù)字化轉(zhuǎn)型的力度成正相關(guān)。我們將組織數(shù)字化轉(zhuǎn)型分為三個階段，這三個階段分別是任務(wù)自動化、數(shù)字化擴(kuò)展和人工智能輔助業(yè)務(wù)。任務(wù)自動化就是過去幾年我們常能看到的應(yīng)用快速上線，搶占市場先機(jī)；數(shù)字化擴(kuò)展是組織的持續(xù)數(shù)字化轉(zhuǎn)型階段；人工智能輔助業(yè)務(wù)是數(shù)字化轉(zhuǎn)型的數(shù)智化階段。這三個階段的應(yīng)用特點和組織的重點工作如下表：

-任務(wù)自動化是將單個任務(wù)數(shù)字化，追求更快速地開發(fā)、上線、迭代應(yīng)用程序，借助DevOps平臺，云平臺實現(xiàn)代碼的編譯、構(gòu)建、上線，負(fù)載均衡部署、訪問策略的部署都通過流水線自動化的方式在數(shù)分鐘內(nèi)完成。

-數(shù)字化擴(kuò)展階段組織的具體工作是應(yīng)用現(xiàn)代化及實現(xiàn)特定業(yè)務(wù)的應(yīng)用組合的現(xiàn)代化，對應(yīng)用現(xiàn)代化的一個衡量指標(biāo)是應(yīng)用能夠隨需而變，應(yīng)用可以根據(jù)業(yè)務(wù)需求快速變化。這一階段應(yīng)用通常部署在多云多區(qū)，組織投入構(gòu)建應(yīng)用和工作負(fù)載在多云多區(qū)及數(shù)據(jù)中心之間遷移的能力，應(yīng)用可以按需彈性構(gòu)建。

-人工智能輔助業(yè)務(wù)是借助生成式AI提升應(yīng)用的智能化水平，例如一些知識管理類應(yīng)用、情感分析類應(yīng)用、對話式應(yīng)用、代碼生成類應(yīng)用應(yīng)用被廣泛的討論。當(dāng)然一些組織也在布局AI引擎、大模型、訓(xùn)練服務(wù)器，但大多數(shù)組織都在關(guān)注AI應(yīng)用安全以及AI模型在云和數(shù)據(jù)中心之間的遷移。

根據(jù)2024年F5《應(yīng)用策略現(xiàn)狀報告》，API超越應(yīng)用，API時代來臨的更主要原因是組織將完成現(xiàn)代化的應(yīng)用程序和工作負(fù)載遷移到云、企業(yè)和組織著手打造應(yīng)用程序/工作負(fù)載跨多云、多云可用區(qū)和數(shù)據(jù)中心的可移植性能力、以及邊緣安全計算及SaaS化服務(wù)的使用。2024年調(diào)查問卷發(fā)現(xiàn)61%的組織通過將應(yīng)用程序/工作負(fù)載遷移到云以實現(xiàn)現(xiàn)代化，提升數(shù)字化體驗，并希望利用這種運(yùn)營模式帶來的效率提升。59%的組織非常關(guān)注跨多云多區(qū)和本地數(shù)據(jù)中心的工作負(fù)載的可移植性，并積極構(gòu)建這種能力，確保應(yīng)用程序/工作負(fù)載能夠隨時來回在數(shù)據(jù)中心和多云多可用區(qū)之間遷移，95%的組織構(gòu)建了API網(wǎng)關(guān)，依賴跨云和數(shù)據(jù)中心的灰度發(fā)布就是構(gòu)建這種能力的具體體現(xiàn)。另外有57%的組織利用邊緣安全計算服務(wù)以及SaaS化的服務(wù)。

人工智能輔助業(yè)務(wù)，即數(shù)字化轉(zhuǎn)型的數(shù)智化階段，將進(jìn)一步加速API的爆發(fā)。根據(jù)我們的領(lǐng)域?qū)＜覍φ?，?shù)字化轉(zhuǎn)型的第二階段—數(shù)字化擴(kuò)展所建立的應(yīng)用服務(wù)和安全服務(wù)能力可以滿足AI應(yīng)用所需的90%能力，而10%的不滿足需求主要集中在AI應(yīng)用的安全性上。因此，本文將聚焦于數(shù)字化擴(kuò)展階段，首先探討企業(yè)和組織在應(yīng)用及實現(xiàn)有特定業(yè)務(wù)的應(yīng)用組合的現(xiàn)代化、應(yīng)用遷移上云，以及構(gòu)建應(yīng)用和工作負(fù)載在多云、多區(qū)及數(shù)據(jù)中心網(wǎng)絡(luò)區(qū)域的一致性能力過程中常見的問題。隨后會說明解決這些常見問題的方案，結(jié)合一些實際案例，論證如何借助F5新一代硬件平臺、NGINX和F5分布式云提升數(shù)字化擴(kuò)展階段應(yīng)用服務(wù)和安全服務(wù)的可靠性水平。最后，我們將再次回到2024年F5《應(yīng)用策略現(xiàn)狀報告》，結(jié)合對領(lǐng)域?qū)＜业恼{(diào)研反饋，總結(jié)我們的解決方案可以為企業(yè)或組織帶來的收益。

02

數(shù)字化擴(kuò)展階段應(yīng)用服務(wù)常見問題

當(dāng)企業(yè)或組織進(jìn)行數(shù)字化轉(zhuǎn)型的第二階段，也就是數(shù)字化擴(kuò)展階段時，組織的主要任務(wù)是應(yīng)用程序的現(xiàn)代化、應(yīng)用程序組合的現(xiàn)代化，以及將現(xiàn)代后的應(yīng)用遷移到云，并確保在遷移過程中應(yīng)用和流量負(fù)載在跨云和數(shù)據(jù)中心之間具備可移植性。現(xiàn)代應(yīng)用指的是容器原生（Container Native）和云原生（Cloud Native）的應(yīng)用程序，它們涵蓋多個維度，包括Docker、Kubernetes、DevOps、微服務(wù)架構(gòu)和云。這些技術(shù)已被幾乎所有的企業(yè)和組織使用，目的是使數(shù)字化擴(kuò)展階段支持組織數(shù)字化業(yè)務(wù)的服務(wù)變得更加簡單。但在實際生產(chǎn)中，情況常常并非如此。我們常發(fā)現(xiàn)，單一任務(wù)需要許多不同的團(tuán)隊提供服務(wù)和技能支持，從而使一個應(yīng)用的交付和上線變得更加復(fù)雜，這通常是因為沒有有效解決數(shù)字化擴(kuò)展階段應(yīng)用服務(wù)的幾個關(guān)鍵問題。

對流量管理的方式發(fā)生了根本變化理解不足

在數(shù)字化擴(kuò)展階段，組織的首要任務(wù)是應(yīng)用現(xiàn)代化，即用現(xiàn)代應(yīng)用替換傳統(tǒng)應(yīng)用。要準(zhǔn)確規(guī)劃和建設(shè)云環(huán)境下的應(yīng)用服務(wù)，避免陷入被動和混亂，首先必須深刻理解流量管理方式的根本變化。如圖所示，傳統(tǒng)應(yīng)用部署在傳統(tǒng)數(shù)據(jù)中心，而現(xiàn)代應(yīng)用部署在多云架構(gòu)之上。傳統(tǒng)應(yīng)用通常采用單體架構(gòu)，而現(xiàn)代應(yīng)用架構(gòu)基于微服務(wù)架構(gòu)。一個系統(tǒng)被分為多個模塊，不同模塊屬于不同的租戶，單個模塊由多個微服務(wù)組成?，F(xiàn)代應(yīng)用中，90%的流量是API對API、服務(wù)對服務(wù)，一個系統(tǒng)由成千上百個微服務(wù)和API組成。

流量管理方式的根本變化在于，傳統(tǒng)架構(gòu)下一個應(yīng)用系統(tǒng)只需要基于一組IP和端口進(jìn)行負(fù)載均衡。而在現(xiàn)代應(yīng)用架構(gòu)下，一個應(yīng)用系統(tǒng)需要基于域名和請求路徑URL在成千上百個微服務(wù)之間進(jìn)行智能流量路由管理?；谔囟l件進(jìn)行轉(zhuǎn)發(fā)、藍(lán)綠發(fā)布、灰度發(fā)布、影子測試等方式，是現(xiàn)代應(yīng)用智能流量路由的必要手段。例如，隨著組織中應(yīng)用上云和信創(chuàng)等進(jìn)程的推進(jìn)，一個應(yīng)用系統(tǒng)通常存在多個版本，需要將客戶的請求在這些版本之間路由。在智能流量路由中，根據(jù)源地址將特定省份的請求路由到云上信創(chuàng)版本是一個典型的場景。

缺乏統(tǒng)一的規(guī)劃與治理

過去10年，企業(yè)和組織的IT架構(gòu)轉(zhuǎn)型以私有云、全棧云和混合云建設(shè)為中心，旨在實現(xiàn)基礎(chǔ)架構(gòu)和應(yīng)用的現(xiàn)代化，進(jìn)而推進(jìn)企業(yè)業(yè)務(wù)的數(shù)字化轉(zhuǎn)型。特別是近年來，一些大型組織在大力推進(jìn)全棧云建設(shè)，除了實現(xiàn)應(yīng)用現(xiàn)代化外，還致力于打造自主可控的國產(chǎn)化關(guān)鍵云基礎(chǔ)架構(gòu)。然而，這一進(jìn)程中存在一個普遍現(xiàn)象，即云建設(shè)呈現(xiàn)“多朵云，各自為陣”的現(xiàn)象。不同項目組各自獨立，自建IaaS云、PaaS云、容器云和全棧云。例如，我們調(diào)研的某國內(nèi)大型金融機(jī)構(gòu)就存在數(shù)十朵云的建設(shè)。下圖所示為基礎(chǔ)架構(gòu)現(xiàn)狀，呈現(xiàn)出多云、多區(qū)和傳統(tǒng)數(shù)據(jù)中心區(qū)域共存的狀態(tài)。

由于這些云的建設(shè)由不同項目組發(fā)起，并在不同時間點進(jìn)行，除了造成資源重復(fù)建設(shè)和浪費(fèi)，更主要的是缺乏架構(gòu)部門的統(tǒng)一規(guī)劃和治理。多云建設(shè)及應(yīng)用上云未依據(jù)統(tǒng)一標(biāo)準(zhǔn)，導(dǎo)致自動化自服務(wù)無法有效實施，甚至存在可靠性和安全性風(fēng)險。

應(yīng)用多云多區(qū)多活新場景

為了保證應(yīng)用的絕對可靠性與彈性，一些大型組織過去通過兩地三中心的多數(shù)據(jù)中心多活方式部署應(yīng)用系統(tǒng)，以確保應(yīng)用的高可用性與高可靠性。然而，在數(shù)字化擴(kuò)展階段，隨著企業(yè)持續(xù)推進(jìn)數(shù)字化轉(zhuǎn)型并大力上云，業(yè)務(wù)的高可靠性現(xiàn)在還依賴于多云、多區(qū)、多活的新場景。如圖所示，同一個業(yè)務(wù)系統(tǒng)應(yīng)用部署在云上三個可用區(qū)，包括信創(chuàng)區(qū)域和非信創(chuàng)區(qū)域，這三個可用區(qū)可能位于不同的數(shù)據(jù)中心。多云多區(qū)多活指的是流量在這三個區(qū)域之間進(jìn)行智能調(diào)度。與多中心多活相比，多云多區(qū)的應(yīng)用多活更注重切換的迅速性。基于可編程能力的多中心多可用區(qū)多活，結(jié)合SDN可編程能力以及網(wǎng)絡(luò)二三層Anycast技術(shù)的多平面技術(shù)，是云環(huán)境技術(shù)的主要方向。為了保證在數(shù)字化擴(kuò)展階段應(yīng)用和工作負(fù)載在多云和數(shù)據(jù)中心中的可移植性，云建設(shè)規(guī)劃中的云前置區(qū)域主要應(yīng)對這一場景。云前置除了SDN和Anycast雙平面外，還需要與云應(yīng)用交付和現(xiàn)代應(yīng)用負(fù)載調(diào)度精密結(jié)合，根據(jù)Host或URL跨可用區(qū)的分發(fā)，實現(xiàn)應(yīng)用在四七層的多可用區(qū)調(diào)度，并根據(jù)業(yè)務(wù)請求流量百分比，實現(xiàn)平穩(wěn)過渡的方式進(jìn)行信創(chuàng)區(qū)和非信創(chuàng)區(qū)的調(diào)度。

新技術(shù)新方法論與已有流程和團(tuán)隊結(jié)合難問題

在數(shù)字化轉(zhuǎn)型的第二階段，各組織持續(xù)投入應(yīng)用現(xiàn)代化，應(yīng)用上云，構(gòu)建多云和傳統(tǒng)數(shù)據(jù)中心之間流量負(fù)載可移植可調(diào)度的過程中，一些新的技術(shù)和新的方法論大量的在落地實施：

-內(nèi)容緩存：經(jīng)過統(tǒng)計，云上負(fù)載均衡約40%的流量進(jìn)入了對象存儲（內(nèi)容緩存），對象存儲保存靜態(tài)資源、DevOps流水線中臨時文件、系統(tǒng)備份文件等。

-容器入口：容器是云上應(yīng)用的主要載體，容器應(yīng)用被K8S中調(diào)度管理，K8S是云上應(yīng)用運(yùn)行的最小單元，容器入口就是K8S流量入口。

-應(yīng)用防護(hù)：基于單個應(yīng)用的應(yīng)用或單組API防護(hù)是多云多區(qū)架構(gòu)下應(yīng)用安全防護(hù)的最大特點，與傳統(tǒng)DMZ區(qū)統(tǒng)一WAF防護(hù)方式形成鮮明對比。

-DevOps：DevOps思想已廣泛的被采納，DevOps關(guān)鍵在于打通開發(fā)和運(yùn)維的壁壘以實現(xiàn)應(yīng)用交付上線與生產(chǎn)運(yùn)維保證的效率。

這些新場景新方法論的落實實施在一些組織中的管理者來看沒有帶來生產(chǎn)力的有效提高，這是因為沒有有效解決新技術(shù)新方法論與已有流程和團(tuán)隊結(jié)合難問題，根據(jù)我們的調(diào)研，大多數(shù)組織都基于新技術(shù)新方法論進(jìn)行平臺化建設(shè)，將傳統(tǒng)數(shù)據(jù)中心網(wǎng)絡(luò)、安全等能力嵌入在平臺中，提升傳統(tǒng)部門的技能水平，實現(xiàn)云網(wǎng)一體化，多云統(tǒng)一安全管理治理。