跳至主要內容

解決方案Web 應用程式與 API

任何應用程式,有人呼叫才醒來

任何容器映像檔,都有自己的網址。請求一停就休眠,3.5 毫秒內醒來,閒置的時間不用 CPU。

閱讀方塊文件

Shell
# any image; waits until it is ready, then prints its address
glac deploy ghcr.io/acme/api:1.4 --name api --port 8080
glac cube versions api       # every deploy is a version
glac cube rollback api       # back to the version before
glac cube logs api -f        # its log, a line per request
glac compose up              # a Cube for each Compose service

沒人呼叫,卻照樣付費

一直開著的伺服器,一個月的每個小時都要付錢。換成方塊,執行個體有請求才醒來,請求停了就休眠,CPU 只按實際運算的毫秒計費。

這些請求一個月用掉的量1
2.1億 CPU 毫秒
一個 vCPU 整月開著,要付費的量1
26.3億 CPU 毫秒

版本,以及隨請求醒來的執行個體

每次部署都是一個版本,它的執行個體從範本啟動,而範本裡的服務已經在執行。請求會在它進來的區域喚醒一個執行個體;請求停了它就休眠,一小時沒用就刪除。

一個應用程式:它的版本、就緒版本的範本,以及它在各區域的執行個體,有請求時喚醒,請求結束後休眠。

你的應用程式能得到什麼

  • 一個指令:版本就緒後,glac deploy 會印出網址。

  • 醒來時狀態都在:記憶體中的快取、連線池和工作階段都還在。

  • 版本與回復:準備好後流量才切換過去,一次呼叫就能切回來。

  • 按區域擴展:執行個體隨請求啟動,最多到你的上限。

  • HTTP/3、gRPC 和 WebSocket,使用你自己的網域和它的憑證。

  • Compose、背景服務和作業:每個服務一個方塊,作業會執行到結束。

閱讀文件

示意預覽

實測,而非承諾

在沒有其他負載的裸機上測得的中位數:這是最佳情況,我們也明白標示。方塊的執行個體與沙箱是同一種,這些數字就是在沙箱上測得的。 我們如何測量

喚醒休眠中的執行個體2
3.5 毫秒
喚醒它的那次呼叫,從送出到回應2
6.7 毫秒
讓它連同記憶體和行程一起休眠2
2.3 毫秒

服務開放後,你可以在自己的應用程式上看到這個數字:喚醒執行個體的請求,在日誌中的那一行會註明喚醒花了多久。

Shell
glac cube logs api -f
# one line a request; one that woke an instance says how long it took

用到的產品

一個月的費用試算

定價頁試算的第一個應用程式,按定價計算。 估算你自己的用量

使用情境

  • 每月 1000萬 個請求,隨機到達,都在同一個區域。
  • 每個請求 20 毫秒 CPU,使用 256 MiB 記憶體,每個回應 10 KB。
  • 執行個體規格為 2 vCPU,沒有另外指定時應用程式就是這個規格。在這樣的流量下,它在請求結束後等 1.2 秒才休眠,之後在記憶體中暫停 10 分鐘。

按定價計算的一個月

$6.90

  • CPU2億 CPU 毫秒 × $0.01 / 百萬$2.06
  • 記憶體180 GiB 小時 × $0.008$1.44
  • 請求1000萬 × $0.30 / 百萬$3.00
  • 傳出流量100 GB × $0.004$0.40

改用付費版,這個月是 $6.46:月費 $5,加上超出內含額度的 $1.46,按同樣的價格從餘額扣除。

部署你的第一個應用程式

取得金鑰,然後對任何映像檔執行一個指令。版本就緒後,它會印出網址。

方塊命令列