基于DPU的容器冷啟動(dòng)加速解決方案

1.?方案背景

1.1.?業(yè)務(wù)背景

隨著容器技術(shù)的迅猛發(fā)展與廣泛應(yīng)用，一種新的云計(jì)算服務(wù)模式應(yīng)運(yùn)而生-函數(shù)即服務(wù)（FaaS, Function as a Service）。FaaS作為一種無(wú)服務(wù)器（Serverless）計(jì)算方式，極大地簡(jiǎn)化了開(kāi)發(fā)人員的工作，使他們能夠?qū)Ｗ⒂趹?yīng)用的構(gòu)建與運(yùn)行，而不再需要承擔(dān)服務(wù)器管理的負(fù)擔(dān)。

然而，F(xiàn)aaS模式也并非沒(méi)有缺陷，其中最為人詬病的便是“冷啟動(dòng)”問(wèn)題。所謂冷啟動(dòng)，是指當(dāng)請(qǐng)求被調(diào)度到某個(gè)函數(shù)實(shí)例時(shí)，如果該實(shí)例在上次執(zhí)行完代碼后已經(jīng)被回收，系統(tǒng)需要先創(chuàng)建一個(gè)新的實(shí)例并初始化環(huán)境，才能繼續(xù)執(zhí)行代碼。

相比之下，熱啟動(dòng)則是指函數(shù)實(shí)例未被回收的情況下，直接復(fù)用現(xiàn)有實(shí)例以響應(yīng)請(qǐng)求，這顯然效率更高。因此，冷啟動(dòng)過(guò)程常常導(dǎo)致較高的延遲，進(jìn)而影響應(yīng)用的性能。

1.2.?問(wèn)題與挑戰(zhàn)

1.2.1 傳統(tǒng)方案

根據(jù)《Slacker: Fast Distribution with Lazy Docker Containers》一文的分析，鏡像拉取過(guò)程占據(jù)了容器啟動(dòng)時(shí)間的76%，然而實(shí)際啟動(dòng)時(shí)只有6.4%的數(shù)據(jù)會(huì)被讀取。這一現(xiàn)象揭示了傳統(tǒng)容器鏡像格式和拉取方式在使用overlay文件系統(tǒng)（OverlayFS）時(shí)存在的問(wèn)題：

• 過(guò)多的時(shí)間花費(fèi)在拉取鏡像上。
• 拉取了過(guò)多無(wú)關(guān)的數(shù)據(jù)。

這兩個(gè)問(wèn)題的根源在于容器鏡像是由一組tgz文件組成，而這些文件作為鏡像層（image layer）存在以下兩個(gè)顯著缺點(diǎn)：

• 提取單個(gè)文件時(shí)，需要掃描整個(gè)layer。
• 同一層多個(gè)文件的提取不支持并行處理。

因此，使用OverlayFS的容器在啟動(dòng)前必須完成所有tgz文件的拉取和解壓，這無(wú)疑增加了啟動(dòng)時(shí)間。

針對(duì)這些問(wèn)題，社區(qū)已經(jīng)提出了一些改進(jìn)措施，具有代表性的兩個(gè)解決方案是Stargz和DADI。

1.2.2 已有的改進(jìn)方案

Stargz 是一種容器鏡像加速技術(shù)，它采用了 Google的CRFS（Container Registry Filesystem）來(lái)重新組織容器鏡像，以便實(shí)現(xiàn)更快的容器啟動(dòng)和更高效的文件檢索。CRFS是一個(gè)只讀的用戶(hù)態(tài)文件系統(tǒng)，它使用了新的文件格式，使得鏡像層內(nèi)的文件可以被隨機(jī)訪問(wèn)（seekable）。

stargz架構(gòu)圖

使用Stargz啟動(dòng)容器時(shí)，無(wú)需拉取所有層到本地，而是遠(yuǎn)程掛載每一層到本地目錄組成rootfs，從而實(shí)現(xiàn)容器的快速啟動(dòng)。容器啟動(dòng)之后的數(shù)據(jù)訪問(wèn)則是利用FUSE(用戶(hù)態(tài)文件系統(tǒng))按需獲取。

DADI(Data Accelerator for Disaggregated Infrastructure)是阿里云針對(duì)容器加速的解決方案，DADI 的核心組件是 Overlaybd，這是一種基于塊設(shè)備的鏡像格式，提供了在block-based layer之上的一個(gè)合并視圖，然后通過(guò)TCMU在Host上產(chǎn)生一個(gè)SCSI設(shè)備作為rootfs。TCMU（Target Core Module In Userspace），是scsi target的用戶(hù)態(tài)實(shí)現(xiàn)，用于生成一個(gè)容器 rootfs 的 SCSI 設(shè)備。

DADI架構(gòu)圖

使用DADI啟動(dòng)一個(gè)容器時(shí)，其也不用拉取所有層到本地，只是基于所有層塊設(shè)備創(chuàng)建一個(gè)scsi device表示rootfs，實(shí)現(xiàn)容器的快速啟動(dòng)。容器啟動(dòng)之后的數(shù)據(jù)訪問(wèn)則是由tcmu按需獲取，并且加入了本地緩存和ZFile加速數(shù)據(jù)的讀取。

1.2.3 問(wèn)題總結(jié)

綜上所述，以上方案在實(shí)際應(yīng)用中仍然存在以下問(wèn)題：

• 傳統(tǒng)OverlayFS容器的冷啟動(dòng)時(shí)間較長(zhǎng)，這可能會(huì)對(duì)性能敏感的應(yīng)用造成影響，導(dǎo)致較差的用戶(hù)體驗(yàn)。
• 改進(jìn)方案中的用戶(hù)態(tài)文件系統(tǒng)需要占用一定的主機(jī)資源，這可能會(huì)對(duì)系統(tǒng)的整體性能產(chǎn)生影響。

2.?方案介紹

2.1.?整體架構(gòu)

為了解決上述問(wèn)題，我們構(gòu)建了基于DPU的容器冷啟動(dòng)解決方案，以k8s為底座，以存儲(chǔ)為核心，利用DPU的卸載和加速能力，使容器的冷啟動(dòng)更快，占用更少的host資源。整體架構(gòu)如下所示：

1-4）：containerd會(huì)調(diào)用yusur-snapshotter準(zhǔn)備rootfs每一層的內(nèi)容快照，image-mgmt根據(jù)label參數(shù)連接存儲(chǔ)，創(chuàng)建spdk bdev。

5-9）：到最后一層時(shí)，需要?jiǎng)?chuàng)建NVMe subsystem/ctrl/ns，關(guān)聯(lián)spdk bdev，此時(shí)在host側(cè)給相應(yīng)PCI綁定NVMe驅(qū)動(dòng)，即可看到對(duì)應(yīng)的NVMe disk。

10）：yusur-snapshotter查到disk之后，按照不同的鏡像格式生成容器啟動(dòng)的rootfs。

采用本方案啟動(dòng)容器時(shí)，首先DPU會(huì)通過(guò)NVMe/RDMA的方式連接遠(yuǎn)端存儲(chǔ)，實(shí)現(xiàn)高效的數(shù)據(jù)傳輸，然后通過(guò)NVMe PCIE的方式直通給host，最后host基于這個(gè)直通的disk生成rootfs并啟動(dòng)容器。由于云盤(pán)原生支持按需讀取的特性，本方案在容器啟動(dòng)過(guò)程中無(wú)需拉取鏡像，從而顯著加快容器的啟動(dòng)過(guò)程。

2.2.?方案描述

當(dāng)使用本方案啟動(dòng)容器時(shí)，首先需要進(jìn)行鏡像轉(zhuǎn)換，鏡像轉(zhuǎn)換的主要作用是將原始鏡像按照 Lvol（邏輯卷）的方式落地到存儲(chǔ)中，并將鏡像元數(shù)據(jù)推送至鏡像倉(cāng)庫(kù)，供容器啟動(dòng)時(shí)使用。

同時(shí)本方案在鏡像轉(zhuǎn)換時(shí)支持兩種鏡像格式y(tǒng)usur-overlayfs和yusur-overlaybd。yusur-overlayfs和原生的鏡像格式一樣，按照overlay的方式生成rootfs，主要用于兼容overlay的場(chǎng)景；yusur-overlaybd以塊設(shè)備的方式作為rootfs，原生支持可寫(xiě)層和理論上性能較overlayfs好。

2.2.1.?鏡像轉(zhuǎn)換

鏡像轉(zhuǎn)換主要責(zé)任是基于SPDK snapshot機(jī)制把原生鏡像按需轉(zhuǎn)換成以上兩種格式的鏡像，鏡像數(shù)據(jù)存到存儲(chǔ)，元數(shù)據(jù)存到鏡像倉(cāng)庫(kù)。鏡像轉(zhuǎn)換有兩種工作模式：普通模式和DPU模式。在DPU模式下，能利用DPU的加速能力，可以顯著加快鏡像轉(zhuǎn)換的速度。

普通模式的架構(gòu)如下圖所示，其組件主要包含image-ctrl，attacher service，opi-spdk-bridge和原生spdk。

紅色線條表示數(shù)據(jù)走向，job拉取原鏡像層數(shù)據(jù)，按不同鏡像格式寫(xiě)到nbd設(shè)備中。各個(gè)組件的作用如下：

• Image-ctrl，鏡像控制器：接收鏡像轉(zhuǎn)換yaml，創(chuàng)建轉(zhuǎn)換job。job負(fù)責(zé)創(chuàng)建塊存儲(chǔ)，調(diào)用attach service創(chuàng)建和克隆lvol，完成鏡像層數(shù)據(jù)寫(xiě)入lvol和推送轉(zhuǎn)換后鏡像元數(shù)據(jù)至倉(cāng)庫(kù)。
• Attacher service：對(duì)opi-bridge操作的抽象，對(duì)上提供opi-bridge的能力
• Opi-spdk-bridge：對(duì)接原生SPDK的opi-bridge，提供原生SPDK的基本操作
• SPDK：原生SPDK提供快照，克隆的能力

DPU模式的架構(gòu)如下圖所示，其組件主要包含image-ctrl，image-mgmt，attacher ，opi-bridge和DPU spdk。

紅色線條表示數(shù)據(jù)走向，job拉取原鏡像層數(shù)據(jù)，按不同鏡像格式寫(xiě)到NVMe disk中，各個(gè)組件的作用如下：

• Opi-bridge：提供不通DPU的存儲(chǔ)能力API
• SPDK：不同DPU的SPDK 服務(wù)，提供NVMe disk的模擬功能

2.2.2.?鏡像格式

使用兩種鏡像創(chuàng)建容器時(shí)，處理流程基本一致，差異在鏡像數(shù)據(jù)的組織方式和rootfs的組成方式，yusur-overlayfs鏡像格式如下所示。

如上圖所示，鏡像X:A完成鏡像轉(zhuǎn)換之后，生成數(shù)據(jù)A，鏡像X:B在轉(zhuǎn)換時(shí)直接使用這部分?jǐn)?shù)據(jù)，鏡像X:B其他數(shù)據(jù)基于克隆的lvol寫(xiě)入。共享數(shù)據(jù)可以包含一個(gè)或多個(gè)lvol，它們之間也是通過(guò)clone鏈接在一起。

yusur-overlaybd的鏡像格式如下圖所示，與yusur-overlayfs鏡像每層數(shù)據(jù)寫(xiě)到lvol不同目錄的方式不同，yusur-overlaybd的鏡像數(shù)據(jù)會(huì)直接寫(xiě)入lvol。

兩種鏡像格式的rootfs組成如下圖所示。

yusur-overlaybd以nbd設(shè)備作為rootfs，不用額外的可寫(xiě)層；而yusur-overlayfs是以塊設(shè)備中的多個(gè)目錄作為lowerdir，然后加一個(gè)可寫(xiě)層作為upperdir構(gòu)成rootfs。

2.2.3.?容器啟動(dòng)

容器啟動(dòng)流程請(qǐng)參考”整體架構(gòu)”章節(jié)。當(dāng)用轉(zhuǎn)換鏡像啟動(dòng)容器時(shí)，containerd會(huì)根據(jù)鏡像元數(shù)據(jù)生成一些labels，這些labels會(huì)作為參數(shù)傳遞給yusur-snapshotter，yusur-snapshotter會(huì)根據(jù)這些labels，創(chuàng)建不同的存儲(chǔ)target。

目前支持兩種形式的存儲(chǔ)target，本地AIO和遠(yuǎn)程N(yùn)VMe-OF，NVMe-OF同時(shí)又支持兩種連接方式NVMe/TCP和NVMe/RDMA。在容器啟動(dòng)過(guò)程中主要涉及以下組件yusur-snapshotter，image-mgmt service和attacher service，作用如下：

• Yusur-snapshotter：實(shí)現(xiàn)containerd的snapshotter接口，負(fù)責(zé)準(zhǔn)備容器啟動(dòng)的rootfs
• Image-mgmt service：和snapshotter交互，以AIO或NVMe-OF的方式創(chuàng)建和掛載塊設(shè)備。

3.?方案測(cè)試結(jié)果

3.1.?功能測(cè)試

3.1.1.?鏡像轉(zhuǎn)換

創(chuàng)建鏡像轉(zhuǎn)換CR之后，控制器就會(huì)創(chuàng)建job進(jìn)行鏡像轉(zhuǎn)換。以下是yusur-overlayfs和yusur-overlaybd轉(zhuǎn)換成功的截圖：

轉(zhuǎn)換成功之后，會(huì)更新CR status，blocks會(huì)包含目的鏡像對(duì)應(yīng)存儲(chǔ)的卷，多個(gè)卷之間是以clone的方式遞進(jìn)，以yusur-overlayfs為例，如下所示：

轉(zhuǎn)換成功之后，目的鏡像會(huì)推送至鏡像倉(cāng)庫(kù)，其作用是在容器啟動(dòng)時(shí)，提供存儲(chǔ)相關(guān)的元數(shù)據(jù)，如下所示：

Annotation中包含該層所在的塊設(shè)備，鏡像格式，文件系統(tǒng)等信息，這些信息會(huì)作為labels傳遞給yusur-snapshotter。

3.1.2.?Pod啟動(dòng)

pod啟動(dòng)之后，可以查看rootfs組成，如下所示：

Yusur-overlayfs:

overlayfs格式的鏡像，塊設(shè)備中包含鏡像的每一層數(shù)據(jù)，掛載后把相關(guān)層目錄，bind到對(duì)應(yīng)的snapshot，構(gòu)成overlay的lowerdir。

Yusur-overlaybd:

overlaybd格式的鏡像, 塊設(shè)備中包含鏡像的rootfs；沒(méi)有把塊設(shè)備直接作為容器啟動(dòng)的rootfs，考慮到還需要一個(gè)可寫(xiě)層，所以基于塊設(shè)備創(chuàng)建一個(gè)qcow2的本地文件，然后本地文件通過(guò)nbd暴露出來(lái)，作為容器啟動(dòng)的rootfs和可寫(xiě)層。

3.2.?性能測(cè)試

性能測(cè)試包括5種方案，本方案提供了其中的兩種yusur-overlayfs/NVMe/RDMA和yusur-overlaybd/NVMe/RDMA。yusur-overlayfs/NVMe/RDMA表示鏡像格式是yusur-overlayfs，存儲(chǔ)target是NVMe-OF，連接方式是RDMA；yusur-overlaybd/NVMe/RDMA同yusur-overlayfs，只是鏡像格式不同。

3.2.1.?Containerd下的容器啟動(dòng)耗時(shí)測(cè)試

我們將測(cè)試整個(gè)容器啟動(dòng)過(guò)程中的時(shí)間消耗，具體分為三個(gè)階段：鏡像拉取、容器創(chuàng)建和服務(wù)ready。

如上圖所示，縱坐標(biāo)表示容器ready時(shí)間（單位：秒），橫坐標(biāo)表示鏡像名稱(chēng)。由于此場(chǎng)景只是去掉了k8s的影響，結(jié)論同2.2.1, 如下：

• 本方案的yusur-overlayfs較overlayfs有63%的性能提升，因?yàn)椴挥美∷袛?shù)據(jù)到本地；
• 本方案的yusur-overlaybd較DADI overlaybd有34%的性能提升，是因?yàn)楸痉桨竔o路徑更短。

如上圖所示，可以得出如下結(jié)論：

• overlaybd鏡像拉取是最快的，因?yàn)閛verlaybd在這個(gè)過(guò)程中只生成TCMU的config文件；
• 本方案的兩種方法都較overlaybd慢，是因?yàn)楸痉桨冈阽R像拉取中需要掛載云盤(pán)。
• ?stargz也比overlaybd慢，是因?yàn)閟targz在鏡像拉取中需要掛載用戶(hù)態(tài)文件系統(tǒng)?

如上圖所示，可以得出如下結(jié)論：

• 由于 OverlayFS 的數(shù)據(jù)已經(jīng)在本地，因此 OverlayFS 的容器創(chuàng)建時(shí)間僅包括 runc 的操作以及啟動(dòng)命令的時(shí)間。
• 本方案的兩種方法中，容器創(chuàng)建時(shí)間較高，因?yàn)楸痉桨傅?rootfs 基于 DPU 提供的云盤(pán)，yusur-snapshoter 需要?jiǎng)?chuàng)建 NVMe 系統(tǒng)（前端）并執(zhí)行找盤(pán)操作。
• stargz 在 CentOS 上消耗的時(shí)間較多，是因?yàn)?stargz 需要預(yù)加載（在這里需要預(yù)拉取 80M 的數(shù)據(jù)，主要時(shí)間消耗在這里）。
• ?對(duì)于 overlaybd，由于其原理上與本方案基本相同，都是利用文件系統(tǒng)實(shí)現(xiàn)按需拉取，因此時(shí)間上基本差不多。

如上圖所示，可以得出如下結(jié)論：

• 容器gcc消耗時(shí)間基本沒(méi)有，是因?yàn)間cc啟動(dòng)命令只是執(zhí)行了gcc --version，這個(gè)在容器創(chuàng)建時(shí)，已經(jīng)就執(zhí)行完了
• OverlayFS 的耗時(shí)最短，因?yàn)樵阽R像拉取階段，鏡像數(shù)據(jù)已經(jīng)被下載并存儲(chǔ)在本地
• Stargz由于前一過(guò)程預(yù)拉取了部分?jǐn)?shù)據(jù)，所以總體時(shí)間上略高于OverlayFS。
• 本方案的 yusur-overlaybd 優(yōu)于 overlaybd，主要是因?yàn)樗诤笃跀?shù)據(jù)讀取方面表現(xiàn)更佳。與 overlaybd 需要通過(guò) TCMU 定位文件偏移量并使用 HTTP Range Request 向 registry 請(qǐng)求數(shù)據(jù)的方式不同，本方案直接通過(guò)內(nèi)核 VFS，并采用 NVMe/RDMA 的方式進(jìn)行數(shù)據(jù)傳輸，因而具有更低的延遲。
• 本方案的 yusur-overlayfs 相較于 stargz 和 overlayfs 表現(xiàn)稍遜，主要原因在于 overlayfs 的數(shù)據(jù)已存儲(chǔ)在本地，而 stargz 在容器啟動(dòng)前已完成熱點(diǎn)數(shù)據(jù)的預(yù)提取，而本方案則缺少數(shù)據(jù)預(yù)提取這一過(guò)程。

3.2.2.?鏡像轉(zhuǎn)換耗時(shí)測(cè)試

由于兩種鏡像格式相差不大，故采用 yusur-overlayfs 作為對(duì)比，測(cè)試結(jié)果如下所示：

如上圖所示，縱坐標(biāo)表示不同模式下鏡像轉(zhuǎn)換時(shí)間（單位：秒），橫坐標(biāo)表示鏡像名稱(chēng)?？梢缘贸鋈缦陆Y(jié)論：

• 基于DPU的鏡像轉(zhuǎn)換方案可以降低鏡像轉(zhuǎn)換的時(shí)間，但是效果不是太明顯。不明顯的原因是受制于后端存儲(chǔ)CEPH，導(dǎo)致RDMA發(fā)揮不出優(yōu)勢(shì)。

3.3.?資源消耗測(cè)試

3.3.1.?CPU消耗測(cè)試

stargz兩次測(cè)試結(jié)果：如圖所示，CPU最高使用率20.17%，平均使用率4.22%。

overlayfs兩次測(cè)試結(jié)果：如圖所示，CPU最高使用率14.77%，平均使用率2.78%。

overlaybd兩次測(cè)試結(jié)果：如圖所示，CPU最高使用率11.4%，平均使用率3.27%。

yusur-overlayfs兩次測(cè)試結(jié)果：如圖所示，CPU最高使用率7.66%，平均使用率1.95%。

yusur-overlaybd兩次測(cè)試結(jié)果：如圖所示，cpu最高使用率10.02%，平均使用率2.17%。

整體使用率較yusur-overlayfs高，從system使用率觀察可以得出是nbd這一層導(dǎo)致的。

匯總結(jié)果如下：

從以上所有圖片，得出如下結(jié)論：

• 本方案的最高CPU使用率最低;
• 本方案的cpu高利用率維持時(shí)間最短，只有30s左右。

3.3.2.?內(nèi)存消耗測(cè)試

stargz兩次測(cè)試結(jié)果：如圖所示，最高內(nèi)存使用7.67G，平均內(nèi)存使用6.86G。

overlayfs兩次測(cè)試結(jié)果：如圖所示，最高內(nèi)存使用5.71G，平均內(nèi)存使用5.16G。

overlaybd兩次測(cè)試結(jié)果：如圖所示，最高內(nèi)存使用5.21G，平均內(nèi)存使用4.94G。

yusur-overlayfs兩次測(cè)試結(jié)果：如圖所示，最高內(nèi)存使用5.28G，平均內(nèi)存使用4.87G。

yusur-overlaybd兩次測(cè)試結(jié)果：如圖所示，最高內(nèi)存使用5.62G，平均內(nèi)存使用5.01G。

匯總結(jié)果如下：

從以上所有圖片，得出如下結(jié)論：

• 本方案的消耗的內(nèi)存最低；
• 本方案的內(nèi)存高消耗維持時(shí)間最短，只有60s左右。

4.?總結(jié)

4.1.?測(cè)試結(jié)果總結(jié)

• 在 K8s 場(chǎng)景下，本方案的 yusur-overlayfs 相比于傳統(tǒng)方案 overlayfs，性能提升了 57%；而相比改進(jìn)方案 DADI，yusur-overlaybd 的性能也提升了 20%
• 在 Containerd 場(chǎng)景下，本方案的 yusur-overlayfs 相比傳統(tǒng)方案 overlayfs，性能提升了 63%；而 yusur-overlaybd 相較于改進(jìn)方案 DADI，性能也提升了 34%。
• 控制面和數(shù)據(jù)面下沉至 DPU，有效減少了主機(jī)資源的消耗。從測(cè)試結(jié)果來(lái)看，本方案的 CPU 和內(nèi)存占用率以及持續(xù)時(shí)間均為最低。
• 從鏡像cypress-chrome（624.2 MiB）、centos(1.3GiB)、tensorflow-notebook(1.7 GiB)的啟動(dòng)時(shí)間看，在本方案中，容器冷啟動(dòng)時(shí)間隨著鏡像大小的增加，其時(shí)間優(yōu)勢(shì)變得越加明顯。
• 從鏡像轉(zhuǎn)換的測(cè)試結(jié)果來(lái)看，鏡像越大，基于 DPU 的方案在時(shí)間上表現(xiàn)出越明顯的優(yōu)勢(shì)，因?yàn)樗軌蚶?DPU 的 RDMA 能力。類(lèi)推到容器啟動(dòng)過(guò)程中，所需的數(shù)據(jù)量越大，本方案的優(yōu)勢(shì)也會(huì)越加顯著。

4.2.?方案價(jià)值

基于DPU的容器冷啟動(dòng)加速解決方案具有如下價(jià)值：

1、提升服務(wù)響應(yīng)速度和用戶(hù)體驗(yàn)：在FaaS中，由于函數(shù)實(shí)例是動(dòng)態(tài)創(chuàng)建的，首次調(diào)用函數(shù)時(shí)可能會(huì)遇到冷啟動(dòng)延遲，即容器從停止?fàn)顟B(tài)到運(yùn)行狀態(tài)所需的時(shí)間?？焖倮鋯?dòng)技術(shù)能夠顯著縮短這一時(shí)間，使得用戶(hù)請(qǐng)求能夠更快地得到響應(yīng)，從而提升用戶(hù)體驗(yàn)。

2、提高業(yè)務(wù)吞吐量：快速冷啟動(dòng)使得FaaS平臺(tái)能夠在短時(shí)間內(nèi)啟動(dòng)更多的函數(shù)實(shí)例，以應(yīng)對(duì)突發(fā)的流量高峰，從而提高業(yè)務(wù)的整體吞吐量。

3、提高系統(tǒng)可用性：在微服務(wù)架構(gòu)和分布式系統(tǒng)中，服務(wù)的快速冷啟動(dòng)可以確保在服務(wù)實(shí)例故障時(shí)，能夠迅速恢復(fù)服務(wù)，減少服務(wù)中斷時(shí)間，提高系統(tǒng)的整體可用性。

4、提升資源利用效率：控制面和數(shù)據(jù)面下沉至 DPU，有效減少了主機(jī)資源的消耗，這意味著在實(shí)際應(yīng)用場(chǎng)景中，將大大節(jié)省了寶貴的CPU和內(nèi)存資源，讓這些資源能夠被應(yīng)用服務(wù)更高效地利用。

綜上所述，基于DPU的容器冷啟動(dòng)加速解決方案對(duì)于提升服務(wù)響應(yīng)速度和用戶(hù)體驗(yàn)、提高業(yè)務(wù)吞吐量、提高系統(tǒng)可用性、提升資源利用效率等方面都具有重要的價(jià)值和意義，隨著云原生和無(wú)服務(wù)器計(jì)算的不斷發(fā)展，該方案將具有廣闊的應(yīng)用前景。

本方案來(lái)自于中科馭數(shù)軟件研發(fā)團(tuán)隊(duì)，團(tuán)隊(duì)核心由一群在云計(jì)算、數(shù)據(jù)中心架構(gòu)、高性能計(jì)算領(lǐng)域深耕多年的業(yè)界資深架構(gòu)師和技術(shù)專(zhuān)家組成，不僅擁有豐富的實(shí)戰(zhàn)經(jīng)驗(yàn)，還對(duì)行業(yè)趨勢(shì)具備敏銳的洞察力，該團(tuán)隊(duì)致力于探索、設(shè)計(jì)、開(kāi)發(fā)、推廣可落地的高性能云計(jì)算解決方案，幫助最終客戶(hù)加速數(shù)字化轉(zhuǎn)型，提升業(yè)務(wù)效能，同時(shí)降低運(yùn)營(yíng)成本。