在 AWS Spot 實例上建置可擴充的 API

大家好! 我叫基里爾,是 Adapty 的技術長。 我們的大部分架構都在AWS上,今天我將討論如何透過在生產環境中使用現貨實例將伺服器成本降低3倍,以及如何設定其自動擴展。 首先將概述其工作原理,然後提供詳細的入門說明。

什麼是 Spot 實例?

實例是其他 AWS 用戶目前閒置的伺服器,他們以很大的折扣出售它們(亞馬遜的折扣高達 90%,根據我們的經驗約為 3 倍,具體取決於區域、可用區和實例類型)。 它們與普通的主要區別在於它們可以隨時關閉。 因此,很長一段時間我們認為,將它們用於原始環境,或用於計算某些內容的任務,中間結果保存在 S3 或資料庫中,這是正常的,但不用於銷售。 有第三方解決方案允許您在生產中使用點,但我們的案例有很多拐杖,因此我們沒有實施它們。 本文所述的方法完全在標準 AWS 功能內執行,無需額外的腳本、皇冠等。

以下是一些顯示現貨實例價格歷史記錄的螢幕截圖。

m5.large 位於 eu-west-1(愛爾蘭)區域。 價格近 3 個月基本穩定,目前節省 2.9 倍。

在 AWS Spot 實例上建置可擴充的 API

m5.large 位於 us-east-1 區域(維吉尼亞州北部)。 價格在 3 個月內不斷變化,目前可節省 2.3 倍到 2.8 倍,具體取決於可用區域。

在 AWS Spot 實例上建置可擴充的 API

t3.small 位於 us-east-1 區域(維吉尼亞州北部)。 價格已穩定 3 個月,目前節省 3.4 倍。

在 AWS Spot 實例上建置可擴充的 API

服務架構

我們將在本文中討論的服務的基本架構如下圖所示。

在 AWS Spot 實例上建置可擴充的 API

應用程式負載平衡器 → EC2 目標群組 → 彈性容器服務

應用程式負載平衡器 (ALB) 用作平衡器,它將請求傳送到 EC2 目標群組 (TG)。 TG 負責在 ALB 執行個體上開啟連接埠並將其連接到彈性容器服務 (ECS) 容器的連接埠。 ECS 類似於 AWS 中的 Kubernetes,管理 Docker 容器。

一個實例可以運行多個具有相同連接埠的容器,因此我們不能固定地設定它們。 ECS 告訴 TG 它正在啟動一個新任務(在 Kubernetes 術語中這稱為 pod),它檢查實例上的空閒連接埠並將其中一個分配給已啟動的任務。 TG 也會使用健康檢查定期檢查實例和 API 是否正在運行,如果發現任何問題,就會停止向那裡發送請求。

EC2 Auto Scaling 組 + ECS 容量提供商

上圖未顯示 EC2 Auto Scaling Groups (ASG) 服務。 從名字上就可以理解,它負責實例的伸縮。 然而,直到最近,AWS 還沒有內建的功能來管理 ECS 中正在運行的機器的數量。 ECS 可以擴展任務數量,例如透過 CPU 使用率、RAM 或請求數量。 但如果任務佔用了所有空閒實例,則不會自動建立新機器。

隨著 ECS 容量提供者 (ECS CP) 的出現,這種情況發生了變化。 現在,ECS 中的每個服務都可以與 ASG 關聯,如果任務不適合正在運行的實例,則會引發新任務(但在既定的 ASG 限制內)。 這也適用於相反的方向,如果 ECS CP 看到沒有任務的空閒實例,那麼它將向 ASG 命令關閉它們。 ECS CP 能夠指定實例負載的目標百分比,以便始終有一定數量的機器空閒用於快速擴展任務;稍後我會討論這一點。

EC2 啟動模板

在詳細介紹建立此基礎架構之前,我要討論的最後一項服務是 EC2 啟動範本。 它允許您創建一個模板,所有機器將根據該模板啟動,以免每次從頭開始重複。 在這裡您可以選擇要啟動的機器類型、安全性群組、磁碟映像和許多其他參數。 您也可以指定將上傳到所有已啟動實例的使用者資料。 您可以在使用者資料中執行腳本,例如,您可以編輯檔案的內容 ECS代理配置.

本文最重要的配置參數之一是 ECS_ENABLE_SPOT_INSTANCE_DRAINING=真實。 如果啟用此參數,那麼一旦 ECS 收到 Spot 實例正在被刪除的訊號,它就會將所有在該實例上執行的任務轉移到 Draining 狀態。 不會向該實例指派新任務;如果現在有任務想要部署到該實例,它們將被取消。 來自平衡器的請求也停止了。 實例刪除通知會在實際事件發生前 2 分鐘發出。 因此,如果您的服務執行任務的時間不超過 2 分鐘,並且沒有將任何內容保存到磁碟,那麼您可以使用競價實例而不會丟失資料。

關於磁碟 - AWS 最近 我有 可以將彈性檔案系統(EFS)與ECS一起使用;使用這種方案,即使磁碟也不是障礙,但我們沒有嘗試這樣做,因為原則上我們不需要磁碟來儲存狀態。 預設情況下,收到 SIGINT(當任務轉移到 Draining 狀態時發送)後,所有正在運行的任務將在 30 秒後停止,即使它們尚未完成;您可以使用參數更改此時間 ECS_CONTAINER_STOP_TIMEOUT。 主要是現貨機不要設定超過2分鐘。

創建服務

讓我們繼續創建所描述的服務。 在這個過程中,我會額外描述一些上面沒有提到的有用的點。 一般來說,這是一個逐步說明,但我不會考慮一些非常基本的情況,或者相反,非常具體的情況。 所有操作均在 AWS 視覺控制台中執行,但可以使用 CloudFormation 或 Terraform 以程式設計方式重現。 在 Adapty,我們使用 Terraform。

EC2 啟動模板

此服務建立將使用的機器的配置。 範本在 EC2 -> 執行個體 -> 啟動範本部分中進行管理。

亞馬遜機器映像 (AMI) — 指定將用於啟動所有執行個體的磁碟映像。 對於 ECS,在大多數情況下值得使用 Amazon 的最佳化鏡像。 它定期更新並包含 ECS 工作所需的一切。 若要尋找目前影像 ID,請前往頁面 Amazon ECS 優化的 AMI,選擇您正在使用的區域並複製其 AMI ID。 例如,對於 us-east-1 區域,寫入時的目前 ID 為 ami-00c7c1cf5bdc913ed。 必須將此 ID 插入指定自訂值項中。

實例類型 — 表示實例類型。 選擇最適合您任務的一項。

密鑰對(登錄) — 指定一個證書,您可以使用該證書透過 SSH 連線到實例(如有必要)。

網絡設置 — 指定網路參數。 網路平台 在大多數情況下,應該會有虛擬私有雲 (VPC)。 安全組 — 您的執行個體的安全群組。 由於我們將在實例前面使用平衡器,因此我建議在此處指定一個群組,僅允許來自平衡器的傳入連接。 也就是說,您將有2 個安全組,一個用於平衡器,允許來自端口80 (http) 和443 (https) 上任何位置的入站連接,第二個用於計算機,允許來自平衡器組的任何連接埠上的傳入連線。 必須使用 TCP 協定開啟兩個群組中所有連接埠到所有位址的出站連線。 您可以限制傳出連線的連接埠和位址,但是您需要不斷監視您是否沒有嘗試存取已關閉連接埠上的某些內容。

儲存(卷) — 指定機器的磁碟參數。 磁碟大小不能小於 AMI 中指定的大小;對於 ECS Optimized,磁碟大小為 30 GiB。

高級細節 — 指定附加參數。

購買選擇 — 我們是否要購買現貨實例。 我們想要,但我們不會在這裡選中此框;我們將在 Auto Scaling 組中配置它,那裡有更多選項。

IAM 實例設定檔 — 指示將啟動執行個體的角色。 為了讓實例在 ECS 中運行,它們需要權限,這些權限通常可以在角色中找到 ecs實例角色。 在某些情況下可以創建,如果沒有,那麼這裡 指令 關於如何做到這一點。 創建完成後,我們在模板中註明。
接下來有很多參數,基本上到處都可以保留預設值,但每個參數都有明確的說明。 我始終啟用 EBS 優化實例和 T2/T3 Unlimited 選項(如果使用) 可爆裂的 實例。

用戶時間 — 表示使用者資料。 我們將編輯該文件 /etc/ecs/ecs.config,其中包含 ECS 代理程式配置。
用戶資料的範例如下:

#!/bin/bash
echo ECS_CLUSTER=DemoApiClusterProd >> /etc/ecs/ecs.config
echo ECS_ENABLE_SPOT_INSTANCE_DRAINING=true >> /etc/ecs/ecs.config
echo ECS_CONTAINER_STOP_TIMEOUT=1m >> /etc/ecs/ecs.config
echo ECS_ENGINE_AUTH_TYPE=docker >> /etc/ecs/ecs.config
echo "ECS_ENGINE_AUTH_DATA={"registry.gitlab.com":{"username":"username","password":"password"}}" >> /etc/ecs/ecs.config

ECS_CLUSTER=DemoApiClusterProd — 此參數表示該實例屬於給定名稱的集群,即該集群將能夠將其任務放置在該伺服器上。 我們還沒有創建集群,但是我們在創建集群時會使用這個名稱。

ECS_ENABLE_SPOT_INSTANCE_DRAINING=true — 此參數指定當收到關閉 Spot 實例的訊號時,該實例上的所有任務都應轉為 Draining 狀態。

ECS_CONTAINER_STOP_TIMEOUT=1m - 此參數指定在收到SIGINT訊號後,所有任務在被殺死之前有1分鐘的時間。

ECS_ENGINE_AUTH_TYPE=docker --此參數表示採用Docker方案作為授權機制

ECS_ENGINE_AUTH_DATA=... — 儲存 Docker 映像的私有容器註冊表的連線參數。 如果它是公開的,那麼您不需要指定任何內容。

出於本文的目的,我將使用 Docker Hub 中的公共映像,因此請指定參數 ECS_ENGINE_AUTH_TYPE и ECS_ENGINE_AUTH_DATA 不需要。

很高興知道:建議定期更新AMI,因為新版本會更新Docker、Linux、ECS代理程式等的版本。為了不要忘記這一點,您可以 設定通知 關於新版本的發布。 您可以透過電子郵件接收通知並手動更新,也可以編寫一個 Lambda 函數,該函數將使用更新的 AMI 自動建立新版本的啟動範本。

EC2 Auto Scaling 組

Auto Scaling 群組負責啟動和擴充執行個體。 組在 EC2 -> Auto Scaling -> Auto Scaling Groups 部分中進行管理。

啟動模板 — 選擇上一個步驟所建立的範本。 我們保留預設版本。

購買選項和實例類型 — 指定叢集的實例類型。 堅持啟動模板使用啟動模板中的實例類型。 結合購買選項和實例類型,您可以靈活配置實例類型。 我們會用它。

可選的按需底座 — 始終有效的常規非 Spot 實例的數量。

高於基礎的按需百分比 — 普通實例和現貨實例的比例,平均分配50-50個,每個普通實例20-80個,增加4個現貨實例。 出於本範例的目的,我將指定 50-50,但實際上我們通常會指定 20-80,在某些情況下指定為 0-100。

實例類型 — 在這裡您可以指定將在叢集中使用的其他執行個體類型。 我們從來沒有使用過它,因為我不太明白這個故事的意思。 也許這是由於特定類型實例的限制,但可以透過支援輕鬆增加它們。 如果您知道該應用程序,我將很高興在評論中閱讀)

在 AWS Spot 實例上建置可擴充的 API

網絡 — 網路設置,為機器選擇 VPC 和子網,大多數情況下您應該選擇所有可用的子網路。

負載均衡 - 平衡器設置,但我們將單獨進行此操作,我們不會在這裡觸及任何內容。 健康檢查 稍後也會配置。

團體人數 — 我們在開始時指出集群中機器數量的限制以及所需的機器數量。 叢集中的機器數量永遠不會小於指定的最小值且不會大於最大值,即使根據指標進行擴展也是如此。

擴展政策 — 伸縮參數,但我們會根據正在執行的ECS任務進行伸縮,所以稍後我們會配置伸縮。

實例縮容保護 — 縮小規模時保護實例不被刪除。 我們啟用它,以便 ASG 不會刪除正在執行任務的機器。 ECS Capacity Provider 將停用對沒有任務的執行個體的保護。

添加標籤 — 您可以為實例指定標籤(為此,必須選取標記新實例複選框)。 我建議指定Name標籤,那麼群組內啟動的所有實例都將具有相同的名稱,並且可以輕鬆地在控制台中查看它們。

在 AWS Spot 實例上建置可擴充的 API

創建群組後,打開它並進入高級配置部分。為什麼在創建階段不是所有選項都在控制台中可見。

終止政策 — 刪除實例時考慮的規則。 它們按順序應用。 我們通常使用下圖中的那些。 首先,具有最舊啟動範本的執行個體將被刪除(例如,如果我們更新了 AMI,我們建立了一個新版本,但所有執行個體都設法切換到它)。 然後選擇最接近下一個計費時間的實例。 然後根據發布日期選擇最舊的。

在 AWS Spot 實例上建置可擴充的 API

很高興知道:更新叢集內所有機器,使用方便 實例刷新。 如果將此與上一個步驟中的 Lambda 函數結合起來,您將擁有一個完全自動化的實例更新系統。 在更新所有機器之前,您必須為群組內的所有執行個體停用實例縮容保護。 不是在群組中進行配置,而是對電腦本身進行保護,這是在「實例管理」標籤上完成的。

應用程式負載平衡器和 EC2 目標群組

平衡器在 EC2 → 負載平衡 → 負載平衡器部分中建立。 我們將使用應用程式負載平衡器;不同類型平衡器的比較可以閱讀: 服務頁面.

聽眾 - 稍後使用平衡器規則建立連接埠 80 和 443 並從 80 重定向到 443 是有意義的。

可用區 - 在大多數情況下,我們會為每個人選擇無障礙區域。

配置安全設置 — 此處顯示了平衡器的 SSL 證書,最方便的選項是 製作證書 在 ACM 中。 關於差異 隱私權政策 可以讀入 文件,您可以預設選擇它 ELBSecurityPolicy-2016-08。 創建平衡器後,您將看到它 DNS名稱,您需要為您的網域配置 CNAME。 例如,這就是它在 Cloudflare 中的樣子。

在 AWS Spot 實例上建置可擴充的 API

安全組 — 為平衡器建立或選擇安全群組,我在上面的 EC2 啟動範本 → 網路設定部分中寫了更多相關內容。

目標組 - 我們建立一個小組,負責將請求從平衡器路由到機器,並檢查它們的可用性,以便在出現問題時替換它們。 目標類型 必須是實例, 協議 и 港口 任何,如果平衡器和實例之間使用 HTTPS 進行通信,那麼您需要向它們上傳憑證。 出於本範例的目的,我們不會這樣做,我們將簡單地保留連接埠 80。

健康檢查 — 用於檢查服務功能的參數。 在實際服務中,這應該是一個單獨的請求,用於實現業務邏輯的重要部分;出於本範例的目的,我將保留預設設定。 接下來,您可以選擇請求間隔、逾時、成功程式碼等。在我們的範例中,我們將指示成功程式碼 200-399,因為將使用的 Docker 映像傳回 304 程式碼。

在 AWS Spot 實例上建置可擴充的 API

註冊目標 — 這裡選擇了該組的汽車,但在我們的例子中,這將由 ECS 完成,因此我們只需跳過此步驟。

很高興知道:在平衡器級別,您可以啟用將在特定時間內儲存在 S3 中的日誌 格式。 從那裡它們可以匯出到第三方服務進行分析,或者您可以直接對 S3 中的資料進行 SQL 查詢 使用雅典娜。 它很方便並且無需任何額外代碼即可工作。 我還建議設定在指定時間段後從 S3 儲存桶中刪除日誌。

ECS任務定義

在前面的步驟中,我們創建了與服務基礎架構相關的所有內容;現在我們繼續描述我們將啟動的容器。 這是在 ECS → 任務定義部分中完成的。

啟動類型相容性 - 選擇 EC2。

任務執行 IAM 角色 - 選擇 ecsTaskExecutionRole。 使用它,可以寫入日誌,提供對秘密變數的存取權限,等等。

在“容器定義”部分中,按一下“新增容器”。

圖片 — 連結到包含專案程式碼的映像;在本例中,我將使用 Docker Hub 中的公共映像 bitnami/節點範例:0.0.1.

內存限制 — 容器的記憶體限制。 硬限制 --硬限制,如果容器超出指定值,將執行dockerkill命令,容器將立即死亡。 軟限制 -- 軟限制,容器可以超出指定值,但在機器上放置任務時會考慮到該參數。 例如,如果一台機器有 4 GiB RAM,而容器的軟限制為 2048 MiB,則該機器最多可以有 2 個正在運行的任務。 實際上,4 GiB RAM 略小於 4096 MiB,這可以在叢集中的 ECS 實例標籤上查看。 軟限制不能大於硬限制。 重要的是要理解,如果一項任務中有多個容器,那麼它們的限制將被匯總。

連接埠映射 -在 主機端口 我們指示 0,這表示該連接埠將動態分配並由目標群組監控。 貨櫃港口 — 應用程式執行的連接埠通常在執行命令中指定,或在應用程式程式碼、Dockerfile 等中指定。 對於我們的範例,我們將使用 3000,因為它列在 Dockerfile 正在使用的圖像。

健康檢查 — 容器運作狀況檢查參數,不要與目標群組中配置的參數混淆。

環境 - 環境設定。 CPU單元 - 與記憶體限制類似,僅與處理器有關。 每個處理器核心為 1024 個單元,因此如果伺服器具有雙核心處理器且容器設定為 512,則可以在一台伺服器上啟動 4 個具有該容器的任務。 CPU 單元始終與核心數量相對應;核心數量不能少一點,記憶體也是如此。

命令 — 在容器內啟動服務的指令,所有參數均以逗號分隔指定。 這可能是gunicorn、npm 等。 如果未指定,將使用 Dockerfile 中的 CMD 指令的值。 我們表明 npm,start.

環境變量 — 容器環境變數。 這可以是簡單的文字資料或來自的秘密變量 秘密經理參數存儲.

儲存和日誌記錄 — 在這裡,我們將在 CloudWatch Logs(來自 AWS 的日誌服務)中設定日誌記錄。 為此,只需啟用自動配置 CloudWatch Logs 複選框即可。 建立任務定義後,CloudWatch 中會自動建立一組日誌。 預設情況下,日誌無限期地儲存在其中;我建議將保留期限從永不過期更改為所需的期限。 這是在 CloudWatch Log 群組中完成的,您需要點擊當前週期並選擇新週期。

在 AWS Spot 實例上建置可擴充的 API

ECS 叢集和 ECS 容量供應商

進入 ECS → 集群部分建立集群。 我們選擇 EC2 Linux + Networking 作為模板。

集群名稱 - 非常重要,我們在這裡使用與啟動範本參數中指定的名稱相同的名稱 ECS_CLUSTER,在我們的例子中 - DemoApiClusterProd。 選取建立空集群複選框。 或者,您可以啟用 Container Insights 以查看 CloudWatch 中服務的指標。 如果您正確執行了所有操作,那麼在 ECS 執行個體部分中,您將看到在 Auto Scaling 群組中建立的電腦。

在 AWS Spot 實例上建置可擴充的 API

轉到選項卡 產能供應商 並創建一個新的。 提醒一下,需要根據運行的ECS任務數量來控制機器的建立和關閉。 請務必注意,一名提供者只能分配給一個群組。

彈性伸縮組 — 選擇先前建立的群組。

託管縮放 — 啟用它以便提供者可以擴展服務。

目標容量% — 我們需要多少百分比的機器來載入任務。 如果指定 100%,則所有電腦將始終忙於執行任務。 如果您指定 50%,那麼一半的汽車將始終是免費的。 在這種情況下,如果負載急劇增加,新的計程車將立即到達空閒車輛,而無需等待執行個體部署。

託管終止保護 --enable,此參數允許提供者取消對實例的刪除保護。 當電腦上沒有活動任務且允許目標容量% 時,就會發生這種情況。

ECS 服務和擴充設定

最後一步:) 要建立服務,您需要在「服務」標籤上轉到先前建立的叢集。

發射類型 — 您需要按一下切換到容量提供者策略並選擇先前建立的提供者。

在 AWS Spot 實例上建置可擴充的 API

任務定義 — 選擇先前建立的任務定義及其修訂版本。

服務名稱 — 為了避免混淆,我們總是指示與任務定義相同的內容。

服務類型 - 始終是複製品。

任務數 — 服務中所需的活動任務數。 此參數由縮放控制,但仍必須指定。

最低健康百分比 и 最大百分比 — 確定部署期間任務的行為。 預設值是100和200,表示部署時任務數量會增加數倍,然後回到想要的值。 如果你有1個任務正在運行,min=0,max=100,那麼在部署過程中它將被殺死,之後會引發一個新的任務,即停機。 如果有 1 個任務正在運行,min=50,max=150,那麼部署根本不會發生,因為 1 個任務不能被分成兩半或增加一倍半。

部署類型 — 留下滾動更新。

展示位置模板 — 在機器上放置任務的規則。 預設是 AZ Balanced Spread - 這意味著每個新任務都將放置在新執行個體上,直到所有可用區中的機器都上升。 我們通常採用 BinPack - CPU 和 Spread - AZ;透過此策略,任務盡可能密集地放置在一台機器上的每個 CPU 上。 如果需要建立新機器,則在新的可用區中建立。

在 AWS Spot 實例上建置可擴充的 API

負載平衡器類型 — 選擇應用程式負載平衡器。

服務 IAM 角色 - 選擇 ecsServiceRole.

負載平衡器名稱 — 選擇先前建立的平衡器。

健康檢查寬限期 — 推出新任務後執行健康檢查之前暫停,我們通常將其設定為 60 秒。

容器到負載平衡 — 在「目標群組名稱」項目中,選擇先前建立的群組,所有內容都會自動填寫。

在 AWS Spot 實例上建置可擴充的 API

服務自動縮放 — 服務擴展參數。 選擇配置服務自動縮放以調整服務的所需數量。 我們在縮放時設定最小和最大任務數。

服務 Auto Scaling 的 IAM 角色 - 選擇 AWSServiceRoleForApplicationAutoScaling_ECSService.

自動任務擴展策略 — 縮放規則。 有2種類型:

  1. 目標跟踪 — 追蹤目標指標(CPU/RAM 使用情況或每個任務的請求數量)。 例如,我們希望平均處理器負載為85%,當它變得更高時,將新增新的任務,直到達到目標值。 如果負載較低,則任務將被刪除,反之,除非啟用了防止縮減的保護(禁用縮減).
  2. 步驟縮放 - 對任意事件的反應。 在這裡您可以設定對任何事件(CloudWatch Alarm)的反應,當事件發生時,您可以新增或刪除指定數量的任務,或指定確切的任務數量。

一個服務可能有多個擴展規則,這可能很有用,主要是確保它們不會相互衝突。

結論

如果您按照說明操作並使用相同的 Docker 映像,您的服務應該返回如下頁面。

在 AWS Spot 實例上建置可擴充的 API

  1. 我們建立了一個模板,根據該模板啟動服務中的所有機器。 我們還學習瞭如何在模板更改時更新機器。
  2. 我們已經配置了對 Spot 實例停止訊號的處理,因此在收到該訊號後的一分鐘內,所有正在執行的任務都會從機器中刪除,因此不會遺失或中斷任何內容。
  3. 我們升高了平衡器,將負載均勻地分配到機器上。
  4. 我們創建了一個在現貨實例上運行的服務,這將機器成本降低了大約 3 倍。
  5. 我們配置了雙向自動擴展,以處理增加的工作負載,而不會產生停機成本。
  6. 我們使用容量提供程序,以便應用程式管理基礎設施(機器),而不是相反。
  7. 我們很棒。

如果您的負載出現可預測的峰值,例如您在大型電子郵件行銷活動中投放廣告,則可以透過以下方式設定擴充功能: 時間表.

您也可以根據系統不同部分的資料進行擴充。 例如我們有這樣的功能 發送個人促銷優惠 行動應用程式的使用者。 有時,一個行銷活動會發送給 1 萬以上的人。 經過這樣的分配後,由於許多用戶同時登入應用程序,對 API 的請求總是會大幅增加。 因此,如果我們看到隊列中有明顯更多的標準指標用於發送促銷推播通知,我們可以立即啟動幾個額外的機器和任務來為負載做好準備。

如果您在評論中告訴我使用 Spot 實例和 ECS 的有趣案例或有關擴展的信息,我會很高興。

很快就會有文章介紹我們如何在主要無伺服器堆疊上(有錢)每秒處理數千個分析事件,以及如何使用 GitLab CI 和 Terraform Cloud 進行服務部署。

訂閱我們,這會很有趣!

只有註冊用戶才能參與調查。 登入, 請。

您在生產中使用現貨實例嗎?

  • 企業排放佔全球 22,2%是6

  • 企業排放佔全球 66,7%18號

  • 企業排放佔全球 11,1%我從一篇文章中了解了它們併計劃使用它們3

27 位用戶投票。 5 名用戶棄權。

來源: www.habr.com

添加評論