VOL. XIII · NO. 05 · Elixir · 25 JUL 2026

Extensions Serverless Architecture

Elixir 编程 · 25 JUL 2026 · 23 min read · 3,789 words

· · ·

Elixir + Cloudflare + Vultr：按需起 VM 的”函数式计算”架构

目标：解释为什么 Elixir + Cloudflare + Vultr 三件套是天然组合，能用按小时计费的 VM 模拟出 serverless 体验，同时保留 BEAM 的”进程即状态”简单性。

一、核心思路：用 BEAM + Cloudflare Tunnel 实现”按需起 VM”

1.1 传统 serverless 的 4 个痛点

痛点	表现
冷启动抖动	Java Lambda 几秒，Node Lambda 100-500ms
状态必须外置	Redis / DynamoDB / S3 强加给你
长连接弱	API Gateway 29s 超时，WebSocket 难做
供应商绑定	CloudWatch / X-Ray / IAM 全是 AWS 私货

1.2 Elixir + Vultr + Cloudflare 的替代方案

替代	实现
”按量计费”	Vultr 按小时计费（$0.007/h 起）
“冷启动”	BEAM 启动 15-30s（含 OS）
“零公网配置”	Cloudflare Tunnel 自动注册，VM 无需公网 IP
”零冷启动边缘”	Cloudflare Worker 处理突发流量
”状态外置” → 不需要	GenServer 进程内状态，0.5KB/进程

1.3 经济模型对比

维度	AWS Lambda	Elixir on Vultr + CF
计费	每 100ms	每小时（$0.007 起）
冷启动	50-500ms	15-30s（可预热）
长连接	差（API GW 29s 超时）	强（Phoenix 百万 WebSocket）
状态	必须外置	进程内原生
突发 1000x	Lambda 自动 scale	VM scale out（30s 准备好）
月成本（10 万次请求）	$1-5	$0.5-2（缩到 0 后）

1.4 为什么是 Elixir

Elixir 相比 JVM/Node 在”按需起 VM”场景有 3 个独有优势：

mix release 是自包含目录（详见 lesson 0006）：一个 bin/ 脚本 + lib/ 编译产物，整个目录 tar 拷到任何 Linux 15 秒可服务。Spring Boot 启动 30-60 秒，Node 启动 2-5 秒但需要预装 node_modules。
BEAM 冷启动比 JVM 快 5-10x：Erlang VM 是为电信级 soft real-time 设计的，2018 年 WhatsApp 工程师 benchmark：2 核 2GB 起 1.5 秒达到 80K 连接。
libcluster 内置 gossip 协议：VM 加减容自动发现，0 配置就形成集群。Spring Cloud / Kubernetes 都要额外服务发现组件。

二、四个具体场景

场景 1：金融新闻抓取（你 ex/elixir 项目的现状！）

痛点：现在 Pipeline.Jobs.NewsDigest 一天只跑 5 个时段（pre_0715 / pre_0915 / trading_am / trading_pm / close），但 Oban worker 进程 24h 在线 → 大部分时间在空转烧钱。

架构：

┌──────────────────────────────────────────────┐
│  Cloudflare Worker (边缘)                    │
│  - cron trigger: 每 5 分钟检查 "现在该跑吗"   │
│  - 命中时段 → POST 到 CF Tunnel              │
└──────────────┬───────────────────────────────┘
               │ https://pipeline.agquant.com/digest
               ▼
┌──────────────────────────────────────────────┐
│  Vultr VM (only during active windows)       │
│  - 4GB / $20/mo = $0.027/h                   │
│  - boot: 15s via snapshot restore            │
│  - runs 5×10min = 50min/day                  │
│  - auto-destroy after 30min idle             │
└──────────────────────────────────────────────┘

代码骨架：

# scripts/spawn_digest_vm.exs
defmodule SpawnDigestVM do
  def ensure_running do
    case list_active_vms() do
      [] -> spin_up()  # 15-30s 内准备好
      [_ | _] -> :ok
    end
  end

  def spin_up do
    snapshot_id = Application.get_env(:pipeline, :vultr_snapshot_id)
    Vultr.post("/instances", %{
      region: "sgp",  # 新加坡离你最近
      plan: "vc2-2c-4gb",
      os: "1743",  # snapshot-from-id 类型
      snapshot_id: snapshot_id,
      label: "pipeline-digest-#{DateTime.utc_now() |> DateTime.to_unix()}",
      user_data: cloud_init_script()  # 启动后跑 mix release + 加入 cluster
    })
  end

  def teardown_after_idle do
    # 30 分钟无 job → Vultr.delete("/instances/:id")
  end
end

成本对比：

方案	月成本
现在的 Oban on EC2/ECS (24×7, 2GB)	~$15-30
Vultr 按需 (5×10min × 30天)	$0.70（1.4h × $0.027 = $0.04/天 × 30）
Cloudflare Workers (cron 触发)	免费额度内
合计	$0.70 / 月

节省 95%+。 适合：周期性任务、cron job、定时抓取。

场景 2：用户上传大文件 → 异步处理（OCR / 解析 / 转码）

痛点：用户偶尔上传 xlsx / PDF（10-100MB），处理需要 30-60s CPU 重活，但 99% 时间没活儿。

架构：

用户上传
   ↓
Cloudflare Worker (接收)
   ↓
  1. 校验 + 限流（rate limit）
  2. 写 R2 存储（$0.015/GB，无 egress 费）
  3. 通过 CF Tunnel 把任务 push 给 Elixir VM
   ↓
┌─────────────────────────────────────┐
│  Vultr VM (处理 worker)             │
│  - 8GB / $40/mo = $0.055/h          │
│  - cold start 25s                   │
│  - 跑完任务 self-destruct            │
└─────────────────────────────────────┘
   ↓
处理完写 R2 + Postgres (RDS)
   ↓
Cloudflare Worker
   ↓
前端轮询 / WebSocket 通知

Elixir 这边的妙处：用 GenServer 状态机串流程，用 Task.Supervisor.async_nolink 并行处理多文件，单 VM 轻松同时处理 50-100 个文件。

成本：

项	单次上传	1000 次/月
R2 存储（10GB 平均）	$0.15/GB-月	取决于保留时间
R2 egress	$0	$0
Cloudflare Worker	0.5ms × 1 = 免费
Vultr 处理 VM (假设 1000次 × 5s = 83min/月)	—	$0.07
RDS Postgres	—	$15-30（常驻）
合计	—	$15-30 / 月（vs 传统常驻 8GB = $40 × 30 = $1200）

节省 95%+。 适合：偶发重活、批处理、用户触发型任务。

场景 3：Phoenix LiveView 实时 Web 应用（金融看板 / 聊天 / 协同）

痛点：WebSocket 长连接需要”常驻”服务器。AWS API Gateway / Lambda 不友好。

架构：

浏览器
  ↓ WebSocket (WSS)
Cloudflare (TLS 终止 + DDoS 防护)
  ↓ CF Tunnel
┌────────────────────────────────────────┐
│  Vultr VM cluster (2-10 个)            │
│  - 4GB / $20/mo each                   │
│  - mix release 启动 15s                │
│  - libcluster 自动 gossip              │
│  - Phoenix LiveDashboard 监控          │
└────────────────────────────────────────┘
  ↓
Postgres (RDS, 常驻)
Redis (Upstash, 按请求)

自动扩缩容：

# cloud-init: VM 起来后自动 join cluster
#!/bin/bash
systemctl start pipeline
# /etc/systemd/system/pipeline.service:
#   ExecStart=/opt/pipeline/bin/pipeline start
#   Environment=LIBCLUSTER_SEEDS=...

# autoscaler.exs (跑在某个 always-on VM 或 CF Worker cron)
defmodule Autoscaler do
  def check_every_minute do
    load = get_cluster_load()  # 从 LiveDashboard 拉
    cond do
      load > 0.8 and vm_count() < 10 -> spin_up_vm()
      load < 0.2 and vm_count() > 1 -> destroy_idle_vm()
      true -> :ok
    end
  end
end

Elixir 的核心优势：

每个 WebSocket = 一个 BEAM 进程（0.5KB），4GB VM = 800 万连接理论上限
libcluster 自动 gossip，VM 加减容无停机
Phoenix LiveView 服务端渲染 + 进程间消息，0 JavaScript 也能做实时 UI

成本（假设峰值 5000 并发 WebSocket，平时 500）：

方案	月成本
AWS ALB + 4× EC2 c5.xlarge (常驻)	~$500-700
Vultr 弹性 (峰 4 VM × 8h/天 + 谷 1 VM × 16h/天)	$20-50
Cloudflare Tunnel + DDoS 防护	免费
合计	$20-50 / 月

节省 90%+。 适合：WebSocket 多 / 流量波峰波谷明显 / 不能用 managed k8s 太复杂的场景。

场景 4：边缘计算 + AI 推理（Cloudflare Workers AI + Elixir 编排）

架构：

用户请求
  ↓
CF Worker (LLM prompt 改写 + 缓存检查)
  ↓
  KV/R2 命中 → 直接返回
  ↓ 未命中
  Workers AI (Llama 3 / SDXL) → 生成
  ↓
  Elixir VM (后处理 + 业务逻辑 + 写 DB)

Elixir 这边只做”必须有的业务编排”：鉴权、计费、对话历史、复杂 multi-step agent。AI 推理交给边缘。

优势：

Workers AI 已经在 200+ 城市节点，你不需要自建 GPU
弹性 = 真正的零（没请求 = 零成本）
Elixir VM 只处理”值得计费的请求”，平时 0 流量 = 0 VM

适合：AI 聊天、图像生成、文档摘要（你 ex/elixir 那个 news_digest 项目就是这个 pattern！LLM 摘要 + 业务落库）。

三、关键技术点详解

3.1 mix release —— Elixir 唯一能 work 的技术基础

MIX_ENV=prod mix release
# 产物：_build/prod/rel/pipeline/

_build/prod/rel/pipeline/
├── bin/
│   ├── pipeline        # 启动脚本
│   └── pipeline.bat    # Windows 启动
├── lib/                # 所有依赖 + BEAM 编译产物
├── releases/
│   ├── 0.1.0/
│   │   ├── pipeline.sh
│   │   └── runtime.exs  # 启动时配置
│   └── COOKIE
└── ...（自包含）

为什么这是关键：整个 rel/pipeline/ 目录可以 tar czf pipeline.tgz _build/prod/rel/pipeline/，scp 到任何 Linux VM，30 秒内可服务。没有运行时依赖（不需预装 Erlang、不需预装系统库）——这跟 Java Spring Boot 需要预装 JVM 是同一个级别，但 cold start 时间只有 Spring Boot 的 1/3。

详见 lesson 0006。

3.2 Cloudflare Tunnel（`cloudflared`）

cloudflared 是 Cloudflare 官方 daemon，让任意内网服务暴露到公网，不需要公网 IP、不需要配防火墙。

# 安装
brew install cloudflared  # macOS
# 或在 Linux VM 上：
curl -fsSL https://pkg.cloudflare.com/cloudflare-main.gpg | sudo tee /usr/share/keyrings/cloudflare-main.gpg
# ...

# 登录获取 cert
cloudflared tunnel login

# 创建 tunnel
cloudflared tunnel create pipeline-prod

# 配 DNS：pipeline.agquant.com → tunnel
cloudflared tunnel route dns pipeline-prod pipeline.agquant.com

# 跑（指向本地 8002 端口）
cloudflared tunnel run pipeline-prod

优势对比：

不用配 nginx / 不用配 TLS cert / 不用公网 IP / 不用配安全组
新 VM 起来后跑同一行命令就 join——这就是”按需 VM”能 work 的关键
Cloudflare 免费版不限 tunnel 数量

3.3 libcluster —— BEAM 自带的集群发现

# mix.exs
{:libcluster, "~> 3.3"}

# config/prod.exs
config :libcluster,
  topologies: [
    k8s: [
      strategy: Cluster.Strategy.Kubernetes,
      config: [kubernetes_namespace: "pipeline", kubernetes_selector: "app=pipeline"]
    ]
  ]

或纯 Vultr 场景用 gossip 策略：

config :libcluster,
  topologies: [
    gossip: [
      strategy: Cluster.Strategy.Epmd,
      config: [hosts: [:"pipeline@#{vm1_ip}", :"pipeline@#{vm2_ip}"]]
    ]
  ]

VM 加减容时：Node.list() 自动更新，新 VM 自动被已有节点 gossip 发现。0 配置——这就是 BEAM 30 年验证过的”软实时集群”。

3.4 cloud-init + Vultr Snapshot

Vultr Snapshot = VM 状态保存为镜像（类似 Docker image 但更重，含 OS + 用户数据）。

cloud-init = VM 第一次启动时跑的脚本（注入到 Vultr Snapshot 创建时）。

# user_data (cloud-init 格式)
#cloud-config
write_files:
  - path: /opt/pipeline.env
    content: |
      DATABASE_URL=postgres://...
      LLM_URL=https://api.openai.com/v1
      LLM_KEY=sk-xxx
runcmd:
  - apt-get update && apt-get install -y curl
  - curl -L https://github.com/your/repo/releases/latest/download/pipeline.tgz -o /tmp/pipeline.tgz
  - tar xzf /tmp/pipeline.tgz -C /opt
  - systemctl enable pipeline
  - systemctl start pipeline
  - cloudflared service install
  - cloudflared tunnel run pipeline-prod

cold start 时间线：

阶段	耗时
Vultr API 接收 + 排队	5-10s
启动 snapshot VM	10-20s
cloud-init 拉 release + 起服务	15-30s
总计	30-60s（其中冷 VM 占大头）

vs Spring Boot（要 2-3 分钟），这个时间可以接受做”按需起”。

3.5 Phoenix LiveDashboard 监控 + Autoscaler 触发

# mix.exs
{:phoenix_live_dashboard, "~> 0.8"}

# 暴露 /dashboard（仅内网）
config :pipeline, :live_dashboard, enabled: true

Autoscaler 从 LiveDashboard 拉指标：

defmodule Autoscaler do
  def check_every_minute do
    metrics = Phoenix.LiveDashboard.fetch_system_metrics()
    
    cond do
      metrics.cpu > 80 and vm_count() < 10 ->
        spin_up_vm()
      metrics.websocket_count > 80_000 ->
        spin_up_vm()  # WebSocket 密集型
      metrics.cpu < 10 and vm_count() > 1 ->
        destroy_idle_vm()
      true -> :ok
    end
  end
end

四、成本对比总览

工作负载类型	传统架构	Vultr + CF 弹性	节省
定时任务（每天 < 1 小时）	$15-30/mo (24/7 2GB)	$0.70/mo	95%
偶发重活（每天 1-2 小时）	$40-120/mo (24/7 4-8GB)	$2-5/mo	95%
WebSocket 流量（峰 4×/谷 1×）	$500-700/mo (4× EC2)	$20-50/mo	90%
AI 编排（按需推理）	难定价（要么 GPU 要么长跑）	$5-20/mo	视情况

五、什么时候不要用这套

场景	原因	替代
延迟敏感 (< 50ms) 的核心 API	VM cold start 30-60s	CF Worker / Fly.io 边缘
长跑批处理（每天 > 8 小时）	直接买 reserved instance 便宜	Vultr reserved / Hetzner
GPU 训练	通用云无 GPU	Lambda Labs / RunPod / Vast.ai
中国境内服务	CF 慢 / Vultr 无国内节点	阿里云函数计算 / 腾讯云 SCF
流量稳定（不波峰波谷）	弹性省不了钱	Reserved instance 反而更便宜

六、立即可落地的最小方案

给 ex/elixir 项目的具体下一步（1-2 天做完）

验证 mix.exs 已有 releases 配置（你已经有了，lesson 0006 详解）
写 cloud-init.yml：cloud-init 起 VM → 拉 git → 跑 mix release → bin/pipeline start
写 lib/pipeline/autoscaler.ex：用 Vultr API 调 POST /instances 和 DELETE /instances/:id
写一个 cloudflared config 模板，每个 VM 起来都注册一条 tunnel
用 Oban cron 每分钟查 LiveDashboard 负载，触发 scale out/in

做完你那个 ex/elixir 项目的月成本能从 $30 降到 $3-5，弹性 10x 扩容能力（金融事件驱动型流量）。

七、相关资源

八、自检清单

知道 mix release 产物是自包含目录，scp 到任何 Linux 可服务
知道 Cloudflare Tunnel 不需要公网 IP / 不需要配 TLS
知道 libcluster gossip 协议让 BEAM 集群加减容无配置
知道 Vultr Snapshot + cloud-init 怎么 cold start 一个 VM
知道 Phoenix LiveDashboard 提供运行时指标
能算”按需起 VM”比”长跑 VM”省多少

九、业务选择框架（什么用、什么不用、怎么判断）

给你和你的 PM / Tech Lead 用：5 分钟判断”我这个业务到底该不该用这套”。

9.1 一句话判断

“流量有明显波峰波谷 + 能容忍 30-60s 冷启动 + 单 VM 状态装得下 + CPU 计算为主 + 月成本敏感”——5 个里 ≥3 个 ✅，就上。

9.2 决策流程图（5 个 gate）

              ┌─────────────────────────┐
              │ Gate 1: 流量模式？        │
              │  峰/谷比 > 3x？          │
              └────────┬────────────────┘
                       │
              ┌────────┴──────────┐
              ▼                   ▼
        ✅ 突发                ❌ 稳态
        继续 ↓                 放弃，用 reserved
              │
              ┌────────┴────────────────┐
              │ Gate 2: 冷启动容忍度？     │
              │  业务能接受 30-60s？     │
              └────────┬────────────────┘
                       │
              ┌────────┴──────────┐
              ▼                   ▼
        ✅ 30-60s ok            ❌ 必须 < 1s
        继续 ↓                 放弃，用 CF Worker / Fly.io 边缘
              │
              ┌────────┴─────────────────────┐
              │ Gate 3: 单 VM 装得下状态吗？ │
              │  GenServer + ETS < 10GB？    │
              └────────┬────────────────────┘
                       │
              ┌────────┴──────────┐
              ▼                   ▼
        ✅ 装得下                ❌ TB 级共享状态
        继续 ↓                 放弃，用 distributed DB + 服务
              │
              ┌────────┴────────────────┐
              │ Gate 4: 计算类型？       │
              │  CPU/Memory vs GPU？    │
              └────────┬────────────────┘
                       │
              ┌────────┴──────────┐
              ▼                   ▼
        ✅ CPU/Memory           ❌ GPU
        继续 ↓                 放弃，用 Lambda Labs / RunPod
              │
              ┌────────┴────────────────┐
              │ Gate 5: 地理 / 合规？     │
              │  全球 OR 海外 OR 国内？  │
              └────────┬────────────────┘
                       │
              ┌────────┴──────────────────────┐
              ▼                                ▼
        ✅ 全球 / 海外 (sgp/lax)        ❌ 中国境内 / 数据不出境
        🎉 适合                          放弃，用阿里云 / 腾讯云

5 个 gate 全过 → 这套架构非常适合 4 个过 → 适合，但部分场景需要做变通 3 个过 → 看具体情况（成本/运维投入是否值得） ≤2 个过 → 换方案

9.3 6 个最适合的业务场景

场景 A：金融 / 交易 / 行情数据（你 ex/elixir 项目就是）

典型业务：盘前盘后新闻、夜盘行情推送、EOD 报告生成、研报抓取

为什么适合：

天然时间窗：每个市场有自己的开收盘时间
一天真正”忙”的小时可能 < 4h（盘前 + 盘中 + 盘后）
计算密集但时间短
真实案例：你 Pipeline.Jobs.NewsDigest 现在 24/7 跑 5 个时段 = 95% 时间空转烧钱

成本：

当前：Oban cron 24×7 在 EC2/ECS 跑，~$30/月
改造后：5 × 10min = 50min/天 = 1.4h/月 × $0.027 = $0.04/月 + $0.10 杂费 = $0.70/月
省 95%

场景 B：电商 / 票务 / 限量活动

典型业务：演唱会开票、双 11、Black Friday、AJ 抽签、PS5 抢购

为什么适合：

N 分钟内 QPS 涨 1000x：从 100 QPS 跳到 100K QPS
平日几乎 0 流量
峰值后立刻回到 0
WebSocket 长连接（抢购房间）+ 短时高频 HTTP（提交订单）

架构：

平日：
  Cloudflare LB → 0 个 VM（仅 Worker 处理静态）
  成本 = $0

开票前 10 分钟：
  CF Worker 检测到开票时间 → spin up 10 个 Phoenix VM
  抢票期间：10 × $0.027/h = $0.27/h × 3h = $0.80
  总成本 ≈ $1 / 次开票

开票后 30 分钟：
  autoscaler 看到 QPS < 5 → halt 所有 VM

场景 C：媒体 / 内容聚合

典型业务：新闻 RSS 抓取、视频转码、播客转文字、爬虫代理

为什么适合：

内容生产有天然节奏（每日 / 每周）
单次任务重（爬 100 个站点需要 10 分钟）
用户读是异步的（不等结果）

实例：你已经在做的”早盘新闻摘要”，可以扩展成”全天 5 个时段抓 + 摘要 + 入库”。

场景 D：企业内部工具 / B2B SaaS 长尾

典型业务：合规检查、BI 仪表盘、内部审批流、批量报表、admin 后台

为什么适合：

用户少（< 1K），资源需求小
业务时间不规律（财务月末、季度审计、双 12）
老板嫌”这工具一年没几个人用还占 1 台 VM”

实例：

财务月报：每月最后 1 天跑 4 小时，平时 0 流量 → 月成本 $0.50
审计报告生成：每季度跑 1 次，每次 8 小时 → 季度成本 $2

场景 E：AI 应用 / 边缘推理

典型业务：文档摘要、客服 chatbot、图片生成、RAG、code assistant

为什么适合：

LLM 推理贵——需要”有请求才花钱”
业务逻辑编排（system prompt 拼接、上下文管理、计费）需要 stateful
Elixir VM 完美：stateful orchestration + CF Worker AI 边缘推理

架构：

用户问
  ↓
CF Worker (拼 system prompt + 检查缓存)
  ↓
  KV 命中 → 直接返回
  ↓ 未命中
  Workers AI (边缘 LLM 推理) → 生成
  ↓
  CF Tunnel → Elixir VM
    - 计费
    - 上下文管理
    - 调用其他 API
    - 写 DB

场景 F：用户触发型重活（上传 / 转换 / 解析）

典型业务：上传 xlsx 解析、上传 PDF 转换、上传视频转码、图片处理

为什么适合：

用户偶发（不是每秒钟）
CPU 重活（30-60s 才能完成）
99% 时间 0 流量

实例：你 ex/elixir 项目现在没做但很容易加——POST /api/upload → R2 存文件 → spin up 8GB VM → Cloudflare Worker 通知前端结果。

9.4 6 个不适合的业务场景

业务	为什么不适合	替代方案
高频交易 (HFT)	必须 < 10ms latency，cold start 30-60s 不可接受	专用 FPGA / colo / co-located exchange
大型 MMO 游戏	单服 10K+ 连接常驻，24/7 满载	Unity Game Server / Agones / 自建 K8s
中国大陆 B2C 业务	GFW 拦截 + Vultr 无国内节点	阿里云函数计算 / 腾讯云 SCF / 华为云
每天 24h 长跑批处理	无波谷，reserved 便宜 50%	Vultr reserved instance / Hetzner bare metal
GPU 训练 / 大模型推理	通用云无 GPU	Lambda Labs / RunPod / Vast.ai / AWS p3
医疗 / 政府（强合规）	数据必须本地、特定云、专有云	华为云 Stack / 阿里云专有云 / 自建机房

额外要谨慎的：

TB 级分布式状态（如全网用户的画像缓存）：单 VM 装不下，硬塞会 OOM——用 Redis Cluster / ScyllaDB / Cassandra
强实时多人协作（如 Google Docs）：< 100ms latency 压力，30-60s cold start 不行——考虑 Fly.io 边缘

9.5 6 个典型部署模式（可直接套用）

模式 1：“Cron-and-Stop”（定时任务模式）

适用：每天 < 1h 的批处理（金融抓取、日报、备份）

┌──────────────────────────────────┐
│ CF Worker (cron trigger)         │
│ - 每 5 分钟检查 "现在该跑吗"     │
│ - 命中时段 → spin up VM          │
└────────┬─────────────────────────┘
         ↓
┌──────────────────────────────────┐
│ Vultr VM (snapshot restore)      │
│ - 跑任务（10-60 min）            │
│ - 跑完 halt                      │
└──────────────────────────────────┘

你的 ex/elixir 项目 Pipeline.Jobs.NewsDigest → 直接套用这个模式。

模式 2：“Webhook-Queue”（事件驱动模式）

适用：用户触发型（上传、点击、表单提交）

用户操作
  ↓
CF Worker (鉴权 + 限流)
  ↓
R2 存文件 / KV 存 metadata
  ↓
CF Tunnel → Elixir VM (libcluster queue)
  ↓
GenServer 派发 → Task.Supervisor 处理
  ↓
完成 → Worker 通知前端 (WebSocket)

模式 3：“Phoenix-Chat”（WebSocket 实时模式）

适用：实时聊天、协作、看板、通知推送

浏览器
  ↓ WSS
Cloudflare (TLS + DDoS)
  ↓ CF Tunnel
┌────────────────────────────────────┐
│ 1-10 × Phoenix VM (libcluster)    │
│ - 每 VM 8000 WebSocket = 0.5KB    │
│ - gossip 自动发现                  │
│ - 节点挂掉自动剔除 + 重连          │
└────────────────────────────────────┘

模式 4：“Overnight-Report”（夜间报表模式）

适用：日报 / 周报 / 月报生成

Oban cron 23:00
  ↓ spin up 1 个 8GB VM
  ↓ 跑 SQL 聚合（3-5 小时）
  ↓ 生成 PDF/Excel
  ↓ 写 R2 / 邮件发送
  ↓ halt

月成本：每天 4h × 30 天 × $0.055 = $6.6/月（vs 长跑 8GB = $40/月）。

模式 5：“Edge-Origin”（边缘 API 模式）

适用：全球用户的低延迟 API（< 100ms）

用户 (全球)
  ↓
Cloudflare Worker (边缘逻辑)
  - 简单鉴权
  - KV 缓存
  - 限流
  ↓ (未命中或需后端逻辑)
  CF Tunnel → Elixir VM (origin)
  - 业务逻辑
  - 复杂查询
  - 第三方 API 调用

优势：CF Worker 边缘命中 → 0 ms；未命中 → Elixir VM → 30-200ms。比”全球部署多 region”便宜 90%。

模式 6：“AI-Orchestration”（AI 编排模式）

适用：所有 AI 应用

用户问
  ↓
CF Worker
  - 拼 prompt
  - 检查 RAG 缓存
  ↓
Workers AI (边缘 LLM 推理)
  ↓
  CF Tunnel → Elixir VM
    - 业务逻辑（鉴权、计费、上下文）
    - 调用其他服务（DB、第三方 API）
    - 持久化（写 history、metrics）

为什么 Elixir 适合这个：AI 应用最复杂的不是”调 LLM”，是”上下文管理 + 工具调用 + 多步 agent + 失败重试”——这是 GenServer 的强项。

9.6 6 个反模式（怎么识别踩坑了）

反模式 1：“为了弹性而弹性”

表现：流量其实很稳，硬加 autoscaler
信号：autoscaler 一天调 0 次
后果：架构复杂度 ↑、可靠性 ↓、成本没省
修复：用 reserved instance 简单点

反模式 2：“以为 cold start 30s 用户能接受”

表现：用户反馈”打开页面要等 30 秒”
信号：用户首屏 < 1s 才能留住，30s cold start 你 90% 用户已经走人
后果：体验崩塌
修复：CF Worker 始终常驻做”立即返回”，复杂逻辑异步

反模式 3：“把所有状态都塞 GenServer”

表现：单 VM 内存 16GB 用了 15.8GB
信号：进程重启 → 状态丢失 → 业务报错
后果：扩展性差、单点故障
修复：热数据 GenServer + 冷数据 Ecto / Redis / S3

反模式 4：“忽略 reserved IP / firewall 配置”

表现：开放 0.0.0.0/0:22 给 SSH
信号：被攻击 / 被入侵
后果：数据泄露、被挖矿
修复：只允许 Cloudflare IP 段（完整列表），不开公网 SSH（用 cloudflared SSH）

反模式 5：“没有 rate limit”

表现：一个 client 触发 1000 个 VM spin up
信号：月费突然从 $5 涨到 $500
后果：账单爆炸
修复：CF Worker 限流 + 账单监控 + 硬上限（autoscaler 不超过 N 个 VM）

反模式 6：“snapshot 不更新”

表现：发版本后没更新 snapshot，VM 跑的还是旧代码
信号：调试半天发现”线上代码跟 git 不一致”
后果：bug 难复现
修复：CI 流程 mix release 后自动 POST /snapshots

9.7 给 PM / Tech Lead 的自检清单

该用的信号（≥3 个就上）：

流量峰谷比 > 3x
能接受 30-60s 冷启动（业务侧可接受）
业务状态可单 VM 装下（GenServer + ETS + DB cache < 10GB）
CPU/Memory 计算，不是 GPU
月成本敏感（少 $50 也有意义）
团队懂 BEAM 或愿意学（不是 K8s 深度玩家）
海外或全球用户（中国大陆用户 < 20%）

不该用的信号（≥1 个就放弃）：

用户要求 < 100ms latency
业务必须中国境内（GFW + 合规）
需要 GPU（训练 / 推理）
24×7 满载（无波谷）
TB 级分布式状态
强合规（数据不能出特定云 / 区域）
团队是 K8s 重度玩家、Ops 期望 Pod 而非 Process

9.8 一句话总结

Elixir + Vultr + Cloudflare 不是”替代 K8s”，是”替代 K8s 中 80% 的常驻 workload”。

它适合的是”业务状态天然进程内、流量天然波峰波谷、用户能容忍几十秒冷启动”的工作负载。

不适合的是”必须 24/7 跑、必须 < 100ms、必须 TB 共享状态、必须中国境内”的工作负载。

选不选这套，跟你的 K8s 经验无关，跟你的业务模式有关。

Extensions Serverless Architecture

Elixir + Cloudflare + Vultr：按需起 VM 的”函数式计算”架构

一、核心思路：用 BEAM + Cloudflare Tunnel 实现”按需起 VM”

1.1 传统 serverless 的 4 个痛点

1.2 Elixir + Vultr + Cloudflare 的替代方案

1.3 经济模型对比

1.4 为什么是 Elixir

二、四个具体场景

场景 1：金融新闻抓取（你 ex/elixir 项目的现状！）

场景 2：用户上传大文件 → 异步处理（OCR / 解析 / 转码）

场景 3：Phoenix LiveView 实时 Web 应用（金融看板 / 聊天 / 协同）

场景 4：边缘计算 + AI 推理（Cloudflare Workers AI + Elixir 编排）

三、关键技术点详解

3.1 mix release —— Elixir 唯一能 work 的技术基础

3.2 Cloudflare Tunnel（cloudflared）

3.3 libcluster —— BEAM 自带的集群发现

3.4 cloud-init + Vultr Snapshot

3.5 Phoenix LiveDashboard 监控 + Autoscaler 触发

四、成本对比总览

五、什么时候不要用这套

六、立即可落地的最小方案

七、相关资源

八、自检清单

九、业务选择框架（什么用、什么不用、怎么判断）

9.1 一句话判断

9.2 决策流程图（5 个 gate）

9.3 6 个最适合的业务场景

场景 A：金融 / 交易 / 行情数据（你 ex/elixir 项目就是）

场景 B：电商 / 票务 / 限量活动

场景 C：媒体 / 内容聚合

场景 D：企业内部工具 / B2B SaaS 长尾

场景 E：AI 应用 / 边缘推理

场景 F：用户触发型重活（上传 / 转换 / 解析）

9.4 6 个不适合的业务场景

9.5 6 个典型部署模式（可直接套用）

模式 1：“Cron-and-Stop”（定时任务模式）

模式 2：“Webhook-Queue”（事件驱动模式）

模式 3：“Phoenix-Chat”（WebSocket 实时模式）

模式 4：“Overnight-Report”（夜间报表模式）

模式 5：“Edge-Origin”（边缘 API 模式）

模式 6：“AI-Orchestration”（AI 编排模式）

9.6 6 个反模式（怎么识别踩坑了）

反模式 1：“为了弹性而弹性”

反模式 2：“以为 cold start 30s 用户能接受”

反模式 3：“把所有状态都塞 GenServer”

反模式 4：“忽略 reserved IP / firewall 配置”

反模式 5：“没有 rate limit”

反模式 6：“snapshot 不更新”

9.7 给 PM / Tech Lead 的自检清单

9.8 一句话总结

3.2 Cloudflare Tunnel（`cloudflared`）