### Why we're leaving serverless | Unkey
---
## 1. 容易懂 (Easy Know)
想像一下你開了一間超快的披薩店，每一筆訂單都要立刻送到客人手上。一開始，你用的是「無伺服器」送貨方式，就像每次有訂單就叫一台全新的小型送貨車來。這些小車雖然很方便，但每次都要等車子來、裝披薩，而且它們記不住上次去哪裡送過貨，所以你得一直打電話給其他服務，問：「這個客人的地址是什麼？」這樣一來一回，披薩送得就沒那麼快了。後來，你決定換成一台超級大的專用送貨車，它有自己的導航和記憶體，能記住所有客人的資訊，而且一直都在店門口等著。這樣一來，送披薩的速度馬上快了6倍，而且管理起來也簡單多了，甚至你可以把這台車借給別人用！這就是這家公司把他們的網路服務從「小車車隊」換成「大專用車」的故事。
## 2. 總結 (Overall Summary)
Unkey 是一家提供 API 身份驗證服務的公司，其核心業務對延遲有極高要求，因為他們的 API 位於客戶應用程式的關鍵路徑上。文章詳細闡述了 Unkey 在採用 Cloudflare Workers 無伺服器架構兩年後，因面臨嚴峻的性能瓶頸與架構複雜性，最終決定徹底重建其 API 堆棧，轉而採用有狀態的 Go 伺服器。
最初選擇無伺服器模型時，Unkey 看中了其全球邊緣部署、自動擴展和按使用量付費的優勢。然而，隨著服務的發展，他們發現無伺服器架構的固有局限性成為了性能和營運效率的巨大障礙。最核心的問題在於快取：無伺服器函數每次調用之間沒有保證的持久記憶體，導致所有快取讀取都必須透過網路請求外部儲存，這為 API 引入了不可接受的延遲，即使是快取命中率高的 Cloudflare 內建快取也無法滿足其低於 10 毫秒的目標。
此外，無伺服器模型雖然承諾簡化營運，卻導致了嚴重的「SaaS 膠水問題」。為了解決無伺服器造成的「人工」問題（如快取、批次處理、即時功能），Unkey 不得不整合大量額外的 SaaS 產品（如 Redis、Cloudflare Durable Objects、Logstreams、Queues、Workflows），這不僅增加了系統的複雜性、成本、延遲，還引入了更多潛在的單點故障。數據管線也成了噩夢，由於函數可能隨時消失，每次調用都必須立即刷新事件，這迫使 Unkey 建立了一個高度複雜的分佈式事件處理系統來處理分析、指標和日誌。
為了解決這些問題，Unkey 決定在 V2 版本中將整個 API 重建為有狀態的 Go 伺服器。此舉立竿見影地簡化了架構，將分散式系統轉變為直接的應用程式，透過記憶體內批次處理消除了對多個輔助服務和複雜日誌管線的需求。性能方面，遷移後端到端延遲降低了 6 倍，極大地提升了用戶體驗。
除了顯著的性能提升，轉向有狀態伺服器還帶來了多項策略性優勢。其中最重要的是實現了平台獨立性，Unkey 不再被鎖定在 Cloudflare 生態系統中，可以在任何地方部署。同時，它也使得客戶能夠輕鬆自行託管 Unkey 服務，並顯著改善了內部開發者的體驗，簡化了本地開發、除錯和測試流程。儘管捨棄了無伺服器的大部分特性，Unkey 仍保留了全球邊緣部署（透過 AWS Global Accelerator）和自動擴展（透過 Fargate）等優勢。
文章強調，這並非全盤否定無伺服器，無伺服器對於不頻繁工作負載、簡單請求/回應模式和事件驅動架構仍是絕佳選擇。然而，當需要一致的低延遲、持久狀態、高頻率工作負載或精細控制時，無伺服器的「複雜性稅」——即為了解決平台限制而引入的額外複雜性——會變得異常高昂。Unkey 的經驗證明，有時最佳解決方案不是規避限制，而是選擇一個不同的基礎架構。未來，Unkey 計劃推出自己的部署平台「Unkey Deploy」，進一步實現服務的可移植性和可自行託管性。
## 3. 觀點 (Viewpoints)
* **無伺服器快取問題是性能瓶頸的核心：** 無伺服器架構缺乏函數調用間的持久記憶體，導致快取操作必須透過網路請求外部儲存。這引入了不可接受的延遲（如 p99 30ms+），使得建立低於 10 毫秒的 API 幾乎不可能，凸顯了「零網路請求永遠比一次網路請求快」的道理。
* **無伺服器創造「SaaS 膠水」問題，增加複雜性與成本：** 儘管無伺服器承諾簡化營運，但其無狀態特性迫使開發者整合多個額外的 SaaS 產品來彌補快取、批次處理等功能。這不僅增加了系統的複雜性、潛在故障點和營運成本，也使得開發者花費大量時間解決非業務價值的架構限制。
* **複雜的數據管線是無伺服器無狀態性的必然結果：** 無伺服器函數的生命週期不確定性，使得傳統伺服器中簡單的記憶體內事件批次處理變得不可能。為此，Unkey 必須建立一個複雜的分佈式事件處理系統來收集分析、指標和日誌，增加了架構的複雜度和脆弱性。
* **有狀態 Go 伺服器帶來顯著的性能提升與架構簡化：** 轉向有狀態 Go 伺服器後，Unkey 的 API 延遲降低了 6 倍。這主要得益於能夠實現簡單的記憶體內事件批次處理和快取，消除了對多個輔助服務和複雜管線的需求，將一個分散式系統轉變為直接的應用程式架構。
* **策略性優勢超越性能，實現平台獨立性與開發者體驗提升：** 除了速度，新架構還支援了客戶自行託管服務，並徹底改善了內部開發流程，使本地開發、除錯和測試變得極為容易。更重要的是，它解除了對 Cloudflare 生態系統的鎖定，實現了真正的平台獨立性。
* **「複雜性稅」是選擇不當架構的隱性成本：** 文章核心教訓指出，為了解決平台限制而投入的努力會產生巨大的「複雜性稅」。這包括建立複雜的快取庫、批次處理服務、日誌管線以及本地開發的變通方案，這些額外工作本質上是在彌補架構的不足，而非創造業務價值。
* **無伺服器仍有其適用場景，但需謹慎評估其限制：** Unkey 並非全盤否定無伺服器，它仍非常適合不頻繁、簡單請求/回應或事件驅動的工作負載。然而，對於需要一致低延遲、持久狀態、高頻率處理或精細控制的應用，無伺服器架構的限制可能會導致性能瓶頸和不必要的複雜性。
## 4. 摘要 (Abstract)
* ✅ Unkey從無伺服器架構（Cloudflare Workers）轉移至有狀態Go伺服器。
* 🚀 遷移後API端到端延遲降低6倍，性能顯著提升。
* ⚠️ 無伺服器架構的快取問題（無持久記憶體、需外部網路請求）是主要性能瓶頸。
* 🔗 無伺服器導致「SaaS 膠水」問題，需整合多個外部服務，增加複雜性與成本。
* 🛠️ 有狀態Go伺服器簡化了複雜的數據管線，實現了記憶體內批次處理。
* 💡 遷移帶來了可自行託管、提升開發者體驗及平台獨立性等策略優勢。
* 💰 無伺服器模型在需要持久狀態和高頻率工作負載時會產生高昂的「複雜性稅」。
* 🤔 無伺服器仍適用於不頻繁、簡單或事件驅動的工作負載，但需考量其限制。
## 5. 問題測驗 (FAQ)
**第一題**
Unkey 決定從無伺服器架構轉移到有狀態 Go 伺服器的主要原因是什麼？
A. Cloudflare Workers 不穩定，經常當機。
B. 無伺服器架構導致了不可接受的高延遲和營運複雜性。
C. 無伺服器架構的成本過高，遠超預期。
D. Go 語言是公司內部唯一支持的開發語言。
**正確答案：B**
**解釋：** 原文明確指出，無伺服器架構在快取問題上造成高延遲，且為了彌補無狀態性需要整合大量外部服務，導致「SaaS 膠水」問題和數據管線複雜化，這些都屬於性能和營運複雜性的範疇。
**第二題**
關於無伺服器快取問題，Unkey 遇到的關鍵挑戰是什麼？
A. Cloudflare 的快取服務命中率太低。
B. 快取讀取需要零網路請求才能滿足效能需求。
C. 無伺服器函數調用之間沒有保證的持久記憶體。
D. 無法使用 SWR（Stale-While-Revalidate）策略進行快取。
**正確答案：C**
**解釋：** 文章明確指出「The fundamental issue was caching. In serverless, you have no guaranteed persistent memory between function invocations. Every cache read requires a network request to an external store, and that's where things got painful。」這是導致高延遲的根本原因。
**第三題**
轉向有狀態 Go 伺服器後，Unkey 獲得了哪些重要的「策略性效益」？
A. 增加了對 Cloudflare 特定功能的依賴。
B. 大幅簡化了本地開發、實現了客戶自行託管和平台獨立性。
C. 必須重新設計所有數據管線，使其更加複雜。
D. 捨棄了全球邊緣部署和自動擴展能力。
**正確答案：B**
**解釋：** 文章在「Strategic Benefits Beyond Performance」部分詳細列舉了自託管、開發者體驗轉變和平台獨立性，這些都是轉向有狀態伺服器帶來的重大策略性優勢。同時也提到保留了全球邊緣部署和自動擴展。
---
**https://www.unkey.com/blog/serverless-exit**
**Summarized by 小濃縮David888.com**
- **Telegram**: [@quantaar_bot](https://t.me/quantaar_bot) | **Line**: [@032trcev](https://line.me/R/ti/p/@032trcev)
---
[Original Source](https://www.unkey.com/blog/serverless-exit)