熟悉的控制器與服務
控制器接收請求，服務處理業務。使用 Go 的結構體與方法區分各自的職責。
查看控制器寫法
Spine以熟悉的開發方式，
打造更快的伺服器。
沿用 NestJS 與 Spring 的控制器和服務結構來組織 Go 應用程式。使用建構函式注入與攔截器，並查看在相同資源下測得的吞吐量與記憶體用量。
跳至主要內容
相同資源，處理更多請求。
量測資料CSV
Shell
go install github.com/NARUBROWN/spine-cli/cmd/spine@v0.1.4
spine new hello-spine --module example.com/hello-spine
cd hello-spine
go mod tidy
spine contract check
spine verify
spine dev
使用 CLI 產生專案，驗證後再執行。完整步驟請參閱「第一個應用程式」。
使用 CLI 建立第一個應用程式相同資源，處理更多請求。
記憶體用量更少。
我們為NestJS/Express、Spring MVC和FastAPI/Uvicorn各分配3 vCPU和3GiB記憶體進行比較。
Spine 內部實驗室測試 / 2026.11.01
查看量測條件和完整結果163,559req/s
HTTP吞吐量
飽和負載下量測的中位數
41.8MiB
觀測記憶體用量
每秒2萬請求時的用量
1.062ms
p99回應延遲
每秒2萬請求時的延遲
相同CPU預算下處理的請求數
越高越好
假設每位使用者每秒請求一次
Spine0.5.2
163,559req/s
NestJS / Express
93,977req/s
如果使用Spine，還可多處理約69,582名使用者的請求。
Spring MVC
118,943req/s
如果使用Spine，還可多處理約44,616名使用者的請求。
FastAPI / Uvicorn
50,173req/s
如果使用Spine，還可多處理約113,386名使用者的請求。
256個並行連線下的飽和吞吐量。我們比較了各實作的實際吞吐量。
此範例按每位使用者每秒請求一次，將每秒吞吐量的差值換算為人數。實際可承載人數取決於請求頻率和應用程式執行的工作。