UserJot 的建立和運作完全是我一個人的事。沒有團隊，沒有承包商，就我一個人。
UserJot是一款針對 SaaS 公司的回饋、路線圖和更新日誌工具。它幫助產品團隊收集用戶回饋、建立公開的路線圖，並讓用戶了解最新進展。其基礎設施需要處理龐大的流量。僅在 8 月份，我們就有 52,000 名用戶存取了該平台，反饋小部件在客戶網站上加載，並且有數千個後台作業正在處理中。
這是我經過數月的迭代後得出的設定。
設定
我有三個前端，全部部署在 Cloudflare Workers 上：
-
Astro用於行銷頁面、部落格和文件（大部分是靜態的，使用最少的 JavaScript）
-
TanStack Start用於儀表板（伺服器呈現，然後成為 SPA）
-
TanStack Start用於公共回饋板（相同方法）
為什麼選擇 TanStack Start？它汲取了 Remix 的優秀理念，並進一步發展。 Next.js 的功能和抽象化太多，顯得臃腫不堪。 TanStack Start 更簡潔，更容易預測。
一個後端集群：
-
Hetzner 上的 Docker Swarm（美國東部）
-
Node.js 與 TypeScript
-
PostgreSQL
-
Caddy 用於反向代理
這就是整個基礎設施。部署透過 GitHub Actions 進行，它執行 CI/CD 並部署到 Docker Swarm。簡單、無趣，但有效。
為什麼沒有 Redis
PostgreSQL 處理一切：
-
使用 pg-boss 的作業佇列
-
JSONB 表中的鍵值存儲
-
使用 LISTEN/NOTIFY 進行發布/訂閱
-
使用 pg-vector 進行向量搜尋以尋找重複回饋
-
會話存儲
-
速率限制
pg-boss 在作業佇列方面表現非常穩定。它每天處理數千個作業：電子郵件推播、通知觸發器、資料同步。由於它是基於 PostgreSQL 建置，因此與專用佇列系統相比，它存在一些限制，但在實際應用中這些限制並不大。
Redis 能做得更好嗎？或許吧。但是管理一個資料庫比管理兩個資料庫簡單得多。當你獨自一人時，每增加一個服務都可能帶來問題。
更重要的是，每個依賴項都會直接影響您的正常運作時間。兩項服務意味著可能故障的次數翻倍。需要監控的內容也翻倍。需要備份的內容也翻倍。需要升級的內容也翻倍。您的可用性取決於最薄弱的服務。每項新服務都可能在凌晨 2 點出現故障。
當然，在某些時候我可能需要 Redis 來做快取。或用 RabbitMQ 來處理複雜的佇列模式。或用 Kafka 來做事件流。但這還很遙遠。說實話？我並不期待加入這些依賴項。
單一區域，全球用戶
後端在一個位置執行：美國東部。
有三個因素使得這項措施在全球得以實施：
-
Cloudflare Argo透過其網路路由流量來減少延遲
-
使用者介面的樂觀更新使操作感覺即時
-
在用戶點擊之前預先載入資料
前端在 Cloudflare 的邊緣呈現，因此使用者可以從附近的位置取得 HTML，同時從後端載入資料。
無伺服器在何處發揮作用
我使用無伺服器作為前端，因為它們是無狀態的。它們只渲染 HTML 和代理 API 呼叫。沒有持久連接，沒有後台任務，也不需要管理狀態。
但後端是傳統的伺服器。 PostgreSQL 需要連接池。作業佇列需要長時間執行的進程。即時功能需要 WebSocket 連線。無伺服器在這些方面並不擅長。
這種拆分效果很好：
-
前端在邊緣自動擴展
-
後端在專用伺服器上可預測地執行
自託管的利弊
我自己託管了 PostgreSQL 和後端叢集。這比使用託管服務需要更多工作，但我得到了：
-
完全控制 PostgreSQL 擴充和配置
-
能夠執行 pg-boss、pg-vector 和其他工具
-
可預測的成本不會隨著使用量而擴大
-
不受供應商鎖定
缺點：我自己負責備份、更新和監控。如果你更重視時間而不是掌控權，託管服務可能會更好。
當這有意義時
此架構在以下情況下效果良好：
-
你是一個人或一個小團隊
-
你想擁有自己的基礎設施
-
您熟悉 PostgreSQL 和 Docker
-
您不需要多區域資料複製
-
您的功能不需要複雜的即時同步
如果出現以下情況，這可能沒有意義：
-
您有一個需要託管服務的大型團隊
-
您需要真正的多區域存在
-
您不擅長管理伺服器
-
您需要針對特定功能的專用資料庫
我學到了什麼
PostgreSQL 的功能遠遠超越你的想像。作業佇列、快取、發布/訂閱。它都能很好地處理這些功能。你可能還不需要 Redis 實例。
無狀態前端簡化一切。當您的邊緣工作器只需進行渲染和代理時，無需擔心分佈式狀態。
單區域對於大多數 SaaS 應用來說已經足夠了。有了良好的快取和優化的 UI 更新，用戶不會注意到你的伺服器是否在遠處。
枯燥的技術也能發揮作用。 Docker Swarm 不像 Kubernetes 那樣花哨，但它更簡單，而且能完成工作。
超額配置你的伺服器。虛擬機器價格便宜。擁有 4 倍所需容量意味著你無需在流量高峰期考慮擴展。為了省心，每月多花 50 美元絕對值得。
維護的現實
最困難的部分是初始設定。理解所有元件如何組合在一起需要時間和經驗。但一旦執行起來呢？我每個月大概會花2-3個小時在基礎建設。
其他一切都是建立功能並與用戶交談。
前進
這種規模會永遠擴大嗎？不會，但它的規模會比大多數人想像的要大得多。
人們嚴重低估了單一 PostgreSQL 實例的處理能力。現代硬體性能極為強大。您可以垂直擴展到擁有數百個核心和 TB 級 RAM 的機器。在適當的硬體上，PostgreSQL 每秒可以處理數百萬次查詢。
這套配置可以輕鬆處理數十萬甚至數百萬的活躍用戶，這取決於你的使用模式。這或許就是我所需要的一切。
目前，甚至在未來幾年，PostgreSQL 和一個簡單的架構就足夠了。我正在開發新功能，與用戶溝通，並發展業務。基礎設施已經夠好了。
如果你對 UserJot 有興趣，請造訪UserJot 。我很樂意與你討論基礎設施決策。你可以在Twitter/X 上找到我。
原文出處：https://dev.to/shayy/my-saas-infrastructure-as-a-solo-founder-2ghl
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
