壓縮算法怎么在構(gòu)建部署中的優(yōu)化

本篇內(nèi)容主要講解“壓縮算法怎么在構(gòu)建部署中的優(yōu)化”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“壓縮算法怎么在構(gòu)建部署中的優(yōu)化”吧!

背景

通常而言，服務(wù)發(fā)布平臺的構(gòu)建部署的流程（鏡像部署除外）會經(jīng)過構(gòu)建（同步代碼 -> 編譯 -> 打包 -> 上傳）、部署（下載包 -> 解壓到目標(biāo)機(jī)器 -> 重啟服務(wù)）等步驟。以美團(tuán)內(nèi)部的發(fā)布平臺 Plus 為例，最近我們發(fā)現(xiàn)一些發(fā)布項(xiàng)在構(gòu)建產(chǎn)物打包壓縮的過程中耗時比較久。如下圖所示的 pack 步驟，一共消耗了1分23秒。

而在平常為用戶解答運(yùn)維問題的時候我們也發(fā)現(xiàn)，很多用戶會習(xí)慣將一些較大的機(jī)器學(xué)習(xí)或者 NLP 相關(guān)的數(shù)據(jù)放入到倉庫中，這部分?jǐn)?shù)據(jù)往往占據(jù)幾百兆，甚至占據(jù)幾個GB的磁盤空間，十分影響打包的速度。 Java 項(xiàng)目也是如此，由于 Java 服務(wù)框架繁多，依賴也多，通常這些服務(wù)打包后也要占據(jù)百兆級別的空間，耗時也會達(dá)到十多秒。下圖是我們的 pack 步驟的中位數(shù)，基本上大部分的 Java 服務(wù)和 Node.js 服務(wù)都至少要消耗 13s 左右的時間來做壓縮打包 。

pack 作為幾乎所有需要部署的服務(wù)必需步驟，它目前的耗時基本上僅低于編譯和構(gòu)建鏡像，因此，為了提高整體構(gòu)建的效率，我們準(zhǔn)備對 pack 打包壓縮的步驟進(jìn)行一輪優(yōu)化工作。

方案對比

準(zhǔn)備場景數(shù)據(jù)

發(fā)布項(xiàng)的包大小分析

為了盡可能地模擬構(gòu)建部署中的應(yīng)用場景，我們將 2020 年的部分構(gòu)建包數(shù)據(jù)進(jìn)行了整理分析，其中壓縮后的包大小如下圖所示，鐘形曲線說明了整體的包體積呈正態(tài)分布，并且有著較明顯的長尾效應(yīng)。壓縮后體積主要在 200M 以內(nèi)，壓縮前的大小大致在 516.0MB 以內(nèi)。

而 99%的服務(wù)壓縮包大小會在 1GB 以內(nèi)，而對于壓縮步驟而言，其實(shí)越大的項(xiàng)目耗時越明顯，優(yōu)化的空間越大。因此，我們在針對性的方案對比測試中選擇了 1GB 左右的構(gòu)建包進(jìn)行壓縮測試，既能覆蓋 99% 的場景，也可以看出壓縮算法之間比較明顯的提升。

這樣選擇的主要原因如下：

1. 數(shù)據(jù)大的情況下計(jì)算結(jié)果會比小數(shù)據(jù)誤差小很多。

2. 能夠覆蓋絕大多數(shù)應(yīng)用場景。

3. 效果對比明顯，可以看到是否有明顯的提升。

備注：由于在相同壓縮庫相同壓縮比等配置的情況下，Compression Speed 并沒有明顯變化，因此沒有做其它包體積的批量測試和數(shù)據(jù)匯總。

本文中我們使用的測試項(xiàng)目為美團(tuán)內(nèi)部的較大型的 C++ 項(xiàng)目，其中文件類型除去 C++、Python、Shell 代碼文件，還有 NLP、工具等二進(jìn)制數(shù)據(jù)（不包括 .git 中存儲的提交數(shù)據(jù)），數(shù)據(jù)類型比較全面。

目錄大小為 1.2G，也可以比較清晰地對比出不同方案之間的差距。

gzip

gzip 是基于 DEFLATE 的算法，它是 LZ77 和 Huffman 編碼 的結(jié)合。DEFLATE 的目的是為了取代 LZW 和其他受專利保護(hù)的數(shù)據(jù)壓縮算法，因?yàn)檫@些算法在當(dāng)時限制了壓縮和其他流行的存檔器的可用性（Wikipedia）。

我們通常使用 tar -czf 命令來進(jìn)行打包并且壓縮的操作，z 參數(shù)正是使用 gzip 的方式來進(jìn)行壓縮。DEFLATE 標(biāo)準(zhǔn)（RFC1951）是一個被廣泛使用的無損數(shù)據(jù)壓縮標(biāo)準(zhǔn)。它的壓縮數(shù)據(jù)格式由一系列塊構(gòu)成，對應(yīng)輸入數(shù)據(jù)的塊，每一塊通過 LZ77 （基于字典壓縮，就是將最高概率出現(xiàn)的字母以最短的編碼表示）算法和 Huffman 編碼進(jìn)行壓縮，LZ77 算法通過查找并替換重復(fù)的字符串來減小數(shù)據(jù)體積。

文件格式

• 一個 10 字節(jié)的報(bào)頭，包含一個魔數(shù) (1f 8b)，壓縮方法 （比如 08 用于 DEFLATE），1 字節(jié)的 header flags，4 字節(jié)的時間戳，compression flags 和操作系統(tǒng) ID。

• 可選的額外 headers，包括原始文件名、注釋字段、“extra” 字段和 header 的 CRC-32 校驗(yàn)碼 lower half 。

• DEFLATE 壓縮主體。

• 8 字節(jié)的 footer，包含 CRC-32校驗(yàn)以及原始未壓縮的數(shù)據(jù)。

我們可以看到 gzip 是主要基于 CRC 和 Huffman LZ77 的 DEFLATE 算法，這也是后面 ISA-L 庫的優(yōu)化目標(biāo)。

Brotli

Alakuijala 和 Szabadka 在 2013-2016 年完成了 Brotli 規(guī)范，該數(shù)據(jù)格式旨在進(jìn)一步提高壓縮比，它在優(yōu)化網(wǎng)站速度上有大量應(yīng)用。Brotli 規(guī)范的正式驗(yàn)證是由 Mark Adler 獨(dú)立實(shí)現(xiàn)的。Brotli 是一個用于數(shù)據(jù)流壓縮的數(shù)據(jù)格式規(guī)范，它使用了通用的 LZ77 無損壓縮算法、Huffman 編碼和二階上下文建模（2nd order context modelling）的特定組合。大家可以參考這篇論文查看其實(shí)現(xiàn)原理。

因?yàn)檎Z言本身的特性，基于上下文的建模方法 （Context Modeling）可以得到更好的壓縮比，但由于它的性能問題很難普及。當(dāng)前比較流行的突破算法有兩種：

• ANS：Zstd, lzfse

• Context Modeling：Brotli, bz2

具體測試數(shù)據(jù)見下文。

Zstd

Zstd 全稱叫 Zstandard，是一個提供高壓縮比的快速壓縮算法，主要實(shí)現(xiàn)的編程語言為 C，是 Facebook 的 Yann Collet 于2016年發(fā)布的，Zstd 采用了有限狀態(tài)熵（Finite State Entropy，縮寫為FSE）編碼器。該編碼器是由Jarek Duda 基于ANS 理論開發(fā)的一種新型熵編碼器，提供了非常強(qiáng)大的壓縮速度/壓縮率的折中方案（事實(shí)上也的確做到了“魚”和“熊掌”兼得）。Zstd 在其最大壓縮級別上提供的壓縮比接近 lzma、lzham 和 ppmx，并且性能優(yōu)于 lza 或 bzip2。Zstandard 達(dá)到了 Pareto frontier（資源分配最佳的理想狀態(tài)），因?yàn)樗鈮嚎s速度快于任何其他當(dāng)前可用的算法，但壓縮比類似或更好。

對于小數(shù)據(jù)，它還特別提供一個載入預(yù)置詞典的方法優(yōu)化速度，詞典可以通過對目標(biāo)數(shù)據(jù)進(jìn)行訓(xùn)練從而生成。

官方 Benchmark 數(shù)據(jù)對比

壓縮級別可以通過 --fast 指定，提供更快的壓縮和解壓縮速度，相比級別 1 會導(dǎo)致壓縮比率的一些損失，如上表所示。Zstd 可以用壓縮速度換取更強(qiáng)的壓縮比。它是可配置的小增量，在所有設(shè)置下，解壓縮速度都保持不變，這是大多數(shù) LZ 壓縮算法（如 zlib 或 lzma）共享的特性。

• 我們采用 Zstd 默認(rèn)的參數(shù)進(jìn)行了測試，壓縮時間 8.471s 僅為原來的 11.266%，提升了 88.733%。

• 解壓時間 3.211 僅為原來的 29.83%，提升約為 70.169%。

• 同時壓縮率也從 2.548 提升到了 2.621。

LZ4

LZ4是一種無損壓縮算法，每核提供大于 500 MB/s的壓縮速度（大于0.15 Bytes/cycle）。它的特點(diǎn)是解碼速度極快，每核速度為多 GB/s（ 約1 Bytes/cycle ）。

從上面的 Zstd 的 Benchmark 對比中，我們看到了 LZ4 算法效果十分出眾，因此我們也對 LZ4 進(jìn)行了對比，LZ4 更加側(cè)重壓縮解壓速度，尤其是解壓縮的速度，壓縮比并不是它的強(qiáng)項(xiàng)，它默認(rèn)支持 1-9 的壓縮參數(shù)，我們分別進(jìn)行了測試。

LZ4 使用默認(rèn)參數(shù)壓縮速度十分優(yōu)秀，比 Zstd 快很多，但是壓縮比并不高，比 Zstd 壓縮后多了 206 MB，足足多了 46%，這就意味著更多的數(shù)據(jù)傳輸時間和磁盤空間占用。即使是最大的壓縮比也并不高，僅僅從 1.79 提升到了 2.11，但是耗時卻從 5s 提升到了 51s。通過對比，LZ4 的確在壓縮率上并不是最優(yōu)秀的方案，在 2.x 級別壓縮率上基本上時間優(yōu)勢蕩然無存，而且還有一點(diǎn)，就是 LZ4 目前官方并沒有對多核 CPU 并行壓縮的支持，所以在后續(xù)的對比中，LZ4 喪失了壓縮解壓縮速度的優(yōu)勢。

Pigz

Pigz 的作者 Mark Adler，同時也是 Info-ZIP 的 zip 和 unzip、GNU 的 gzip 和 zlib 壓縮庫的共同作者，并且是 PNG 圖像格式開發(fā)工作的參與者。

Pigz 是 gzip 的并行實(shí)現(xiàn)的縮寫，它主要思想就是利用多個處理器和核。它將輸入分成 128 KB 的塊，每個塊都被并行壓縮。每個塊的單個校驗(yàn)值也是并行計(jì)算的。它的實(shí)現(xiàn)直接使用了 zlib 和 pthread 庫，比較易讀，而且重要的是兼容 gzip 的格式。Pigz 使用一個線程（主線程）進(jìn)行解壓縮，但可以創(chuàng)建另外三個線程進(jìn)行讀、寫和檢查計(jì)算，所以在某些情況下可以加速解壓縮。

一些博客在 i7 4790K 這樣的家用 PC 平臺中測試 Pigz 的壓縮性能時，并沒有十分高的速度，但在我們真機(jī)驗(yàn)證的數(shù)據(jù)中提升要明顯很多。通過測試，它的壓縮時間執(zhí)行速度只用了 1.768s，充分發(fā)揮了我們平臺物理機(jī)的性能，User 時間（CPU 時間之和）一共使用了 1m30.569s，這和前面的使用 gzip 單線程的方式速度幾乎是一個級別。壓縮率 2.5488 和正常使用 tar -czf 幾乎相差不多。

ISA-L Acceleration Version

ISA-L 是一套在 IA 架構(gòu)上加速算法執(zhí)行的開源函數(shù)庫，目的在于解決存儲系統(tǒng)的計(jì)算需求。 ISA-L 使用的是 BSD-3-Clause License ，因此在商業(yè)上同樣可以使用。

使用過 SPDK（Storage Performance Development Kit ）或者 DPDK（Data Plane Development Kit）應(yīng)該也聽說過 ISA-L ，前者使用了 ISA-L 的 CRC 部分，后者使用了它的壓縮優(yōu)化。ISA-L 通過使用高效的 SIMD （Single Instruction, Multiple Data）指令和專用指令，最大化的利用 CPU 的微架構(gòu)來加速存儲算法的計(jì)算過程。ISA-L底層函數(shù)都是使用手工匯編代碼編寫，并在很多細(xì)節(jié)上做了調(diào)優(yōu)（現(xiàn)在經(jīng)常要考慮 ARM 平臺，本文中所提及的部分指令在該平臺支持度不高甚至是不支持）。

ISA-L 對壓縮算法主要做了 CRC、DEFLATE 和 Huffman 編碼的優(yōu)化實(shí)現(xiàn)，官方的數(shù)據(jù)指出 ISA-L 相比 zlib-1 有 5 倍的速度提升。

舉例來說，不少底層的存儲開源軟件實(shí)現(xiàn)的 CRC 都使用了查表法，代碼中存儲或者生成了一個 CRC value 的表格，然后計(jì)算過程中查詢值，ISA-L 的匯編代碼中包含了無進(jìn)位乘法指令 PCLMULQDQ 對兩個64位數(shù)做無進(jìn)位乘法，最大化 intel PCLMULQDQ 指令的吞吐量來優(yōu)化 CRC 的性能。更好的情況是 CPU 支持 AVX-512，就可以使用 VPCLMULQDQ（PCLMULQDQ 在 EVEX 編碼的 512 bit 版本實(shí)現(xiàn)）等其它優(yōu)化指令集（查看是否支持的方式見“附錄”）。

備注：截圖來自 crc32_ieee_by16_10.asm

使用

ISA-L 實(shí)現(xiàn)的壓縮優(yōu)化級別支持 [0,3]，3 為壓縮比最大的版本，綜合考慮我們采用了最大的壓縮比，雖然壓縮比 2.346 略低于 gzip 不過影響不大。在 2019 年 6 月發(fā)布的 v2.27 版本里，ISA-L 加了多線程的 Feature，因此在后續(xù)的測試中，我們采用了多線程并發(fā)的參數(shù)，效果提升比較顯著。

由于我們構(gòu)建機(jī)器的系統(tǒng)為 Centos7 需要自行編譯 ISA-L 的依賴，比如 nasm 等庫，所以在安裝配置上會比較復(fù)雜，ISA-L 支持多種優(yōu)化參數(shù)比如，IGZIP_HIST_SIZE（壓縮過程中加大滑動窗口），LONGER_HUFFTABLES，更大的 Huffman 編碼表，這些編譯參數(shù)也會對庫有很大提升。

壓縮時間

real  0m1.372s
user  0m5.512s
sys 0m1.791s

測試后的效果相當(dāng)驚人，是目前對比方案中最為快速的，時間上節(jié)省了 98.09%。

由于和 gzip 格式兼容，因此同樣可以使用 tar -xf 命令進(jìn)行解壓，后續(xù)的解壓縮測試過程中，我們使用的仍然是 ISA-L 提供的解壓方式。

Pzstd

通過 Pigz 的測試，我們就在想，是否 Zstd 這樣優(yōu)秀的算法也可以支持并行呢，在官方的 Repo 中，我們十分驚喜地發(fā)現(xiàn)了一個“寶藏”。

Pzstd 是 C++11 實(shí)現(xiàn)的并行版本的 Zstandard （Zstd 也在這之后加入了多線程的支持），類似于 Pigz 的工具。 它提供了與 Zstandard 格式兼容的壓縮和解壓縮功能，可以利用多個 CPU 核心。 它將輸入分成相等大小的塊，并將每個塊獨(dú)立壓縮為 Zstandard 幀。 然后將這些幀連接在一起以產(chǎn)生最終的壓縮輸出。 Pzstd 同樣支持文件的并行解壓縮。 解壓縮使用 Zstandard 壓縮的文件時，PZstandard 在一個線程中執(zhí)行 IO，而在另一個線程中進(jìn)行解壓縮。

下圖是和 Pigz 的壓縮和解壓縮速度對比，來自官方 Github 倉庫（機(jī)器配置為：Intel Core i7 @ 3.1 GHz, 4 threads），效果比 Pigz 還要出色，具體對比數(shù)據(jù)見下文：

Pied Piper (Middle-out compression)

Middle-out Compression 最初是在美劇中提到的一個概念，不過現(xiàn)在已經(jīng)有了一個真正的實(shí)現(xiàn) middle-out，該算法目前小范圍應(yīng)用在壓縮時序數(shù)據(jù)中，由于缺乏成熟地理論支撐以及數(shù)據(jù)對比，沒有正式進(jìn)入方案的對標(biāo)。

備注：Pied Piper 是美劇《硅谷》 中虛擬出來的公司和算法。

兼容性

本文中調(diào)研所提及的對比方案，都是統(tǒng)一在構(gòu)建集群中的機(jī)器中進(jìn)行測試，由于構(gòu)建系統(tǒng) 在線上的機(jī)器集群配置高度統(tǒng)一（包括硬件平臺和系統(tǒng)版本），所以兼容性表現(xiàn)和測試數(shù)據(jù)也高度吻合。

選型

實(shí)際上，部分官方的測試機(jī)器的配置和美團(tuán)構(gòu)建平臺的物理機(jī)配置并不一致，場景可能也有區(qū)別，上面引用的測試結(jié)果中所使用的CPU以及平臺架構(gòu)和編譯環(huán)境和我們所用的也有些出入，而且大多數(shù)還是家用的硬件比如 i7-4790K 或者 i9-9900K，這也是需要使用構(gòu)建平臺的物理機(jī)和具體的構(gòu)建包壓縮場景來進(jìn)行測試的原因，因?yàn)檫@樣才能得出最接近我們使用場景的數(shù)據(jù)。

對比數(shù)據(jù)

幾個方案的數(shù)據(jù)對比如下表格（在本文中的時間數(shù)據(jù)選擇是通過多次運(yùn)行后，選擇結(jié)果的中位數(shù)）：

壓縮時間對比

從整個構(gòu)建后的壓縮構(gòu)建包的時間可視化圖中可以看出，最初版本的 gzip 壓縮相當(dāng)耗時，而采取 Pzstd 是最快速的方案，ISA-L 稍慢，Pigz 略微慢一點(diǎn)，這三者都可以達(dá)到從 1m11s 到 1s 左右的優(yōu)化，最快可以節(jié)省 98.51% 的壓縮時間。

解壓縮時間對比

解壓縮的時間上并沒有像壓縮效率相差很多，在 GB 級別的項(xiàng)目中壓縮比 2.5-2.6 范圍內(nèi)時，時間都在 11s 以內(nèi)。而且為了最大兼容已有的實(shí)現(xiàn)和保持穩(wěn)定性，解壓方案優(yōu)先考慮兼容 gzip 格式的策略，這樣對部署目標(biāo)機(jī)器的侵入性最小，即可以使用 tar -xf 解壓的方案優(yōu)先。

而在后面的方案實(shí)施中，由于部署需要穩(wěn)定可靠的環(huán)境，所以我們暫時沒有對部署機(jī)器做環(huán)境改造。

下面的時間對比是分別使用各自的解壓方案的對比：

• Pzstd 解壓速度最快，相比 Gzip 節(jié)省了 86.241% 的時間。

• Zstd 算法的解壓縮效率其次，大約可以節(jié)省 70.169% 的解壓時間。

• ISA-L 可節(jié)省 61.9658% 的時間。

• Pigz 可節(jié)省 43.357% 的解壓時間。

• Brotli 解壓可以節(jié)省 29.02% 的時間。

壓縮比的對比

壓縮比的對比中 Zstd 和 Pzstd 有一些優(yōu)勢，其中 Brotli 和 LZ4 由于支持的參數(shù)限制，比較難測試同級別壓縮比下的速度，因此選擇了壓縮比稍低的參數(shù)，但是效率仍然距離 Pigz 和 Pzstd 存在一些差距。

而 ISA-L 的實(shí)現(xiàn)在壓縮比上有一些犧牲，不過并沒有差距很大。

優(yōu)劣分析總結(jié)

在本文開始階段，我們介紹了構(gòu)建部署流程，因此我們此次優(yōu)化的目標(biāo)時間大致計(jì)算公式如下：

在測試案例對比中，時間耗時的順序?yàn)?Pzstd < ISA-L < Pigz < LZ4 < Zstd < Brotli < Gzip （排名越靠前越好），其中壓縮和解壓縮的時間在整體的耗時上占比較大，因此備選策略為 Pzstd、ISA-L、Pigz。

當(dāng)然，這其中還存在磁盤空間的成本優(yōu)化問題，即壓縮比可能對磁盤空間產(chǎn)生優(yōu)化，但是對構(gòu)建的耗時會產(chǎn)生負(fù)優(yōu)化，不過由于目前時間維度是我們優(yōu)化的主要目標(biāo)，比磁盤成本和上傳帶寬成本要重要，因此壓縮比采用了較為普遍或者默認(rèn)最優(yōu)的壓縮比方案，即在 2.3 - 2.6 范圍內(nèi)。不過在一些內(nèi)存型數(shù)據(jù)庫等存儲介質(zhì)成本較為高的場景中，也許要綜合多個方面需要更多考量，請大家知悉。

評分策略

比較于 gzip，新算法都具有想當(dāng)不錯的速度，但是由于壓縮格式的向前不兼容，加上需要客戶端（部署目標(biāo)機(jī)器）的支持，可能方案實(shí)施周期會較長。

而對于部署來說，可能收益并不是十分明顯，反而加重了一些維護(hù)和運(yùn)維成本，所以我們暫時沒有把 Pzstd 的方案放到較高的優(yōu)先級。

選型的策略主要有基于如下原則：

• 整體耗時優(yōu)化提升最大，這也是整體優(yōu)化方案的出發(fā)點(diǎn)。

• 保證最大兼容性，為了讓接入構(gòu)建平臺的業(yè)務(wù)和平臺減少改動成本，需要保持方案的兼容性（優(yōu)先考慮最大兼容的策略，即兼容 gzip 的方案優(yōu)先）。

• 保證部署目標(biāo)機(jī)器環(huán)境的穩(wěn)定和可靠，選擇對部署機(jī)器侵入最小的方案，這樣無需安裝客戶端或者庫。

• 壓縮場景在真機(jī)模擬測試中完全契合美團(tuán)構(gòu)建平臺的場景，即在我們現(xiàn)有的物理機(jī)平臺和目標(biāo)壓縮場景中對比數(shù)據(jù)效果良好。

• 其實(shí)本問題更全面的評分角度有很多維度，比如對象存儲的磁盤成本、帶寬成本、任務(wù)耗時，甚至是機(jī)器成本，不過為了簡化整體方案的選型，我們省略了一些計(jì)算，同時壓縮比的對比選擇上也選擇了各自官方推薦的范圍。

綜合以上幾點(diǎn)，決定一期采取 ISA-L 的方式加速，可以最穩(wěn)定并且較高速地提升構(gòu)建平臺的效率，未來可能會實(shí)現(xiàn) Pzstd 的方案，下面的數(shù)據(jù)為一期的結(jié)果。

優(yōu)化效果

為了方便結(jié)果的展示，我們過濾出了部分打包時間較長的發(fā)布項(xiàng)展示出來（這些耗時很久的項(xiàng)目往往十分影響用戶的使用體驗(yàn)，而且總體的占比在 10% 左右），這部分任務(wù)優(yōu)化的時間從 27s 到 72s 不等，過去越是項(xiàng)目大的項(xiàng)目壓縮時間越長，如今壓縮時間都可以穩(wěn)定在 10s 以內(nèi)，而且是在我們的機(jī)器同時執(zhí)行多個任務(wù)的情況下。

而后我們將優(yōu)化前的 Pack 步驟（壓縮+上傳）部分打點(diǎn)數(shù)據(jù)，以及優(yōu)化后的部分打點(diǎn)數(shù)據(jù)做了匯總，得出了平均的優(yōu)化效果對比，數(shù)據(jù)如下：

1. 在我們之前的一個構(gòu)建包的統(tǒng)計(jì)中，多數(shù)的構(gòu)建包壓縮后在 100MB 左右，壓縮前大概是在 250MB，按照 gzip 算法的壓縮速度的確會在 10s 左右的級別。

2. 由于構(gòu)建的物理機(jī)可能同時運(yùn)行多個任務(wù)，所以實(shí)際壓縮效果會比測試中稍微耗時多一點(diǎn)。

壓縮平均節(jié)省了 90% 的時間。

到此，相信大家對“壓縮算法怎么在構(gòu)建部署中的優(yōu)化”有了更深的了解，不妨來實(shí)際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！