Growth App 知识库

Growth App 基础设施架构

12分钟阅读

Growth App 基础设施架构

当前版本：v0.1　|　状态：🟢 进行中　|　最后更新：2026-07-13

🧭 TL;DR：现在我们在做什么

一句话总结

把应用从”一台 VPS 上的 Docker 容器”拆成三层——控制层（Cloudflare 边缘节点）、计算层（DePIN 去中心化算力，Akash Network / io.net）、数据层（DBaaS + Hyperdrive）——每层用最便宜且最合适的基础设施。目标：非 Frappe Press 应用做到 0 VPS，Frappe Press 从 3-4 台减到 1 台。

架构已确认，下一步：注册 Akash（$100 免费额度），拿一个开源应用验证全链路。

👉 现在轮到我做什么

下一步行动

  • 注册 Akash Network 账号（有 $100 免费额度），跑通第一个测试部署
  • 研究 Akash SDL 部署格式（不用 Docker Compose，需要翻译现有配置）
  • 研究 Cloudflare 和 Akash 节点之间的 VPC/内网打通方案
  • 拿一个简单开源应用（Outline 或 n8n）跑通完整链路：CF Container → Akash → Hyperdrive → DBaaS

Bob 说这个方向足够做 1-2 周。每天发一次进度同步。

🌱 背景与契机

旧架构的痛点：

  • 每套 Frappe Press 需要 3-4 台 VPS，每行业独立部署，成本 2000-3000/月
  • 扩容靠手动加机器，RAM 不够、出网费、单点故障都要自己搞
  • 传统云厂商（AWS/GCP）靠流量费和算力溢价”躺赚”，不符合主权个人路线

触发契机：

  • Bob 2026-07-13 连续 34 封邮件 + 1 次语音通话，和 AI 深入探讨”能不能用 Cloudflare + DePIN 替代 VPS”
  • 从”Frappe Press 能不能减配”一路推到”非 Frappe 应用能不能 0 VPS”
  • 核心洞察：Cloudflare（速度+安全+连接） + DePIN（主权+降本） + DBaaS（方便+合规）= 完整替代方案

要达成的目标：

  • Frappe Press：3-4 台 VPS → 1 台 VPS（Bench 强状态暂无法替代）
  • 非 Frappe 应用：做到 0 VPS
  • 算力成本降低 70-95%（GPU 走 Akash Network 竞价市场）

🏗️ 核心架构

flowchart TB
    User["👤 用户 / Agent"]

    User -->|"HTTPS"| L1

    subgraph L1["控制层 · Cloudflare 边缘网络"]
        direction LR
        A1["Workers（API网关·认证·调度）"]
        A2["Queue · R2 · D1"]
        A3["Tunnel · Hyperdrive"]
    end

    L1 -->|"Tunnel 加密隧道"| L2

    subgraph L2["计算层 · DePIN 去中心化算力"]
        direction LR
        B1["Akash Network（K8s·CPU/GPU）"]
        B2["io.net（GPU 集群）"]
        B3["无状态容器（推理·转码·爬虫）"]
    end

    L2 -->|"Hyperdrive 连接池"| L3

    subgraph L3["数据层 · DBaaS"]
        direction LR
        C1["PostgreSQL + Patroni（主从复制）"]
        C2["MySQL / MariaDB"]
    end

三层解耦：用户请求经 CF 边缘节点路由，无状态计算调度到 DePIN，持久化数据走 Hyperdrive 写入数据库。

🔍 架构分层拆解

  • Cloudflare 控制层：前端和 API 网关放在 CF 全球 330+ 边缘节点上，用户就近访问。Workers 做认证和调度，Queue 缓冲异步任务，Tunnel 打通 DePIN 加密通道，Hyperdrive 维持数据库长连接池。CF 是 Web2 和 Web3 之间的”连接云”——自己不生产算力，但连接一切。

  • DePIN 计算层：所有无状态 Docker 容器跑在 Akash Network / io.net 的去中心化算力上。Akash 负责通用 K8s 编排（CPU/GPU 并重），io.net 专注 GPU 集群（在线率更高但更贵，适合模型训练）。节点不稳定是设计前提——靠编排器检测离线 → 自动在新节点拉起容器（self-healing）。部署格式是 SDL，不是 Docker Compose。GPU 比 AWS 便宜 70-95%，CPU 任务如果追求稳定低价可走 Hetzner VPS。

  • 数据库层：PostgreSQL + Patroni 做主从流复制高可用，通过 Hyperdrive 连接池接入 CF 网络。数据库 I/O 延迟要求极高，物理存储仍在单 Provider 本地 NVMe 上（不是分布式卷），去中心化靠应用层 Patroni 跨国流复制实现，而非物理层。Hyperdrive 目前专为 CF Workers 设计，不直接暴露给外部容器——需要 Workers 做数据库网关桥接。

  • Web3 三件套（Bob 7/13 语音明确）：DePIN（去中心化算力）+ IPFS（去中心化存储）+ 智能合约（去中心化交易/信任）。Cloudflare 已内置 IPFS 网关和以太坊网关（Dashboard → Web3），开箱即用。这套组合让应用既是 Web2（快、商业可用），又是 Web3（主权、AI 可自主交易）。Bob 称之为 Web2.5。

🗳️ 关键决策记录

只增不减的表格，旧决策不删除，被推翻的标状态即可。

版本决策点选了什么为什么不选另一个状态
v0.1计算层选型Akash Network（通用 K8s）+ io.net（GPU 专用）纯 VPS 成本高且被厂商锁定✅ 进行中
v0.1CPU 稳定负载Hetzner VPS（4核/16G ~5-10欧/月）Akash CPU（$15-30/月）反而不划算✅ 进行中
v0.1数据库连接Hyperdrive（CF Workers 做数据库网关）自建 PgBouncer 需自己维护连接池；Hyperdrive 是 Workers 绑定，不能直接被 VPS/DePIN 容器调用✅ 进行中
v0.1数据库高可用PostgreSQL + Patroni 应用层流复制去中心化分布式卷 I/O 延迟太高，跨全球同步数据库会崩✅ 进行中
v0.1DePIN → CF 连接CF Tunnel（容器启动时主动打通）CF 主动连 DePIN 不可行——节点无固定 IP✅ 进行中
v0.1VPS 保留范围仅 Frappe Press Bench（有状态）+ 三个边角场景全面消灭 VPS 不现实，Frappe 依赖本地文件系统✅ 进行中
v0.1io.net vs Akashio.net 用于模型训练（GPU 密集），Akash 用于通用部署io.net 在线率更高但更贵，按场景分轨✅ 进行中
v0.1Web3 存储层IPFS（通过 CF Web3 Gateway 接入）Arweave（永久存储但更贵）CF 已内置 IPFS 网关，开箱即用

📈 演化记录

版本变化的唯一记录位置，最新的排最上面。

日期版本变化触发/来源改动摘要
2026-07-13创建 v0.1Bob 34 封邮件 + 语音通话确立三层架构：CF 控制层 + DePIN 计算层 + DBaaS 数据层；明确 Web3 三件套（DePIN + IPFS + 智能合约）；确认 Akash Network 有 $100 免费额度可供验证

💰 成本估算

当前预估（待实际验证）：

层方案月费估算
控制层CF Workers/Containers 免费层 + Paid 按需$0-20
计算层（GPU）Akash Network 竞价比 AWS 便宜 70-95%
计算层（CPU 稳定）Hetzner VPS~5-10 欧/月
数据层Neon/Supabase 免费层 或 Hetzner 自管$0-10
单项目总计~$10-50/月

规模效应（Bob 7/13）：单项目 2000-3000/月。DePIN + CF 的架构在规模上体现真正的成本优势。

🛣️ 迁移路径

当前（v0.1）                  过渡期                       终极形态
   │                            │                            │
   ▼                            ▼                            ▼
全部跑在 VPS 上          非 Frappe 应用先迁            非 Frappe → 0 [[VPS]]
3台 DO Droplet          到 CF+[[DePIN]] 验证           [[Frappe Press]] → 1 VPS
                         Frappe Press 保持 VPS          （Bench 强状态待攻克）
  1. 先拿一个简单应用（Outline / n8n）验证 CF + Akash Network + Hyperdrive + DBaaS 全链路
  2. 验证通过后，逐步把 gottenergy 的非 Frappe 工具迁到新架构
  3. Frappe Press 的 Bench 因强状态依赖本地文件系统，短期保留 VPS，远期研究无状态化改造
  4. SolarFlow 新部署直接从零走新架构

🪨 已知风险 / 硬骨头

目前明确知道但还没解决的难点：

  • 冷启动延迟：DePIN 节点离线 → Akash K8s 检测 → 新节点拉镜像 → 容器启动，几十秒到几分钟。不适合实时性要求极高的场景
  • DePIN CPU 不一定比 Hetzner 便宜：GPU 赛道 DePIN 碾压，但 CPU 赛道 Hetzner（4核/16G ~5-10欧/月）常比 Akash CPU（$15-30/月）更便宜。需要按任务类型分轨，不能一刀切全丢 DePIN
  • 数据库卷不是去中心化的：Akash Network 的持久卷跑在单个 Provider 的本地 NVMe 上，物理层仍是中心化的。去中心化靠应用层 Patroni 流复制，不是物理层。邮件 29-30 明确说”不要在硬件/存储层搞跨国去中心化卷”
  • Hyperdrive 不能直接被外部容器调用：Hyperdrive 是 CF Workers 的绑定功能，独立 VPS 或 DePIN 容器无法直接使用。需要 Workers 做数据库网关桥接（邮件 13）
  • 部署格式差异：Akash Network 用 SDL，不是 Docker Compose。现有 docker-compose.yml 需要翻译
  • 架构门槛：不像 docker compose up 一条命令，需要理解三层之间的网络、认证、编排（CF Tunnel、SDL、VPC 组网）

❓ 待验证 / 待探索

还没研究清楚、需要进一步验证的开放问题。一旦有结论，会转成”关键决策记录”里的一行，并在这里划掉。

  • 拿 Outline 或 n8n 跑通 CF Container → Akash Network → Hyperdrive → DBaaS 全链路
  • 实测 DePIN 节点下线 → Akash 自动重建容器的冷启动时间
  • CF Queue + DePIN “抢单”模式的延迟是否可接受
  • 对比 Akash Network 和 io.net 的实际 GPU 价格和可用性
  • Frappe Press Bench 能否通过无状态化改造最终也迁移到 DePIN？（远期）
  • 研究 PostgreSQL 分布式插件——Bob 语音提到”邮件里说了可以加插件在 Akash 上分布式存储”，但邮件 AI 的结论是反对物理层分布式卷。需要验证

🗄️ 已废弃的方向（快速索引）

文档变长后，方便不翻全文就知道”哪些路走过又被否了”。

暂无。当前架构为首次确立。

📎 溯源

标注关键决策/方向转变，来自哪次邮件、哪次聊天，方便回头翻原始对话。

日期来源主题
2026-07-1334 封邮件Bob 和 AI 探讨 CF + DePIN + DBaaS 替代 VPS 全路线
2026-07-13语音通话Bob 明确 Web3 三件套（DePIN + IPFS + 智能合约）、规模论证（100 项目 × 100 免费额度、沟通频率调整

关系图谱

反向链接