1.方案背景

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

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

然而，F(xiàn)aaS模式也并非沒有缺陷，其中最為人詬病的便是“冷啟動(dòng)”問題。所謂冷啟動(dòng)，是指當(dā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)請求，這顯然效率更高。因此，冷啟動(dòng)過程常常導(dǎo)致較高的延遲，進(jìn)而影響應(yīng)用的性能。

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

1.2.1 傳統(tǒng)方案

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

過多的時(shí)間花費(fèi)在拉取鏡像上。

拉取了過多無關(guān)的數(shù)據(jù)。

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

提取單個(gè)文件時(shí)，需要掃描整個(gè)layer。

同一層多個(gè)文件的提取不支持并行處理。

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

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

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

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

stargz架構(gòu)圖

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

DADI(Data Accelerator for Disaggregated Infrastructure)是阿里云針對容器加速的解決方案，DADI 的核心組件是 Overlaybd，這是一種基于塊設(shè)備的鏡像格式，提供了在block-based layer之上的一個(gè)合并視圖，然后通過TCMU在Host上產(chǎn)生一個(gè)SCSI設(shè)備作為rootfs。TCMU（Target Core Module In Userspace），是scsi target的用戶態(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ù)訪問則是由tcmu按需獲取，并且加入了本地緩存和ZFile加速數(shù)據(jù)的讀取。

1.2.3 問題總結(jié)

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

傳統(tǒng)OverlayFS容器的冷啟動(dòng)時(shí)間較長，這可能會(huì)對性能敏感的應(yīng)用造成影響，導(dǎo)致較差的用戶體驗(yàn)。

改進(jìn)方案中的用戶態(tài)文件系統(tǒng)需要占用一定的主機(jī)資源，這可能會(huì)對系統(tǒng)的整體性能產(chǎn)生影響。

2.方案介紹

2.1.整體架構(gòu)

為了解決上述問題，我們構(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)，即可看到對應(yīng)的NVMe disk。

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

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

2.2.方案描述

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

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

2.2.1.鏡像轉(zhuǎn)換

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

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

紅色線條表示數(shù)據(jù)走向，job拉取原鏡像層數(shù)據(jù)，按不同鏡像格式寫到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ù)寫入lvol和推送轉(zhuǎn)換后鏡像元數(shù)據(jù)至倉庫。

Attacher service：對opi-bridge操作的抽象，對上提供opi-bridge的能力

Opi-spdk-bridge：對接原生SPDK的opi-bridge，提供原生SPDK的基本操作

SPDK：原生SPDK提供快照，克隆的能力

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

紅色線條表示數(shù)據(jù)走向，job拉取原鏡像層數(shù)據(jù)，按不同鏡像格式寫到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寫入。共享數(shù)據(jù)可以包含一個(gè)或多個(gè)lvol，它們之間也是通過clone鏈接在一起。

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

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

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

2.2.3.容器啟動(dòng)

容器啟動(dò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)過程中主要涉及以下組件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.方案測試結(jié)果

3.1.功能測試

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ì)包含目的鏡像對應(yīng)存儲(chǔ)的卷，多個(gè)卷之間是以clone的方式遞進(jìn)，以yusur-overlayfs為例，如下所示：

轉(zhuǎn)換成功之后，目的鏡像會(huì)推送至鏡像倉庫，其作用是在容器啟動(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到對應(yīng)的snapshot，構(gòu)成overlay的lowerdir。

Yusur-overlaybd:

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

3.2.性能測試

性能測試包括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í)測試

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

如上圖所示，縱坐標(biāo)表示容器ready時(shí)間（單位：秒），橫坐標(biāo)表示鏡像名稱。由于此場景只是去掉了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è)過程中只生成TCMU的config文件；

本方案的兩種方法都較overlaybd慢，是因?yàn)楸痉桨冈阽R像拉取中需要掛載云盤。

stargz也比overlaybd慢，是因?yàn)閟targz在鏡像拉取中需要掛載用戶態(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 提供的云盤，yusur-snapshoter 需要?jiǎng)?chuàng)建 NVMe 系統(tǒng)（前端）并執(zhí)行找盤操作。

stargz 在 CentOS 上消耗的時(shí)間較多，是因?yàn)?stargz 需要預(yù)加載（在這里需要預(yù)拉取 80M 的數(shù)據(jù)，主要時(shí)間消耗在這里）。

對于 overlaybd，由于其原理上與本方案基本相同，都是利用文件系統(tǒng)實(shí)現(xiàn)按需拉取，因此時(shí)間上基本差不多。

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

容器gcc消耗時(shí)間基本沒有，是因?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由于前一過程預(yù)拉取了部分?jǐn)?shù)據(jù)，所以總體時(shí)間上略高于OverlayFS。

本方案的 yusur-overlaybd 優(yōu)于 overlaybd，主要是因?yàn)樗诤笃跀?shù)據(jù)讀取方面表現(xiàn)更佳。與 overlaybd 需要通過 TCMU 定位文件偏移量并使用 HTTP Range Request 向 registry 請求數(shù)據(jù)的方式不同，本方案直接通過內(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ù)提取這一過程。

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

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

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

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

3.3.資源消耗測試

3.3.1.CPU消耗測試

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

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

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

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

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

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

匯總結(jié)果如下：

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

本方案的最高CPU使用率最低;

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

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

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

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

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

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

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

匯總結(jié)果如下：

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

本方案的消耗的內(nèi)存最低；

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

4.總結(jié)

4.1.測試結(jié)果總結(jié)

在 K8s 場景下，本方案的 yusur-overlayfs 相比于傳統(tǒng)方案 overlayfs，性能提升了 57%；而相比改進(jìn)方案 DADI，yusur-overlaybd 的性能也提升了 20%

在 Containerd 場景下，本方案的 yusur-overlayfs 相比傳統(tǒng)方案 overlayfs，性能提升了 63%；而 yusur-overlaybd 相較于改進(jìn)方案 DADI，性能也提升了 34%。

控制面和數(shù)據(jù)面下沉至 DPU，有效減少了主機(jī)資源的消耗。從測試結(jié)果來看，本方案的 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)勢變得越加明顯。

從鏡像轉(zhuǎn)換的測試結(jié)果來看，鏡像越大，基于 DPU 的方案在時(shí)間上表現(xiàn)出越明顯的優(yōu)勢，因?yàn)樗軌蚶?DPU 的 RDMA 能力。類推到容器啟動(dòng)過程中，所需的數(shù)據(jù)量越大，本方案的優(yōu)勢也會(huì)越加顯著。

4.2.方案價(jià)值

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

1、提升服務(wù)響應(yīng)速度和用戶體驗(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í)間，使得用戶請求能夠更快地得到響應(yīng)，從而提升用戶體驗(yàn)。

2、提高業(yè)務(wù)吞吐量：快速冷啟動(dòng)使得FaaS平臺(tái)能夠在短時(shí)間內(nèi)啟動(dòng)更多的函數(shù)實(shí)例，以應(yīng)對突發(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)用場景中，將大大節(jié)省了寶貴的CPU和內(nèi)存資源，讓這些資源能夠被應(yīng)用服務(wù)更高效地利用。

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

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

審核編輯 黃宇