1、編委會版權聲明編寫單位:北京通明湖信息城發展有限公司中國信息通信研究院神州數碼集團股份有限公司通明智云(北京)科技有限公司編寫組成員:北京通明湖信息城發展有限公司:曹軍威、明陽陽、袁仲達中 國 信 息 通 信 研 究 院:陳屹力、杜嵐、蔣嘯天通 明 湖 云 和 信 創 研 究 院:李 剛、張紅忠、梅 江通明智云(北京)科技有限公司:吳若松、單雷、潘黎強、廖猛蛟、陳毅東本報告版權屬于北京通明湖信息城發展有限公司、中國信息通信研究院、神州數碼集團股份有限公司、通明智云(北京)科技有限公司,并受法律保護。轉載、摘編或利用其他方式使用本報告文字或者觀點的,應注明來源。違反上述聲明者,編者將追究相關法律
2、責任。目錄 一、云原生技術發展概要.1(一)云原生技術發展綜述.2(二)應用引擎技術介紹.3(三)云原生應用引擎概述.6二、云原生應用引擎-數云時代的關鍵技術組件.11(一)云原生技術圖譜下的應用引擎.12(二)主流的云原生應用引擎介紹.14(三)云原生應用引擎的衍生產品形態.22(四)云原生產業圖譜下的應用引擎.28(五)云原生應用引擎面臨的挑戰.39三、云原生應用引擎行業應用場景和價值.30(一)金融行業.31(二)電信行業.37四、云原生應用引擎展望.45(一)無服務器架構云原生應用引擎技術新路線.46(二)應用引擎中國云原生技術創新突破口.47(三)中國云原生應用引擎生態建設展望.48
3、附錄:國內云原生應用引擎產品介紹.49(一)通明智云-NJet 應用引擎.50(二)百度-BFE.53(三)阿里-Higress.55(四)阿里 MOSN.571云原生應用引擎技術發展白皮書2第一章 云原生技術發展概要(一)云原生技術發展綜述經過十幾年的發展,云計算作為數字化轉型的重要基礎設施,已經由“面向云遷移應用”的階段演進到“面向云構建應用”的階段,即由“以資源為中心”演進到“以應用為中心”的云原生基礎設施階段。云原生基礎設施利用智能的調度和運維系統來高效管理更為豐富的應用,為用戶帶來了多方面的革新。在云原生的基礎設施中,支撐應用的所有能力都已經 API 化、標準化,如存儲、網絡、路由、
4、部署,這種架構使得應用能夠解除對特定的云服務商的依賴,快速分發到不同的公有云,或公有和私有云混合的復雜云環境。尤其是硬件資源的API 化,使得硬件可以接受上層的調度編排,為應用及時提供相關的資源需求。這種軟硬協同的基礎設施架構在為應用提供更好性能的同時,也對隔離性、安全性等多方面能力進行了加強。云原生架構具有如下典型技術特征:采用輕量級的容器。云原生應用程序是打包為輕量級容器的獨立自治服務的集合。與虛擬機相比,容器簡化了容器管理集群的搭建工作,同時整合了調度、配置、存儲、網絡等。用戶可以將微服務及其所需的所有配置、依賴關系和環境變量打包成容器鏡像,輕松移植到全新的服務器節點上,而無需重新配置環
5、境。設計松耦合的微服務。微服務將大型復雜軟件應用拆分成多個簡單應用,每個簡單應用描述著一個小業務并可以被獨立部署。各微服務之間是松耦合的,可以獨立地對每個服務進行升級、部署、擴展和重新啟動等。相比傳統的單體架構,微服務具有降低系統復雜度、獨立部署、獨立擴展、跨語言編程等特點。通過API進行交互協作。云原生服務使用輕量級API進行交互,比如基于 RESTFul、gRPC或NATS等協議。使用最佳語言和框架開發。云原生應用的每項服務可以使用最適合該功能的語言和框架開發。微服務的細粒度拆分模式使得各個服務可以分別根據需要選擇最適合的語言和框架。通過 DevOps 流程進行管理。DevOps 是一組過
6、程、方法和系統的統稱,旨在統一軟件開發和軟件操作,與業務目標緊密結合,構建出一種通過持續交付實踐去優化資源和擴展應用程序的新方式,縮短了開發周期、增加了部署頻率,并實現了更可靠的發布。以容器、微服務、DevOps 等為核心的云原生技術和理念推動著云原生產業生態蓬勃發展。隨著企業深入上云用云,業務應用走向全面云化,企業對云原生的需求升級,需要一個底層的云原生應用引擎來支撐業務應用的快速云化改造。比如,應用引擎的邊車(Sidecar)形態可以在傳統應用不做任何改造的情況下,實現上云遷移;再如,應用引擎作為應用服務器,為業務提供了標準的微服務框架。此外,傳統的技術領域,如數據庫、數據倉庫等轉變為云服
7、務的方式也需要云原生應用引擎來進行支撐??傊?,云原生應用引擎和其他云原生技術的相互融合,可以為企業提供堅實的云化技術底座,從而實現企業應用的云原生技術升級。云原生應用引擎技術發展白皮書3第一章 云原生技術發展概要1.應用引擎的定義 應用引擎是面向互聯網和云原生應用提供的運行時組態服務程序。具備環境感知、安全控制、加速優化等能力,一般呈現為 Web 服務、流媒體服務、代理(Proxy)、應用中間件、API 網關、消息隊列等產品形態?;ヂ摼W時代國際主流的應用引擎包括:NGINX,Apache,IIS 等。在云原生時代有許多新的輕量級應用引擎涌現,比較流行的云原生應用引擎包括:NGINX(C 語言)
8、,Envoy(C+語言),Linkerd(Rust 語言)等。在云原生架構中,應用引擎除了提供南北向通信網關的功能以外,還提供了服務網格中東西向通信、透明流量劫持、熔斷、遙測與故障注入、鏈路追蹤、藍綠發布等新功能特性,因此應用引擎在云原生架構中發揮著更為關鍵的作用。圖 1 云原生應用引擎架構(二)應用引擎技術介紹 云原生應用引擎技術發展白皮書4第一章 云原生技術發展概要如上圖所示,應用引擎產品形態包括 Web 服務器、流媒體服務器、應用服務器和代理服務器等。其中,代理服務器又可分為正向代理、反向代理、邊車和消息代理等產品。(1)Web 服務器Web 服務器是 World Wide Web 服務
9、器的簡稱,又稱為網頁服務器,主要功能是提供互聯網信息服務,能夠為各種客戶端提供如 WWW、Email、FTP 等互聯網服務。常見的 Web 服務器有 Apache、NGINX、IIS 等。Web 服務器具有接口通用性好和可擴展性強的特點。以 NGINX 為例,它是一款輕量級 Web 服務器,采用異步高并發多進程模型,性能優異、占用內存和資源少,既可以用于靜態文件解析,也可以通過擴展服務提供動態內容。在云計算領域,Web 服務器是應用引擎中最為廣泛的產品形態。圖 2 應用引擎產品形態2.應用引擎的產品形態 云原生應用引擎技術發展白皮書5第一章 云原生技術發展概要(2)流媒體服務器流媒體服務器是專
10、注于提供音視頻資源在線播放的應用服務器,大多是通過標準的 Web 服務器附加特定的音視頻處理功能實現,從而滿足人們對音視頻傳輸質量和響應時延的要求。以 NGINX 為例,其中的 Flv Stream 模塊能實現流媒體的功能,而且支持 flv 視頻進度條拖拽,另外NGINX 還可以作為反向代理服務器提供基于 Flash Media Server 或者 Red5 的 RTMP/RTMP 流媒體服務?;谄鋵崟r性和多媒體展示能力,流媒體服務器已經成為云原生應用引擎服務的一種重要形態。(3)應用服務器應用服務器是部署特定應用的軟件平臺,如 NGINX、Weblogic、Tomcat。應用服務器一般會實
11、現可插拔的協議處理框架,具備多語言編程接口。以 NGINX 為例,它可以通過 NGINX 和 FASTCGI 的方式運行 PHP、JSP 或其他語言編寫的應用服務,并可以通過插入特定協議的實現模塊支持如 Dubbo、gRPC 類似的企業應用?;诤啙嵏咝У木幊陶Z言,應用服務器成為構建微服務的基礎和云原生應用引擎的重要形態。(4)代理服務器(Proxy)代理服務器是客戶端和服務端的中介,如 NGINX,Envoy 等。主要功能是信息的訪問控制、應用加速及信息隱藏。代理服務器分為兩類,正向代理服務器(forward proxy)和反向代理服務器(reverse proxy)。反向代理服務器代理外部
12、請求訪問內部網絡的服務,而前者代理內部請求訪問外部網絡的服務。明確支持特定協議的代理服務器被稱為7層代理,最常支持的協議類型為HTTP/S。相對應的,不解析內容,僅僅進行 TCP/UDP 端口轉發的被稱為 4 層代理。以 NGINX 為例,通過不同的模塊對 4/7 層進行了良好的高性能支持,7 層上支持 HTTP1.x,HTTP2 及HTTP3,并通過插件機制實現對特定 7 層協議的定制支持。在云原生架構中,代理服務器通過入/出口網關、邊車等角色成為重要的應用引擎產品形態。云原生應用引擎技術發展白皮書6第一章 云原生技術發展概要1.云原生技術架構下應用引擎的演進云原生應用引擎從傳統互聯網架構發
13、展到云原生架構,其支撐的軟硬件類型由操作系統、數據庫、應用中間件和 Web 服務器逐步發展為基于云原生內核、分區解耦的數據庫及相關衍生產品,例如,API 網關、入/出口網關、邊車、微隔離、消息代理、應用代理等。云原生架構的應用引擎實現雖然需要借助容器、DevOps、微服務等新興云原生技術,但我國在云原生應用引擎技術領域已經積累了深厚的研究基礎。據 Gartner1預測,到 2025 年,云原生平臺將成為超過 95%的新數字計劃的基礎,遠高于 2021 年的不到40%。以上預測說明,中國云原生產業將迎來蓬勃發展,基于云原生應用引擎在云原生技術的突出位置,應用引擎將成為信息產業發展的主力軍和排頭兵
14、。圖 3 云原生應用引擎演進12022 年十二大重要戰略技術趨勢,Gartner,2021 年 10 月(三)云原生應用引擎概述云原生應用引擎技術發展白皮書7第一章 云原生技術發展概要2.云原生應用引擎的特點作為云原生環境部署里的基礎組件,云原生應用引擎具有如下特征:(1)無狀態能力云原生應用引擎有多種形態,如應用服務器、應用代理,但無論哪種都需適應云原生環境的多變的動態部署要求,包括擴展、遷移,特別是適配云原生的容器化部署。因此,一定不能在節點存儲狀態數據,需要把狀態數據及時同步到控制管理平面。以 NGINX 為例,其集群同步能力可以在不同實例間同步配置,產生的日志可以不落盤,而直接對接管控
15、平面的日志服務組件。(2)可觀測能力傳統應用的網絡和硬件規劃是靜態的,而云原生環境下的規劃部署是動態的,并且請求的拓撲每次都可能不同。因此,云原生應用引擎需要支持 Opentracing 等可觀測架構,按要求及時上報請求的跟蹤信息。NGINX早在數年前就支持 Opentracing,可以對接 Zipkin、Jaeger server,實現統一的調用鏈觀測。(3)動態配置能力云原生環境下由于業務服務變動頻繁,需要應用網關或代理即時變更配置,同時云原生環境下的微隔離也要求控制面及時下發控制策略。因此,云原生應用引擎,尤其是代理服務器必須具備動態配置能力,才不會因為不及時的配置變更影響業務。(4)D
16、evOps 集成能力云原生的應用架構有快速迭代、多版本并存、藍綠部署以及熱更新的特點。因此,需要應用引擎提供接口支持版本熱更新、流量切換、灰度測試等能力。例如,NGINX 支持熱更新,可以根據復雜協議特有的變量進行不同的路由選擇。云原生應用引擎技術發展白皮書8第一章 云原生技術發展概要應用引擎在微服務體系中發揮著重要的作用。一是作為應用服務器,能夠適應企業現有的實現語言,提供相應的服務器實現,從而保證企業能以較低的成本完成業務的云化改造。例如,NGINX 通過兩種模式實現通用服務器支持,通過動態模塊機制、加載不同語言的模塊,目前已經有對應的 C/Go/Java 或解釋型語言如 PHP/Pyth
17、on/LUA;或者把不同的語言首先翻譯為 WASM 方言,再通過 WASM 模塊執行。二是作為流量或 API 網關,應用引擎僅僅是代理或施加策略控制,有時還可以彌補服務實現的缺陷,比如下面章節中代理MQTT 消息協議時對其缺乏 HA 能力的彌補。而在服務網格架構中,應用引擎除了上述的作用外,還以邊車的形態和控制面組件進行交互,為服務增強了可觀測性、安全、流量控制。例如,NGINX 本身的融斷機制、豐富的路由策略滿足邊車的流量調度需要,而微隔離的需求則通過豐富的第三方安全插件支持,原生的豐富的 upstream 指標體系則滿足了可觀測性需求。3.云原生架構下應用引擎的定位圖 4 應用引擎定位云原
18、生應用引擎技術發展白皮書9第一章 云原生技術發展概要如下圖所示,應用引擎的部署包含數據平面、控制平面、管理平面。數據平面實現業務的數據處理,控制平面實現對業務策略的配置,管理平面實現對引擎的管理?;诠芾砥矫?、控制平面與數據平面的協同交互,云原生應用引擎在數據平面實現了安全、高效部署,基于 API 網關和入口網關(Ingress)傳入的數據,服務節點借助邊車功能實現了一系列的微服務,并將服務結果輸出到相關用戶?;谶呠嚰夹g,應用引擎實現了數據平面與控制平面和管理平面的功能解耦,底層實現對軟硬件資源的自動化管理和控制,其技術更新對上層服務邏輯的影響較小,上層用戶不必對底層服務進行重復設計和主動干
19、涉,從而帶來效率和安全性的提高。圖 5 應用引擎部署應用引擎在云原生環境中實現了以下部署:(1)消息隊列消息隊列是構建低延遲、高并發、高可用、高可靠的分布式消息中間件。云原生環境中部署消息隊列,將消息隊列作為服務運行,允許在不進行配置服務器的情況下創建應用程序處理擴展管理,由云提供商抽象和處理,以微服務為中心,消息隊列松耦合,可以更新特定功能而不會導致應用程序停機。4.云原生架構下應用引擎的部署云原生應用引擎技術發展白皮書10第一章 云原生技術發展概要(2)入口/出口網關(Ingress/Egress)云原生架構下應用引擎的部署可以在整個系統的入口和出口處部署代理,使得所有流入和流出的流量都由
20、代理進行轉發,而這兩個負責入口和出口的代理就叫入口網關和出口網關。它們相當于整個微服務應用的邊界代理,把守著進入和流出服務網格的流量。(3)API 網關API 網關是一個云原生、高性能、可擴展的微服務網關,基于 OpenResty 結合 etcd 來實現,API 網關具備動態路由和插件熱加載的特性,適合微服務下的 API 管理。API 網關實現了客戶端和服務端調用關系和部署環境的解耦,它向客戶端隱藏了應用劃分的微服務的部署版本。API 網關可以根據負載策略進行請求流量調節,客戶端可以靈活地選擇在不同場景使用不同版本的后端服務。API 網關是所有業務流量的入口,可以處理傳統的南北向流量客戶端服務
21、器通信,也可以處理服務間的東西向流量,也可以當作 K8s 入口網關來使用。(4)邊車邊車是分布式和微服務架構的設計模式,實現了控制和邏輯的分離與解耦。通過給應用服務加裝一個邊車達到控制和邏輯分離的目的,通過給應用程序加上一個邊車的方式擴展應用程序現有的功能,如日志記錄、監控、流量控制、服務限流等。業務服務只需要專注于實現業務邏輯即可。(5)Serverless 應用引擎Serverless 應用引擎是面向應用的 Serverless PaaS 平臺,幫助 PaaS 層用戶免運維 IaaS,按需使用,按量計費,實現低門檻微服務應用上云,有效解決成本及效率問題。Serverless 應用引擎支持
22、WAR/JAR/壓縮包自動構建成 Docker 鏡像能力,讓零容器基礎的客戶沿用原有部署方式使用 Serverless 應用引擎。11云原生應用引擎技術發展白皮書12第二章 云原生應用引擎-數云時代的關鍵技術組件(一)云原生技術圖譜下的應用引擎經過多年的發展,云原生的理念不斷豐富、落地、實踐,已經進入了快速發展的時期。云原生技術以其高效穩定、快速響應的特點驅動引領了企業業務發展,幫助企業構建出更加適用于云環境的應用服務。結合對 CNCF 云原生全景規劃的理解和國內云原生應用的演進現狀,未來云原生架構包括如下四個層面:支撐平面提供整個云原生應用的基礎設施支持,包括物理性的硬件、網絡等資源,也包括
23、適應云化動態規劃配置的虛擬化技術。同時,基礎軟件、容器等不可變基礎設施也是支撐平面的關鍵性內容。在支撐平面之上是云化環境的服務網格,它是云原生技術演進的流行架構,實現更多的東西向能力控制。服務網格的實現包括了數據平面和控制平面,前者無論是 Proxy 還是應用服務器的形態,都承載了具體的業務流量,而后者負責控制數據平面。管理平面負責云原生應用整體的交付、運維和運營,尤其是結合AI的數據分析,在提高整體的資源利用率、故障診斷、自動化編排調度等方面都發揮極為重要的作用。圖 6 云原生技術圖譜如上圖所示,基于軟硬件基礎設施的支撐和管理、控制平面對相關資源的管理、優化和控制,云原生應用引擎定位于服務網
24、格內的數據平面,基于數據處理和信息通信等先進技術驅動應用引擎發展。云原生應用引擎技術發展白皮書13第二章 云原生應用引擎-數云時代的關鍵技術組件作為云原生服務網格的數據平面,應用引擎是微服務應用南北向和東西向流量管理、安全控制引擎。首先,支撐平面將為應用引擎提供配置、封裝、管理、部署的基礎支撐,支撐平面的容器編排系統將應用引擎以容器、POD 的方式自動化部署到云原生集群環境的各個節點;應用引擎將從容器編排系統獲得配置信息并按照配置信息執行流量代理、彈性、熔斷、限流、安全控制、應用路由等功能。以邊車來說,支撐平面的容器編排系統將邊車應用引擎以容器方式注射到微服務的 POD 中,從而實現透明流量劫
25、持、熔斷、故障注入、遙測等功能;而應用引擎中的入口網關、出口網關則為 K8s 集群提供外部訪問(南北向)的功能。入口網關、出口網關可以通過 K8s 以 POD 的方式部署,此外入口網關和出口網關通過 K8s 的 API-Server 獲得配置信息,并根據配置信息進行流量代理和路由。同樣,提供 K8s 集群的外部訪問接口 API 網關也是從 K8s 的 API-Server 獲得配置信息,大多數的 API 網關也是以 POD 的形式由 K8s 來部署的。API 網關根據 K8s 獲得的配置信息執行流量路由、協議轉換、安全控制等功能。其次,控制平面則通過服務發現協議對應用引擎進行更為精確細致的控制
26、,其中包括:證書動態分發、控制策略、黑白名單、加密通信、熔斷、限流、遙測等功能??刂破矫鏋樵圃鷳锰峁┝嗽瓉碇纹矫嫠鶝]有的流量治理、安全治理和可觀測性能力。應用引擎在通過容器編排系統部署后,通過服務發現協議獲得控制平面配置的 SSL 證書、黑白名單、流量劫持、熔斷限流、故障注入、遙測等動態配置信息從而實現自動化微服務應用流量控制與管理。應用引擎將流量代理過程中的遙測數據(訪問日志信息和狀態信息)格式化并傳輸給管理平面的數據采集、大數據分析引擎。管理平面通過人工智能技術實現智能運維決策,并將根據遙測數據經過人工智能分析產生的決策或者反饋信息傳輸到管理平面的開發運維一體化平臺(DevOps)上
27、,推動代碼演進、產生運維策略。而DevOps 產生的運維策略則下發到控制平面,由控制平面根據運維指令分解成為具體的應用引擎配置信息,下發到部署在數據平面的各類引用引擎,從而實現安全智能自動化運維的云原生最佳實踐。圖 7 云原生架構各個平面之間關系云原生應用引擎技術發展白皮書14第二章 云原生應用引擎-數云時代的關鍵技術組件(二)主流的云原生應用引擎介紹1.NGINX 介紹(1)NGINX 簡介NGINX 是一款自由的、開源的、高性能的 HTTP 服務器和反向代理服務器;同時也是一個 IMAP、POP3、SMTP 代理服務器;NGINX 可以作為一個 HTTP 服務器進行網站的發布處理,另外 N
28、GINX 可以作為反向代理進行負載均衡的實現。(2)NGINX 的特點更快:單次請求響應更快,高并發可以更快的處理響應。高拓展性:設計極具擴展性,由多個不同功能、不同層次、不同類型且耦合度極低的模塊組成。高可靠性:很多高流量網站都在核心服務器上大規模使用 NGINX。低內存消耗:一般 1 萬個非活躍的 HTTP Keep-Alive 連接在 NGINX 中僅消耗 2.5MB 內存。高并發:單機支持 10 萬以上的并發連接。熱部署:master 管理進程與 worker 工作進程的分離設計,使得 NGINX 能夠支持熱部署。云原生應用引擎技術發展白皮書15(2)NJet 特點:在 NGINX 的
29、 master 和 worker 主運行框架基礎上,增加了 Copilot 協助進程框架,用于提供配置管理功能,并避免此類功能對業務的干擾。提供動態配置能力框架,用于對現有模塊進行動態配置改造,從而避免 reload/restart 對業務的打擾。內置 HA 能力,可以自動構建高可用集群。內置集群、配額限制等企業特性。提供單機管理 API/GUI,便于集成,也利用輕量化部署。第二章 云原生應用引擎-數云時代的關鍵技術組件圖 8 NJet 架構圖2.NJet 介紹(1)NJet 簡介NJet 派生自 NGINX,并獨立演進的開源應用引擎,可以作為 Web server/應用代理/出入口網關等多種
30、形式部署。由于繼承于 NGINX,NJet 天生具有高性能、穩定、易擴展的特點。同時 NJet 也解決了 NGINX 長期存在的難于動態配置、管理功能影響業務等問題,其基本架構如下圖所顯示:云原生應用引擎技術發展白皮書16第二章 云原生應用引擎-數云時代的關鍵技術組件(1)Envoy 簡介Envoy 是作為微服務架構中以獨立進程方式實現高級網絡功能的,輕量級 7 層服務代理,通常以邊車的方式運行在應用程序的周邊,或者作為網絡的邊緣代理來運行,其基本架構如下圖所顯示:3.Envoy 介紹(2)Envoy 特點進程外體系結構:Envoy 是一款自包含的高性能服務器,具有很小的內存占用空間,它與任何
31、應用程序語言或框架一起運行。HTTP/2支持:Envoy對出入流量都有HTTP/2 和 gRPC 支持,是一個透明的 HTTP/1.1 到 HTTP/2 代理。高級負載均衡:Envoy 支持高級負載均衡功能,包括自動重試、斷路、全局速率限制、請求鏡像和區域本地負載均衡等。服務發現和動態配置:Envoy 提供 API 來動態管理其配置??捎^測性:深入觀測 L7 流量,原生支持分布式跟蹤。圖 9 Envoy 架構圖云原生應用引擎技術發展白皮書17第二章 云原生應用引擎-數云時代的關鍵技術組件(1)API7 簡介API7 是云原生、高性能、可擴展的微服務 API 網關,提供負載均衡、動態上游、灰度發
32、布、服務熔斷、身份認證、可觀測性等豐富的流量管理功能。API7 基于 NGINX 的 OpenResty 分支實現,主要利用 OpenResty提供的 LUA 擴展能力,實現 API 網關需要的多種業務特性。圖 10 API7 架構圖24.API7 介紹2 參考來源:https:/ 云原生應用引擎-數云時代的關鍵技術組件(2)API7 特點 高可用:API7 默認選用 etcd 作為配置中心得 API7 可以支持毫秒級配置更新、支撐數千網關節點;網關節點無狀態,可任意擴容或縮容。協議轉換:支持豐富的協議類型,如 TCP/UDP、Apache Dubbo、MQTT、gRPC、SOAP、WebSo
33、cket 等。安全防護:內置多種身份驗證與安全防護能力,如 Basic Auth、JSON Web Token、IP 黑白名單、OAuth 等。性能高:API7 使用 Radixtree 算法實現高性能、靈活路由。全動態能力:修改網關配置、增加或修改插件等,無需重啟網關服務即可實時生效;支持動態加載SSL 證書。擴展能力強:借助靈活的插件機制,可針對內部業務完成功能定制;支持自定義負載均衡算法與路由算法,不受限于 API 網關實現。治理能力豐富:如故障隔離、熔斷降級、限流限速等。云原生應用引擎技術發展白皮書19第二章 云原生應用引擎-數云時代的關鍵技術組件(1)Kong 簡介Kong 是 由
34、Mashape 公 司 開 源 API 網 關,基 于 OpenResty(NGINX 結 合 LUA 模 塊)和 Apache Cassandra 或 PostgreSQL 構建。Kong 的三個主要組件為 Kong server:基于 NGINX 的服務器,用來接收API 請求;Apache Casssandra/PostgreSQL:用來存儲操作數據;Kong dashboard:官方推薦 UI 管理工具。(2)Kong 特點:擴展性好:內置插件編寫的 API 用于特定功能擴展。豐富的功能模塊:包括身份認證、安全控制、流量控制、分析監控、協議轉換、日志應用等。動態配置能力:可以通過聲明式
35、或 Restful 接口可進行高級路由、主動健康檢查等各種配置。授權認證功能豐富:可支持 JWT、OAUTH 或基于 ACL 的訪問控制。原生的 KIC 支持。5.Kong 介紹云原生應用引擎技術發展白皮書20第二章 云原生應用引擎-數云時代的關鍵技術組件(1)Linkerd 簡介Linkerd 是開源的網絡代理,設計為以服務網格部署,用于管理、控制和監控應用程序內的服務與服務間通訊的數據平面。Linkerd 為應用程序增加了可視性、控制和可靠性,它使用了熔斷、延遲感知負載均衡,最終一致服務發現、截止時間傳播以及跟蹤和 dashboard 等技術。Linkerd 利用一個抽象層來提供一致的跨服
36、務,以及統一的dashboard 和控制層,并通過分離通訊機制與應用代碼,讓服務所有者自由選擇最適合其服務的語言,其基本架構如下圖:圖 11 Linkerd 基本架構Linkerd 作為單獨的獨立代理運行,應用程序通過這些實例代理調用,而不是直接連接到目標。Linkerd應用路由規則,與現有服務發現機制進行通信,從而讓服務方及使用方不必關心產品的部署拓撲,解耦服務發現。Linkerd 在此過程中收集到各種性能指標,如請求、成功率及延遲分布等。6.Linkerd 介紹云原生應用引擎技術發展白皮書21第二章 云原生應用引擎-數云時代的關鍵技術組件(2)Linkerd 特點:負載均衡:Linkerd
37、 提供了多種負載均衡算法,它們使用實時性能指標來分配負載并減少整個應用程序的尾部延遲。熔斷:Linkerd 包含自動熔斷,將停止將流量發送到被認為不健康的實例,從而使他們有機會恢復并避免連鎖反應故障。服務發現:Linkerd 與各種服務發現后端集成,通過刪除特定的(ad-hoc)服務發現實現來幫助用戶降低代碼的復雜性。動態請求路由:Linkerd 啟用動態請求路由和重新路由,允許用戶使用最少量的配置來設置分段服務(staging service),金絲雀(canaries),藍綠部署(blue-green deploy),跨 DC 故障切換和黑暗流量(dark traffic)。重試次數和截止
38、日期:Linkerd 可以在某些故障時自動重試請求,并且可以在指定的時間段之后讓請求超時。gRPC:Linkerd 支持 HTTP/2 和 TLS,允許它路由 gRPC 請求,支持高級 RPC 機制,如雙向流,流程控制和結構化數據負載。分布式跟蹤:Linkerd 支持分布式跟蹤和度量,可以提供跨越所有服務的統一的可觀測性。云原生應用引擎技術發展白皮書22第二章 云原生應用引擎-數云時代的關鍵技術組件在云原生環境下,基于應用引擎的代理技術衍生出多種產品來服務于云原生環境的不同場景,如 API 網關、入/出口網關、邊車等。(1)產生背景在微服務架構中,通常會將大型服務拆分成多個獨立的微服務,每個微
39、服務會以 API 形式對外提供。但是在呈現給用戶的交互界面,又需要在一個頁面上顯示來自不同微服務的數據,此時需要統一的入口來進行 API的調用,API 網關就在此場景下應運而生。API 網關屏蔽了系統的內部復雜結構,同時還具有 API 管理/調用等通用功能,如認證,限流,流控等。(2)API 網關特點 API 網關通過與微服務注冊中心連接實現微服務無感知動態擴容。API 網關對于出現無法訪問的服務,會自動熔斷,而無需人工參與。API 網關具備藍綠部署,金絲雀發布或 A/B 發布的能力。API 網關做為系統統一入口,實現各應用微服務共需的授權認證協議轉換等通用能力,同時擔負對后端的負載均衡。AP
40、I 網關具備能力編排的能力,將不同微服務編排成為新的服務。綜上,API 網關的意義在于為云原生應用的基礎設施,實現了相關業務和服務的可靠訪問。1.API 網關(三)云原生應用引擎的衍生產品形態云原生應用引擎技術發展白皮書23第二章 云原生應用引擎-數云時代的關鍵技術組件2.入/出口網關(1)產生背景作為云化應用部署基礎的 K8s 集群構建出了獨立的虛擬專用網絡,為集群內部的應用和外界的交互帶來了障礙,因此需要通過特定的代理程序來實現數據的路由和轉發,入/出口網關是在這樣的背景下所產生。入口網關提供 K8s 集群外部訪問集群內部的路由能力,以及負載均衡、SSL 和基于名稱的虛擬托管。與之相反,出
41、口網關為 K8s 集群提供集群內部訪問集群外部能力,即 Egress。兩種功能可以集中到一個節點上。K8s 集群對外暴露服務還有另外兩種技術:Nodeport 和 LoadBalancer,入口網關與兩者相比,可以減少不必要的端口暴露,安全性更好。圖 12 入口網關云原生應用引擎技術發展白皮書24第二章 云原生應用引擎-數云時代的關鍵技術組件(2)入/出口網關特點多協議支持:除對 HTTP 協議之外,還對特定協議,如 HTTP 2,WebSocket 或標準的 TCP/UDP 協議進行支持。主動健康檢查能力:特別是入口網關會定期對 K8s 集群內部的服務進行探測,保障客戶端訪問集群內服務的可用
42、性和及時性。實時監測:入/出口網關會將業務監控指標推送到集群的統一監控平臺,或按需產生調用鏈的跟蹤信息。動態配置:入/出口網關會接收 K8s 集群下發的策略,并及時的應用生效。綜上,入/出口網關提供了 K8s 集群和外部交互的安全、便捷機制。(1)產生背景邊車模式是一種將應用注冊、通信、安全功能從應用本身剝離出來作為單獨進程的方式。該模式允許我們向應用無侵入添加多種功能,避免了為滿足第三方組件需求而向應用添加額外的配置代碼。在微服務的架構下,應用的業務邏輯和網絡傳輸應解耦,網絡對應用應透明,網絡控制邏輯應盡可能由網絡傳輸組件處理,此類的需求特別適合用邊車模式解決,所謂的邊車產品應運而生。(2)
43、邊車的特點多語言適配:可以滿足任何編程語言編寫業務應用。實現資源共享:邊車可以訪問與主應用程序相同的資源。例如,邊車可以監控邊車和主應用程序使用的系統資源。低延遲:由于邊車靠近主應用程序,因此在它們之間進行通信時沒有明顯的延遲。功能擴展:對于不提供可擴展性機制的應用程序,也可以使用邊車擴展功能。綜上,邊車在不影響現有業務的情況下,對應用服務進行功能擴展,滿足云化改造的需要。比如,邊車可以幫助服務注冊到相應的服務發現系統,并對服務做相關的健康檢查。再如,邊車可以幫助從服務發現中找到相應外部服務的地址,然后做服務路由。另外,邊車接管了進出的流量,可以實現相應的日志監控、調用鏈跟蹤、流控熔斷等功能。
44、3.邊車云原生應用引擎技術發展白皮書25第二章 云原生應用引擎-數云時代的關鍵技術組件3 翼托.白話零信任 m.北京:電子工業出版社.圖 13 微隔離示意圖圖 14 基于微隔離的零信任架構如果黑客已經攻進了一個服務器,那么他就可以利用這個服務器做跳板,進一步攻擊網絡中的其他服務器。微隔離可以阻止這種來自內部的橫向攻擊。微隔離通過服務器間的訪問控制,阻斷勒索病毒在內部網絡中的蔓延,降低黑客的攻擊面。NIST 給出的基于微隔離技術實現的零信任架構如下圖。圖中業務系統服務器上安裝了 agent,數據資源前面安裝了網關。兩者都受到管理平臺的統一管理。(1)產生背景微隔離是 NIST 白皮書總結的在零信
45、任計算環境下,用于實現東西向安全的(服務器跟服務器間的安全)技術,是零信任架構的重要組成部分。4.微隔離3云原生應用引擎技術發展白皮書26第二章 云原生應用引擎-數云時代的關鍵技術組件業務系統先通過 agent 做身份認證。認證通過后,網關才會放行業務系統去獲取數據資源。否則,會被網關攔截。隨著系統虛擬化及云化,可以采用基礎設施的虛擬化設備的能力進行隔離。但基于基礎設施的虛擬化無法基于業務做太細力度的控制,因此隨著技術架構的云化演進,邊車模式成為云原生環境的微隔離部署架構首選。以 NGINX 實現的邊車功能為例,它可以通過入口網關接口對接 K8s 下發的安全策略,通過實現對 service的出
46、入的流量劫持,實現傳輸加密、訪問授權、認證等能力。(2)微隔離特點可視化:識別信息在公司中的流動方式,知道有哪些數據流流經用戶的路由網關,標識應用間的連接和依賴性,建立整體架構的可視化流量拓撲圖。專注高優先級目標:了解每個主機的攻擊面,從關鍵應用開始隔離。應該使用白名單策略,保持默認拒絕。策略模型:不是針對網絡結構(例如,VLAN、子網、區域或 IP 地址等)創建策略,而是基于應用、角色、標簽、分組來定義策略。制定能以最少數量提供最大覆蓋面的規則集。綜上,微隔離通過對東西向流量附加更多的訪問控制,有力保障了微服務架構下的數據安全。圖 15 微服務隔離云原生應用引擎技術發展白皮書27第二章 云原
47、生應用引擎-數云時代的關鍵技術組件(1)產生背景典型消息系統架構包括生產者、消費者以及 broker。而消息系統中 broker 的水平擴展一直是消息系統使用的關鍵痛點。以 MQTT 的架構為例,作為客戶端的消息生產者以及消費者,必須連接到每一個 broker,因此,在 broker 變動時,必然帶來對客戶端配置的變更及連接的切換,從而影響業務。同時,消息系統的數據分片大多存在冷熱不均的情況,容易造成訪問熱點影響消息系統的整體性能。為了解決這些問題,需要基于標準 Proxy 架構實現針對某種特定消息類型的代理應用服務器,即消息代理。圖 16 消息代理(2)消息代理特點消息路由:根據發送的主題,
48、自動選擇后端合適的 broker 進行消息的轉發??煽總鬏敚寒斏a者發送消息到代理時,代理會檢測后端 broker 狀態,當該 broker 故障時,把消息路由到其他備份的 broker,從而維持生產者到后端的 TCP 連接不變,保證業務的高可用性。消息變換:當一條消息到達代理時,該數據可以轉變為其他協議類型的數據,并轉發到相應的服務。綜上,消息代理可以彌補消息系統的實現缺陷,保證整個系統的高性能、可靠性和高可用性。5.消息代理云原生應用引擎技術發展白皮書28第二章 云原生應用引擎-數云時代的關鍵技術組件過去幾年中,云原生關鍵技術被廣泛采納,云原生產業日趨完善,在管理、控制、數據和支撐平面中都
49、建立了良好的產業生態,形成了十分成熟的云原生產品。在數據平面,作為云原生環境部署里的基礎組件,應用引擎產品以其無狀態、可觀測、動態配置以及 DevOps 集成能力,在微服務體系中實現了 API 網關、入出口網關、邊車、消息代理等一系列功能。這些應用引擎產品在數據平面實現了安全、高效部署,以及與管理、控制平面的協同交互與功能解耦。圖 17 云原生產業圖譜(四)云原生產業圖譜下的應用引擎云原生應用引擎技術發展白皮書29第二章 云原生應用引擎-數云時代的關鍵技術組件當前云原生應用引擎技術路線多樣化,缺乏統一的服務質量衡量標準。在目前的云原生環境下,應用引擎由提供通信網關功能的南北向控制引擎以及提供透
50、明流量劫持、熔斷、遙測與故障注入等新功能特性的東西向控制引擎組成。其中,南北向應用控制引擎技術相對較為統一,普遍采用 NGINX 作為主流的應用引擎。然而,作為云原生應用架構的核心組件的東西向應用控制引擎,其技術路線和產品形態呈現出多樣化發展的局面,尚未形成核心技術壟斷格局。例如,其應用部署模式存在著多種方式,包括反向代理模式、路由網格模式以及矩陣網格模式。這些應用引擎技術的部署模式尚未固化,工作原理互不相同,尚未形成統一的標準,難以客觀公正地衡量其服務質量。為了更好地適應產業生態的規?;l展,需要制定統一、明確的服務質量衡量標準,幫助企業判斷和評估各條技術路線的前景和局限,選擇最適合自己的應
51、用引擎技術路線和工具,實現產品規范化發展。當前云原生應用引擎能耗問題突出,性能有待提升。一方面,應用引擎在提升效率和安全性的同時帶來了能耗問題。在數據層面,應用引擎把應用前端的服務控制、流量傳遞等功能集約化,并與具體應用服務的業務功能進行解耦,實現業務和數據分離。當業務或數據本身發生變化,只需要針對業務或數據部分單獨進行處理,從而提升了效率。與此同時,云原生應用引擎針對業務流量在數據層面進行統一控制從而提升了安全性。然而,在提升效率和安全性的同時,云原生應用引擎會占用一定的資源,從而帶來能耗問題。為了更好地應用云原生應用引擎技術,需要進一步降低其運行時能耗,實現效率和能耗之間的合理權衡。另一方
52、面,應用引擎的性能還有進一步提升的空間。在實際應用過程中,云原生應用引擎技術的性能還沒有充分發揮出來。在部分應用中,應用引擎變成了新的業務的瓶頸,反而阻礙了性能的提升。例如,部分應用引擎技術路線中仍然大量采用 Go語言進行開發,盡管 Go 語言語法簡單并可以進行并發編程,但基于 Go 語言的應用引擎技術產品性能還低于基于 C 和 Rust 語言的應用引擎。我國應用引擎技術創新不足,存在信息安全風險。掌握核心技術是擁有產業話語權的關鍵,而我國在云原生應用引擎技術方面還處于快速發展階段,尚未完全掌握其核心技術,由此引發的挑戰主要體現在以下兩個方面:一是關鍵技術理論創新少,關鍵領域面臨信息安全風險。
53、當前我國應用引擎開發以應用國外產品、基于開源項目自研和改造為主。而這些產品和開源項目主要以國外公司主導,我國企業在其中的關鍵技術上多為引進或復制,理論創新較少。例如,不少國內應用引擎產品是在開源的 NGINX 應用引擎的基礎上直接進行開發。在當前復雜的國際形勢下,應用引擎技術存在被卡脖子等因素而引入信息安全風險,特別是在國家重點行業。例如,目前金融行業廣泛使用 NGINX 應用引擎技術,一旦該技術發生停服或者安全漏洞無法快速修復,將給國家金融穩定帶來巨大挑戰。因此,掌握核心應用引擎技術,是我國在云原生生態發展、防范重大信息安全風險的必備條件。二是國內尚無規?;拈_源社區支撐云原生應用引擎的創新
54、。開源社區是推動產業不斷升級、技術不斷創新的重要動力源泉。根據云原生計算基金會(CNCF4)官網公布的數據,CNCF 作為當前全球最大的云原生開源組織,其成員經濟規??偤鸵呀洺^ 20 萬億美元,但是它是由國外公司主導成立,國內尚未形成規?;膽靡骈_源社區推動云原生應用引擎創新發展。因此,亟需成立獨立的開源社區來支撐國內云原生產業的創新能力,營造良好的創新土壤。4 https:/cf.io/,2023 年 3 月(五)云原生應用引擎面臨的挑戰30云原生應用引擎技術發展白皮書31(一)金融行業1.七層軟負載全球數字化轉型持續加速,越來越多的企業業務都向互聯網化、移動化發展,各種 APP 的數
55、量爆炸式增長。在云原生技術蓬勃發展的今天,其對金融行業的影響越來越大,成為數字化轉型的新動力。金融行業的云原生實際應用部署也越來越多,更多的業務朝著 PaaS 方向演進,越來越多銀行開始將分布式云原生架構作為下一代銀行核心技術架構。而應用引擎作為云原生部署中的關鍵節點,對于金融行業實現云原生應用的敏捷、穩定、安全交付至關重要,在入出口控制、API 統一、緩存加速、負載均衡、安全防護等方面發揮各種不同功能和角色作用。圖 18 七層軟負載在云原生和傳統環境下,均有在四、七層分離 ADC 部署的場景,通常四層 ADC 由硬件 ADC 承擔保證性能,七層為軟軟負載部署,提升業務的靈活性和擴展性。第三章
56、 云原生應用引擎行業應用場景和價值云原生應用引擎技術發展白皮書32第三章 云原生應用引擎行業應用場景和價值金融行業的計算資源逐步向上集中到數據中心,另外業務對帶寬資源的需求也在不斷增長,例如分行、支行和網點等分支機構的帶寬需求日益緊張。在此背景下,如何降低帶寬消耗、提升用戶訪問體驗顯得更加迫切。圖 19 邊緣緩存應用因此,通過在分行、支行、網點部署緩存節點,來達到降低帶寬減少擁塞、提升體驗,是一個低成本、易于部署的解決方案。緩存節點的部署,可以是單級、兩級或者多級。結合緩存節點的管理平臺,實現管理等集中化,業務可視化,運維簡易方便的特點。2.邊緣緩存應用云原生應用引擎技術發展白皮書33第三章
57、云原生應用引擎行業應用場景和價值圖 20 云原生入口網關3.云原生入口網關在云原生平臺 K8s 中,南北向的入口網關已經成為必需組件。入口網關公開了從集群外部到集群內服務的HTTP 和 HTTPS 路由,可為 Service 提供外部可訪問的 URL、負載均衡流量、SSL/TLS 卸載、虛擬托管等。云原生應用引擎技術發展白皮書34第三章 云原生應用引擎行業應用場景和價值云原生環境下,通常 K8s 集群與入口網關為 1 對 1 關系,不同 K8s 集群之間是獨立的。K8s 集群內部通過冗余 pod 實現容器的更高可靠性,但是 K8s 集群之間難以互相備份以實現集群多活等更高的可靠性要求。通過入口
58、網關接入到多個 K8s 集群,支持多 K8s 集群訂閱,從而實現跨集群流量轉發。圖 21 云原生應用引擎的集群多活中心集群的入口網關訂閱了業務集群的 API Server,同時支持業務流量從中心集群的入口網關流向業務集群,從而實現了集群業務的多活能力。4.云原生應用引擎的集群多活云原生應用引擎技術發展白皮書35第三章 云原生應用引擎行業應用場景和價值5.云原生應用安全當前在金融的云原生生態中,面臨跟其他行業類似問題,應用快速迭代,傳統應用和現代應用并存,機器人攻擊和欺詐更加難以防范,管理和防護 API 風險增高,開源創新帶來新的安全風險等。由于金融行業本身特殊性質,云原生安全顯得更為復雜和緊迫
59、。云原生應用安全跟傳統安全的本質差別在于云平臺安全原生化,安全產品本身要原生化,能夠內嵌融合于云,同時能夠有效解決云上安全風險。云原生安全體系和架構要與云計算環境相融合。圖 22 云原生應用安全從被保護對象角度,云原生安全分為數據面的安全防護、控制面的安全合規和防護、云訪問安全。云原生引擎結合安全分析和策略平臺,可以提供強大的數據面保護能力,包括應用安全和 API 安全?;诎踩幏逗筒呗?,在容器入口處提供通用安全策略、輕量級高性能的安全防護,實時感知安全態勢;并將安全情報數據輸送到安全分析平臺,通過 K8s API 調整安全策略,形成閉環,增強云原生場景下的安全防護和安全監控。云原生應用引擎
60、技術發展白皮書36第三章 云原生應用引擎行業應用場景和價值(1)支持業務的平滑改造和升級在實現數字化金融過程中,金融行業普遍向云原生技術方案演進?;谌萜?、K8s、微服務為代表的云原生技術,通過應用引擎的灰度發布、藍綠發布技術,實現業務彈性擴縮容、平滑無損升級;借助應用引擎動態變更后端服務的能力,無縫支持動態分配計算資源,從而達到降本增效的效果。(2)支持多集群和高可靠性金融業務本身需要保證高可靠性,常見部署架構有同城雙活、異地容災和兩地三中心。應用引擎支持上述部署架構,在業務節點故障情況下實現業務數據的快速切換,從而保障業務的不間斷運行;甚至在集群集群故障情況下,實現集群業務的流量切換。(3
61、)確保云原生業務的安全性應用引擎作為云原生集群入出口網關控制點,具備作為安全控制點的要求,結合認證和授權和加密技術,保證數據私密性、防止非法泄露,保證數據訪問使用方可追蹤追責;結合防 DOS 攻擊、WAF 技術,確保集群整體網絡安全。同時應用引擎支持對云安全業務的靈活編排、快速迭代,使得 DevSecOps 實現敏捷安全的部署和升級,靈活對接各種安全單元,提升安全能力。云原生環境下可能存在多種應用架構,需要統一開放 API,提供統一的認證接入管理和 Bot/DOS 安全防護能力;提供 API 分流管理和配額管理、請求限速、協議轉換,以及 API 數據分析和流量可視化,一定的應用安全防護等。以上
62、需求歸納為應用引擎需要提供 API 網關能力以及管理能力。除此以外,在 API 數量不斷增長情況下,API 網關要能夠支持彈性擴容、配置同步、狀態監控、易于部署等。6.API 網關7.云原生應用引擎在金融行業的價值云原生應用引擎技術發展白皮書37第三章 云原生應用引擎行業應用場景和價值隨著云原生理念的推廣與技術的不斷豐富,云原生已經進入成熟階段。電信行業云原生理念是指各組織在公有云、私有云和混合云等新型動態環境中,構建和運行可彈性擴展的應用。電信行業云原生是一系列思想的集合,包括容器、服務網格、微服務、不可變基礎設施、聲明式 API 等云原生技術。電信行業中云原生最初階段是為上層應用提供技術、
63、網絡、存儲的基礎架構資源,之后是通過容器、微服務、DevOps 三者結合建立 PaaS 平臺實現 DevOps,最后是基于業務復雜度,將復雜業務分拆、松耦合、獨立更新部署、管理及流程自動化來實現微服務治理和 API 運營。電信行業云原生落地并逐步演進也是從單數據中心到多云、混云架構。電信行業云原生可以基于微服務架構進行應用設計與開發,使用容器進行應用承載與編排,采用 DevOps 打造開發運維一體化管理體系。(二)電信行業云原生應用引擎技術發展白皮書38第三章 云原生應用引擎行業應用場景和價值1.某運營商 PaaS 平臺某運營商 PaaS 平臺基于服務網格(Service Mesh)構架對微服
64、務進行管理,選擇以 Docker 和 K8s 為基礎來構建 PaaS 平臺方案。通過虛擬化的方式,可以在幾秒鐘之內虛擬出一個小的、獨立的、隨需隨用的 CPU內核,使得服務可以通過更細的粒度對資源進行控制。該 PaaS 平臺提供操作簡便的一鍵式服務自動化部署、統一配置管理、應用的彈性擴縮容、微服務管控、DevOps 工具鏈、資源/服務/容器等多維度綜合監控、安全管控等功能。PaaS 平臺服務配置與部署中心提供對服務網關的配置管理。網關規則描述了一個運行在服務網格邊緣的負載均衡器,用于接收轉入或轉出的 HTTP/TCP 連接。支持規則配置與流量路由,控制服務之間的流量和API 調用,實現對斷路器、
65、超時和重試等服務級別屬性的配置簡化,幫助應用開發人員輕松設置 A/B 測試、灰度發布、藍綠部署、金絲雀部署和基于百分比的流量分割的分階段部署等任務。支持流量負載,支持跨集群的流量分配比例,集群內多實例之間流量分配比例,提供集群的高可用性。如下圖所示:圖 23 PaaS 服務網格管理架構云原生應用引擎技術發展白皮書39第三章 云原生應用引擎行業應用場景和價值某運營商核心業務支撐系統的監控模塊采用分布式部署方式,支持動態增減存儲資源,包括本地存儲、集中存儲、超融合等多種方式。該監控模塊具備多租戶安全隔離、細粒度、多維度以及動態配置等特點。2.某運營商核心業務支撐系統圖 24 系統監控架構該系統在監
66、控上層采用 NGINX 和 Prometheus 的架構模式,利用 Prometheus 搭建層次化,多維度網格式的監控體系,通過上層 NGINX 對業務側的系統平臺、租戶、資源和應用進行統一的管理。云原生應用引擎技術發展白皮書40第三章 云原生應用引擎行業應用場景和價值3.某運營商 IT 智能運維系統某運營商 IT 智能運維系統通過構建統一的混合云管平臺,支持私有云和公有云的混合云等多云環境下混合資源的統一調度、統一監控,并基于 K8s 容器框架實現資源統一調度、業務智能調度以及多集群管理的能力。該 IT 智能運維系統架構如下所示:圖 25 IT 智能運維系統該系統分成了五層,分別為門戶層、
67、能力開放層、能力中心層、PaaS 平臺層、IaaS 基礎設施層?;诮y一 PaaS 平臺組件構建能力中心,通過統一能力開放網關對應用層提供服務。該系統通過能力開放平臺以及 LVS/NGINX 實現前后端解耦、應用邏輯和數據存儲分離以及系統中心化、微服務化設計的能力。云原生應用引擎技術發展白皮書41第三章 云原生應用引擎行業應用場景和價值該系統上云應用能夠根據特點選擇清單內 PaaS 組件、容器實例級別隔離以及按需擴容,也可以拆分為多個集群。擴容和拆分過程做到對應用透明。該系統上云應用部署架構如下所示:圖 26 IT 系統部署架構系統訪問入口采用軟負載獨立部署,主要是 LVS/NGINX,基于
68、NG 進行應用安全防護。應用部署的環境包含物理機、虛擬機、容器三種共存,對于 K8s 集群根據系統特點至少分為兩個大集群:核心生產集群、小系統集群。其中,核心生產集群在綜合考慮負載、安全、內控因素后可以拆分為多個,而 PaaS 平臺部分主要是管理和選擇使用各種類型的 PaaS 組件。云原生應用引擎技術發展白皮書42第三章 云原生應用引擎行業應用場景和價值4.某運營商應用管理中心電信行業業務在微服務模式下,運營商內部服務少則幾個到幾十個,多則上百個,每個服務一般都是以集群方式部署,一個服務消費方對應有多個的服務提供方。電信行業中服務的消費方如何發現服務的提供方?如何實現服務的動態上下架?服務的消
69、費方如何實現某種負載均衡策略訪問集群中的服務提供方實例?針對這些問題,電信行業中引入了云原生應用引擎技術,提供一個統一的云原生網關來管理業務的前臺集群和微服務后臺集群,如下圖所示:基于云原生應用引擎的以一個嵌入式服務發現的方式,實現統一網關和動態路由的公共組件。適用于所有由 Java 語言編寫的并基于 HTTP(S)訪問的微服務或應用(多集群環境最佳),為微服務或應用提供服務自動發現、自動注冊、動態路由、灰度發布、A/B 測試等功能,并且能夠做到多環境部署、切換時用戶無感知。圖 27 基于云原生應用引擎技術的集群管理云原生應用引擎技術發展白皮書43第三章 云原生應用引擎行業應用場景和價值圖 2
70、8 基于云原生應用引擎技術的應用管理中心架構圖基于云原生應用引擎技術的應用管理中心架構如下圖所示:應用管理中心包含了網關層、業務層以及數據層。頂層網關層:是采用的 LVS 或者 NGINX 來實現。業務層:是運營商內部的業務系統或前臺服務集群,以及支撐業務系統的后臺服務集群。數據層:是支持業務系統運行的數據庫以及通信和緩存的 MQ 和 Redis 等組件。云原生應用引擎技術發展白皮書44第三章 云原生應用引擎行業應用場景和價值5.云原生應用引擎在電信行業的價值(1)計算資源彈性調度電信行業云原生設計,在電信業務服務負載快速上升時,及時擴容計算資源,保證應用性能穩定;在負載下降時,及時回收計算資
71、源,加快資源在不同租戶函數間的流轉,提高數據中心利用率。通過計算資源的彈性調度,幫助用戶完成指標收集、在線決策、離線分析、決策優化的閉環。(2)負載均衡和流控電信行業云原生架構下,負載均衡和流控提升以及可保證后端服務的質量,并且多租戶模式下,具備出色的隔離能力,避免應用服務相互干擾。(3)推進云原生標準化電信運營商攜手合作伙伴共同推進電信行業云原生技術標準化工作,如電信網絡云原生架構、容器技術與相關接口等,解決電信行業缺少云原生參考標準現狀。(4)提升多集群管理云原生應用提升電信行業中多集群異構資源池,異地資源池、異版本資源池的統一管理以及服務多集群同時發布,在多集群管理的基礎上,實現災備雙活
72、的電信行業的業務系統。45云原生應用引擎技術發展白皮書46第四章 云原生應用引擎展望(一)無服務器架構云原生應用引擎技術新路線當前的云原生應用引擎技術路線普遍采用代理技術,性能還有很大的優化空間。與此同時,隨著業務的復雜程度飆升,在創新發展需求的不斷驅動下,用戶的關注點逐漸上移,敏捷成為破局高頻競爭的利器。為了提高開發部署的效率,以應用為中心、屏蔽底層復雜邏輯,靈活擴展、按需取用的無服務器架構(Serverless)技術成為云時代的迫切需求。Serverless 技術通過將業務功能解耦,逐步把業務應用和基礎設施分離,從而使得開發人員無需關心基礎設施的運維工作,只需專注于應用邏輯的開發,簡化了開
73、發難度。因此,Serverless已然成為一種具有廣闊應用前景的云原生應用引擎技術新路線。Serverless 是一種彈性伸縮、按需付費、簡化運維的應用引擎技術。Serverless 將應用與基礎設施徹底分離,其核心思想是將提供服務資源的基礎設施抽象成各種服務,以 API 接口的方式供給用戶按需調用。由于應用架構堆棧中的各類資源的管理將全部委托給平臺,免去了基礎設施的運維,使得開發人員更聚焦高價值的業務領域,專注于應用邏輯的開發,僅在事件觸發時才調用計算資源,真正做到了彈性伸縮與按需付費。這種架構體系結構消除了對傳統的海量持續在線服務器組件的需求,降低了開發和運維的復雜性,同時降低運營成本并縮
74、短了業務系統的交付周期,使得用戶能夠專注在價值密度更高的業務邏輯的開發上。當前國內 Serverless 的技術生態良好,相關產品層出不窮。例如,在平臺層,華為、阿里、騰訊、百度等均推出了云函數計算服務產品,與此同時,Knative、Apache OpenWhisk 等開源無服務器架構框架也發展較為成熟;在工具鏈方面,螞蟻金服、騰訊云、華為云、阿里云等國內公司相繼開發出了用于應用框架、可視化、測試調試、安裝部署的相應工具。相對于代理技術,Serverless 應用效率高、開發難度低,但兼容性還有待提高。Serverless 使開發人員無需關心基礎設施運維、只需專注于應用邏輯開發的模式主要帶來了
75、兩方面的優勢。Serverless 通過大量的遠程過程調用(RPC),擺脫了對 Web 服務器以及 HTTP 協議的依賴,應用效率顯著提升。開發者可以基于函數即服務(FaaS)功能,只需編寫業務函數代碼并設置運行的條件,計算資源以服務形式提供無需考慮資源容量與基礎設施運維,減少了需要開發的內容,縮短了開發交付時間,從而使得開發交付更加敏捷,降低了開發的難度。但是,在 Serverless 的應用兼容性和改造成本還需要不斷優化。在 Serverless 架構中,原有應用無法直接使用,需要進行必要的重構。具體來說,應用需要重構成底層的基礎功能,抽象成后端即服務(BaaS),所承載的業務功能需要拆分
76、成函數。在 Serverless 應用遷移改造的過程中,Serverless 中的重構后的應用很難與原有應用相互兼容,并且改造重構各種應用存在一定的成本和負擔。云原生應用引擎技術發展白皮書47第四章 云原生應用引擎展望(二)應用引擎中國云原生技術創新突破口云原生技術棧已經發展較為成熟,其核心領域已經形成了統一的事實標準。例如,容器編排領域的 K8s、服務網格領域的 Istio。這些領域的核心技術主要由國外公司主導,我國起步相對較晚,技術創新難度大。相對于這些云原生核心技術領域,應用引擎領域的技術路線尚未統一、產品形態多樣化。因此,云原生應用引擎領域是我國在云原生產業實現加速追趕、彎道超車的重要
77、機遇,針對該領域的空白快速進行技術突破具有十分重要的意義。推進我國應用引擎技術創新是保障云原生數據安全的關鍵。云原生應用引擎提供了服務網格中東西向通信、透明流量劫持、熔斷、遙測與故障注入等新功能特性,與此同時,它是服務網格數據面唯一的控制系統,控制著云原生應用數據流轉的中轉站,其地位和作用在云原生架構中十分重要。由于應用引擎控制著大量的云原生應用核心數據,應用引擎技術的安全直接關系到國家和企業的信息和數據安全。所以,掌握應用引擎的安全可控,替換國密算法,采用信息技術應用創新應用引擎是保障我國關鍵領域數據安全的重要舉措。例如,基于 NGINX開源引擎基礎上的云原生微服務 API 網關技術 Apa
78、che APISIX 通過設置多種身份認證方式、正則表達式拒絕服務、替換國密算法等一系列舉措保障了其云原生應用數據的安全。因此,為了保障我國云原生信息和數據的安全,有必要堅持核心技術創新發展、推動云原生國密算法替換、提高信息技術應用創新應用引擎采用率。部分國內企業已有應用引擎開發經驗,已經具備創新基礎。當前國內企業在云原生應用引擎的技術研發上緊跟國際產業發展趨勢,例如,通明智云、騰訊云、華為云等企業已經有企業具備應用引擎開發能力。因此,相較于操作系統,云原生應用引擎技術的技術創新難度要小得多。在現有基礎上,國內企業通過聯合構建創新聯合體,可以在有限的資源和人員投入下取得重要創新突破。此外,當前
79、的應用引擎技術的難度和復雜度還比較低。例如,目前的 NGINX 引擎開發人員不超過 57 人,代碼量不超過 50 萬行。因此,我國云原生應用引擎取得創新突破的可能性很高。云原生技術棧高速發展,發展信息技術應用創新云原生應用引擎迫在眉睫。目前,云原生應用尚未全部下沉到應用引擎,其技術難度和復雜度還相對較低。未來,將會有越來越多的云原生應用下沉到應用引擎,此時的應用引擎創新難度和復雜度將遠遠超過現有水平。屆時,應用引擎所要承擔的功能任務會更多、更復雜、也更綜合,例如:流量劫持透明帶、協議自動識別、自動的 ACL 控制、自動安全防護能力、自動遙測功能,甚至自動故障注入等。因此,現階段是應用引擎技術快
80、速發展的絕佳時機,將來的應用引擎技術難度會遠超應用開發的難度,技術門檻會越來越高。開放兼容是信息技術應用創新應用引擎發展的重點。應用引擎技術的創新不是閉門造車,需要廣泛吸取借鑒各種技術的優勢和短板,基于現有的比較成熟的項目和技術進行開發與創新。一是應選擇主流開發語言。為了與國際云原生主流應用接軌、保障應用引擎的生命力,應用引擎最好選擇 C、Rust 等主流的開發語言。通過深入學習和參考 NGINX、Linkerd 等經典原型,可以少走彎路、快速構建應用引擎的基本架構。二是需要適配多種云原生應用場景和主要功能應用形態。應用引擎產品形態涉及了 API 網關、入/出口網關、邊車、微隔離、消息代理等。
81、為了提升云原生應用引擎的兼容性,需要支持以上多種甚至全部產品形態。與此同時,應用引擎還應支持底層國密算法,保障云原生信息安全。三是需要兼容信息技術應用創新類軟件和硬件產品。開放兼容的云原生應用引擎需要構建良好的上下游生態環境,需要兼容信息技術應用創新芯片、服務器、操作系統、數據庫中間件和應用軟件等,從而營造出更加良好的產業生態以及更加廣闊的技術生存空間。云原生應用引擎技術發展白皮書48第四章 云原生應用引擎展望一是構建應用引擎開源社區,鼓勵技術創新。開源社區是云原生應用引擎的創新源泉和主要開發場所,對于關鍵技術的創新突破極其重要。然而,現階段國內尚未形成具有一定規模的云原生應用引擎開源社區,不
82、利于應用引擎技術的持續創新和發展,不符合國家在云原生領域創新的戰略需求。因此,需要通過建立完善的開源社區來吸引全球范圍內相關開發人員參與,擴大影響力,促進技術生態,人才生態和用戶生態的深度融合,在云原生應用引擎產生事實影響力與話語權。通過鼓勵更多的開發者、ISV 在開源平臺上進行開發交流,形成反饋-調優-反饋-再調優的良性循環。與此同時,基于開源社區項目,應用引擎廠商可以為客戶打造出品類豐富、安全可靠的開源產品,并在已有產品上不斷優化、改進,提升客戶使用體驗。二是設立相關的技術研究機構,建立理論創新的長效機制。國內相關科研院校、龍頭企業研究部門目前對云原生應用引擎技術發展的緊迫性和潛在價值尚未
83、統一,未能形成合力,諸多關鍵技術未能有序布局、合作攻關。需要企業和科研院校加強合作,成立云原生應用引擎創新研究小組,建立理論創新的長效機制,專注于應用引擎的理論研究和技術突破。通過企業和科研機構聯合設立創新研究小組,可以推動應用引擎技術與產業供需對接、提高云原生應用引擎創新能力及產用鏈接,促進資源共享和互利共贏,從而形成聯合開發、優勢互補、利益共享、風險共擔的合力。三是加強產業互動協同,構建政產學研用生態體系。云原生應用引擎技術的快速發展離不開產業上下游互動以及聯合政產學研用各單位共同創新。通過建立企業與各單位之間的應用引擎需求牽引機制,企業可以快速了解產業上下游、政產學研用各單位的應用引擎功
84、能需求,并得到相應的資金支持,以創新項目團隊為核心,根據不同單位的真實需求進行相應的技術開發與創新。在此過程中,可以聯合其他各單位的科研人員,打開新思路、嘗試新方法,實現技術突破和功能創新。通過建立長期的產業合作關系,不斷加速應用引擎技術的科研成果落地,實現真正的核心技術。(三)中國云原生應用引擎生態建設展望49云原生應用引擎技術發展白皮書50附錄 國內云原生應用引擎產品介紹NJet 最早是基于 NGINX1.19 基礎,派生并獨立演進的開源應用引擎,并隨著 NGINX 版本迭代,吸收上游 NGINX 的更新,在本白皮書編寫時,已經同步更新到 NGINX1.23.1 版本。NJet 的目標在于
85、適應國內特定的技術規范及標準,如國密算法套件支持,并構建安全可控的云原生數據面,支撐我國云原生產業生態。作為底層引擎,NJet 利用動態加載機制可以實現不同的產品形態,如 API 網關、消息代理、出入向代理,負載均衡,WAF 等等。(一)通明智云-NJet 應用引擎圖 29 NJet 技術架構圖相比市面其他類型的API網關,高性能是NGINX主要的優點,但動態配置能力的缺乏一直受到業界的詬病。NJet 在 NGINX 的架構上進行了擴充,對其框架進行了改寫,增加了 CoPilot Framework 及可持久化的動態存儲能力,解決了指令配置變更動態生效的關鍵問題,擴展了 NJet 的應用場景。
86、此外,業界對應用引擎可觀測性的需求,需要應用引擎持續不斷的采集性能指標、日志數據以及注入跟蹤信息,但這對應用引擎的性能造成了不可忽視的影響,NJet 利用 CoPilot Framework 隔離了業務處理及配置變更和指標采集,避免了遙測對性能的影響。作為云原生的應用引擎,NJet 需要支持業界流行的入口網關及邊車的 API 規范,基于動態配置和CoPilot Framework 架構,NJet 可以通過不斷更新獨立的相關 CoPilot Module,實現對響應標準規范的及時支持。1.NJet 背景云原生應用引擎技術發展白皮書51附錄 國內云原生應用引擎產品介紹2.NJet 特點NGINX
87、有著優秀的模塊機制,但是許多業務急需的功能沒有作為正式模塊進入 NGINX,NJet 充分吸收了開源社區的優秀擴展模塊,在功能規劃上包含了 4 大類 18 類組件,特別是隨著安全威脅的快速增加趨勢,規劃了安全組件。具體功能如下圖:圖 30 NJet 具體功能云原生應用引擎技術發展白皮書52附錄 國內云原生應用引擎產品介紹NJet 功能亮點總結如下:支持 HTTP3。支持集群、高可用、Restful API。內置 WAF 模塊、支持國密/RSA 加密通訊、支持多種認證方式。支持動態配置加載。支持 LUAJit 可編程腳本控制,NJet 除了內置對 HTTP 1/2/3 的支持外,還支持利用腳本實
88、現對特定應用協議的解析,并根據協議內容進行特定的路由。數據、管控能力隔離,可觀測性需要的指標、追蹤數據采集不會影響對業務的處理,不會導致業務處理的性能降級??蛇m應本地、容器及云原生部署。除安全功能外,“企業特性”也是NJet關注的重點領域,如內置的高可用性,自動化的集群發現及配置同步。云原生應用引擎技術發展白皮書53附錄 國內云原生應用引擎產品介紹5 參考來源:https:/www.bfe- Front End,百度統一應用層流量接入轉發平臺)是百度統一的七層流量轉發平臺。BFE 日處理請求達萬億級別,目前已接入百度大部分流量,是業界最大規模的統一接入服務之一。同時,BFE 為互聯網、金融企業
89、提供完整的私有化解決方案。BFE 采用 Go 語言開發,已經貢獻開源社區。BFE 分為數據平臺和控制平面兩大部分,數據平面的 BFE Server 是核心轉發引擎,將用戶流量經過內容路由、負載均衡處理后,轉發給后端業務集群??刂破矫姘?3 個模塊:API-Server 對外提供 API 接口,完成BFE 配置的變更、存儲和生成;Conf-Agent:配置加載組件,從 API-Server 獲取最新配置,并觸發 BFE Server進行配置熱加載;Dashboard:為用戶提供了圖形化操作界面,以對 BFE 的主要配置進行管理和查看。圖 31 BFE 架構圖(二)百度-BFE51.BFE 背景
90、云原生應用引擎技術發展白皮書54附錄 國內云原生應用引擎產品介紹2.BFE 特點 流量接入和轉發:支持 HTTP、HTTPS、HTTP/2、QUIC 等多種協議,并支持強大的應用層路由能力。流量全局調度:支持由外網流量調度和內網流量調度共同構成的全局流量調度系統。安全和防攻擊:支持黑名單封禁、精細限流和應用層防火墻(WAF)等多種防攻擊能力。實時數據分析:支持分鐘級的超高維度時序報表?;诙嘧鈶艏軜嬙O計,租戶之間配置相互隔離。模塊框架靈活,支持高效率定制開發第三方擴展模塊??捎^測性:提供豐富詳盡的監控指標和各類日志供問題診斷、數據分析及可視化,以及請求分布式Tracing。云原生應用引擎技術發
91、展白皮書55附錄 國內云原生應用引擎產品介紹Higress 是基于阿里內部的 Envoy Gateway 實踐沉淀、以開源 Istio 和 Envoy 為核心構建的下一代云原生網關,實現了流量網關、微服務網關、安全網關三合一的集成能力,集成 Dubbo、Nacos、Sentinel 等微服務技術棧,支持入口網關與 API 網關。6 參考來源:https:/higress.io/zh-cn/圖 32 Higress 功能架構Higress 主要用于云原生環境,其核心數據面功能基于 Envoy 進行定制和演進,通過 Envoy 的 filter 實現路由及特定業務處理。(三)阿里-HigressE
92、61.Higress 背景云原生應用引擎技術發展白皮書56附錄 國內云原生應用引擎產品介紹2.Higress 特點 功能豐富:除數據面外,還提供 higress console 及控制面。易于使用:流量調度、服務治理、安全防護的一站式網關解決方案,支持 HTTP 到 Dubbo 協議轉換,一鍵輕松完成協議映射配置。便于擴展:提供 WASM、LUA、進程外三種插件擴展機制,支持利用不同的語言進行插件開發。安全防護:提供 JWT/OIDC/自定義認證鑒權,并集成 modSecurity 模塊增加常見的 Web 安全防護。云原生應用引擎技術發展白皮書57附錄 國內云原生應用引擎產品介紹最底層是網絡層
93、,負責收發數據包;之上是多協議層,支持 HTTP 系列協議、SOFARPC、Dubbo 等,提供自定義協議能力;流過濾器提供健康檢查、故障注入等能力;代理層提供代理框架,實現分階段處理、路由、負載均衡、連接池。每一層通過插件機制向外提供接口,方便用戶靈活的注冊自身的需求,采用協程池的方式讓用戶以同步的代碼風格實現異步的高性能。7 參考來源:https:/mosn.io/阿里 MOSN 是一款使用 Go 語言開發的網絡代理軟件,作為云原生的網絡數據平面,旨在為服務提供多協議,模塊化,智能化,安全的代理能力。MOSN 是 Modular Open Smart Network 的簡稱。MOSN 可以
94、與任何支持xDS API的 Service Mesh集成,亦可以作為獨立的四、七層負載均衡,API網關,云原生入口網關等使用。MOSN 整體架構共分四層,如下圖所示:圖 33 MOSN 分層架構(四)阿里 MOSN71.MOSN 背景云原生應用引擎技術發展白皮書58附錄 國內云原生應用引擎產品介紹 熱生效:配置熱生效;二進制平滑升級是核心競爭優勢。流量管理及路由:headers/uri 分流;連接池、健康檢查、熔斷保護、故障注入;TLS/國密。提供 4/7 層轉發能力。業務支持能力:MOSN 作為底層的高性能安全網絡代理,支撐了 RPC、消息、網關等業務場景。內存和連接池增強:通過內存池的封裝降低運行時內存回收帶來的卡頓,實現多種對象高效的復用內存;封裝了多種協議的連接池,提升服務網格之間的建連能力,實現連接復用及管理。2.MOSN 特點