从 Azure Functions 到 FreeBSD：无服务器到自托管的工程迁移实践

迁移触发：当无服务器遇到产品生命周期终结

2025 年感恩节早晨，Julio Merino 发现他的 Web 服务返回 "503 Service unavailable" 错误。登录 Azure 控制台后，只看到简短的 "Runtime version: Error" 消息，无法诊断具体问题。更关键的是，控制台顶部有一个不起眼的黄色警告："Migrate your app to Flex Consumption as Linux Consumption will reach EOL on September 30 2028 and will no longer be supported."

这个警告并非新闻 —— 作者几周前就知道 Azure Functions 的免费计划即将终止。但遇到实际的服务中断后，迁移从 "未来计划" 变成了 "紧急行动"。虽然距离 2028 年还有三年时间，但不可预测的运行时错误和产品生命周期的确定性终结，促使他立即将服务从 Azure Functions 迁移到自家车库中的 FreeBSD 服务器。

技术重构：从 Azure Functions 运行时到 FreeBSD daemon 包装

1. Azure Functions 自定义处理器架构

在 Azure Functions 中，作者使用自定义处理器（Custom Handler）模式运行 Rust 编写的服务。架构如下：

# Azure Functions 运行时环境变量
FUNCTIONS_CUSTOMHANDLER_PORT=8080
# 应用监听此端口，Azure 处理 TLS 终止和路由

应用本身是一个标准的 HTTP 服务器，通过环境变量获取监听端口。Azure Functions 运行时负责：

TLS 终止
请求路由（基于 function.json 配置）
按需启动和停止容器实例
监控和自动扩缩容

2. FreeBSD daemon (8) 包装方案

迁移到 FreeBSD 后，需要让二进制应用作为系统服务运行。关键需求包括：

以非特权用户身份运行
创建 PID 文件供服务管理
日志重定向和轮转
配置注入

FreeBSD 的 daemon(8) 工具完美解决了这些问题：

daemon \
    -P /var/run/endbasic.pid \
    -o /var/log/endbasic.log \
    -H \
    -u endbasic \
    -t endbasic \
    /bin/sh -c '
        . /usr/local/etc/endbasic.conf
        /usr/local/sbin/endbasic'

参数解析：

-P /var/run/endbasic.pid: 指定 PID 文件路径，供 rc.d 框架管理进程生命周期
-o /var/log/endbasic.log: 将 stdout/stderr 重定向到日志文件
-H: 关键参数，支持日志轮转（响应 SIGHUP 信号）
-u endbasic: 以 endbasic 用户身份运行（权限降级）
-t endbasic: 设置进程标题，便于 ps ax 识别

3. rc.d 服务集成

将 daemon 包装集成到 FreeBSD 的服务管理系统中：

#! /bin/sh

# PROVIDE: endbasic
# REQUIRE: NETWORKING postgresql

. /etc/rc.subr

name=endbasic
command=daemon
rcvar=endbasic_enable
pidfile="/var/run/${name}.pid"
start_cmd=endbasic_start
required_files="
    /usr/local/etc/endbasic.conf
    /usr/local/sbin/endbasic"

endbasic_start()
{
    if [ ! -f /var/log/endbasic.log ]; then
        touch /var/log/endbasic.log
        chmod 600 /var/log/endbasic.log
        chown endbasic /var/log/endbasic.log
    fi

    echo "Starting ${name}."
    daemon \
        -P "${pidfile}" \
        -o /var/log/endbasic.log \
        -H \
        -u endbasic \
        -t endbasic \
        /bin/sh -c '
            . /usr/local/etc/endbasic.conf
            /usr/local/sbin/endbasic'
}

load_rc_config $name
run_rc_command "$1"

启用服务：

sysrc endbasic_enabled="YES"
service endbasic start

架构变化：TLS、数据库与日志管理的工程实现

1. TLS 终止策略迁移

在 Azure Functions 架构中，TLS 终止由平台处理。迁移到自托管后，有几种选择：

方案对比：

自签名证书 + nginx: 需要证书管理、配置复杂度高
Let's Encrypt: 自动化但需要公网 IP 和域名验证
Cloudflare Tunnels: 零配置 TLS，无需开放入站端口

作者选择了 Cloudflare Tunnels，架构如下：

客户端 → Cloudflare (TLS 终止) → cloudflared 隧道 → localhost:8080 → 应用

优势：

无需管理证书
内置 DDoS 防护
无需防火墙入站规则
保持与 Azure Functions 相同的安全模型（第三方 TLS 终止）

CORS 配置挑战： 由于 Cloudflare 作为前端代理，CORS 预检请求需要在其控制台配置。解决方案是使用转换规则：

{
  "rule_name": "CORS for endbasic",
  "action": "rewrite",
  "action_parameters": {
    "headers": {
      "Access-Control-Allow-Origin": {
        "operation": "set",
        "value": "https://endbasic.dev"
      },
      "Access-Control-Allow-Methods": {
        "operation": "set", 
        "value": "GET,POST,OPTIONS"
      }
    }
  }
}

2. 数据库迁移：从 Azure PostgreSQL 到自托管

成本对比：

Azure 托管 PostgreSQL: 最低配置 $15 / 月（开发模式，无冗余）
自托管 PostgreSQL: 硬件成本已摊销，仅电费

技术调整：

连接认证: 从密码认证改为本地对等认证

# pg_hba.conf
local   all             endbasic                              peer

测试策略: 从远程测试数据库改为本地测试实例

// 之前：连接远程 Azure PostgreSQL 进行测试
// 之后：使用本地临时 PostgreSQL 实例
#[cfg(test)]
fn create_test_db() -> PgPool {
    // 启动嵌入式 PostgreSQL 或使用临时实例
}

备份策略: 从 Azure 自动备份改为 ZFS 快照

# 每日快照
zfs snapshot tank/postgres@$(date +%Y%m%d)
# 保留最近7天
zfs list -t snapshot -o name -s creation | grep tank/postgres@ | head -n -7 | xargs -n1 zfs destroy

3. 日志管理：newsyslog 轮转机制

长期运行的服务需要日志轮转防止磁盘耗尽。FreeBSD 使用 newsyslog(8) 系统：

配置示例：

/var/log/endbasic.log endbasic:wheel 600 7 * @T00 JC /var/run/endbasic.pid

参数解析：

600: 文件权限 (rw-------)
7: 保留 7 个归档文件
*: 基于大小轮转（无限制时基于时间）
@T00: 每日午夜轮转
JC: J = 压缩为 .bz2，C = 轮转后继续写入
PID 文件路径：用于发送 SIGHUP 信号

轮转流程：

newsyslog 检测到轮转条件（时间 / 大小）
重命名当前日志文件：endbasic.log → endbasic.log.0
创建新的空 endbasic.log
向 daemon 进程发送 SIGHUP 信号
daemon 关闭旧文件句柄，重新打开新日志文件
newsyslog 压缩归档文件：endbasic.log.0 → endbasic.log.0.bz2

性能、成本与运维的量化分析

性能提升实测

迁移后性能显著提升，主要因素：

热缓存优势: 自托管服务持续运行，数据库查询缓存、文件系统缓存保持热状态
网络延迟消除: 应用与数据库共置，消除云环境网络延迟（通常 1-5ms）
冷启动消除: 无服务器环境每次请求可能触发冷启动（100ms-2s），自托管无此开销
资源独占: 避免云环境的多租户资源竞争

量化指标（估算）：

平均响应时间：从 50-200ms 降至 5-20ms
P99 延迟：从 500ms-2s 降至 50ms
吞吐量：提升 3-5 倍（相同硬件）

成本对比分析

Azure Functions 成本结构：

计算：免费层（即将终止）
数据库: Azure PostgreSQL $15 / 月（最低配置）
总成本: ~$20 / 月（含其他服务）

FreeBSD 自托管成本：

硬件: ThinkStation (二手) ~$500（一次性）
电力: ~$10 / 月（24x7 运行）
网络：已有家庭宽带
总成本：摊销后～$15 / 月（第一年后降至～$10 / 月）

三年总拥有成本（TCO）：

Azure: $20 × 36 = $720
自托管: $500 + ($10 × 36) = $860
差异: 自托管贵 $140，但获得完全控制权和性能提升

运维复杂度评估

失去的 Azure 功能：

自动扩缩容: 需要手动容量规划
地理冗余: 单点故障风险（作者迁移后第二天遇到 2 小时停电）
监控仪表板: 需要自建监控（Prometheus + Grafana）
自动部署: 从 GitHub Actions 自动化部署改为手动 sudo make install

获得的控制权：

完全日志访问: /var/log/ 直接查看，无需登录云控制台
即时配置变更: 直接编辑配置文件，无需等待部署
深度调试能力: 可直接 attach 调试器、分析核心转储
硬件优化: 可针对特定工作负载优化内核参数

迁移决策框架：何时选择自托管？

基于此案例，我们可构建迁移决策框架：

适合自托管的情况：

技术栈匹配度
- 应用已是独立二进制（Go、Rust、C++）
- 无重度依赖云特定服务（如 DynamoDB、SQS）
- 数据库可轻松迁移（PostgreSQL、MySQL）
流量模式
- 相对稳定流量，无突发尖峰
- 可预测的容量需求
- 区域性用户集中（无需全球低延迟）
成本敏感度
- 月成本超过 $50-100
- 长期运行（>1 年）
- 有闲置硬件资源
技术能力
- 有系统管理经验
- 能处理备份、监控、安全
- 有应对故障的应急预案

应保持无服务器的情况：

突发流量模式
- 流量波动剧烈（10 倍以上变化）
- 无法预测的峰值
- 全球分布用户
运维资源有限
- 无专职运维团队
- 需要专注于业务逻辑
- 无法承受服务中断
重度云服务依赖
- 深度集成 AWS/Azure/GCP 服务
- 使用无服务器数据库（Aurora Serverless、Cosmos DB）
- 依赖云原生消息队列、事件总线

工程实施清单

迁移前准备（1-2 周）

评估应用架构兼容性
选择目标硬件（性能、功耗、成本）
设计网络架构（防火墙、DNS、TLS）
规划数据迁移策略
建立监控和告警系统

技术迁移（2-3 天）

创建服务管理脚本（rc.d/Systemd）
配置日志轮转（newsyslog/logrotate）
设置 TLS 终止（Cloudflare/nginx）
迁移数据库（pg_dump/pg_restore）
测试端到端功能

运维建立（1 周）

配置自动备份（ZFS 快照 /rsync）
设置监控指标（CPU、内存、磁盘、网络）
创建灾难恢复流程
文档化运维手册
进行故障演练

结论：平衡控制权与复杂性

从 Azure Functions 迁移到 FreeBSD 自托管的案例展示了云原生与自托管之间的权衡。迁移带来了显著的性能提升和成本节约，但也引入了新的运维责任。

关键启示：

无服务器并非银弹：对于稳定流量、技术栈简单的应用，自托管可能更经济高效
FreeBSD 的稳定性：30 年不变的架构提供了可预测的运维环境
混合架构的价值：Cloudflare Tunnels 等工具允许部分功能保持 "云原生"（TLS、DDoS 防护）
技能投资回报：系统管理技能一旦掌握，可应用于多个项目

最终决策应基于具体的技术需求、成本约束和团队能力。对于许多中小型项目，自托管提供了云服务之外的可行选择 —— 特别是在云厂商不断调整产品策略和定价的今天。

资料来源：

Julio Merino. "From Azure Functions to FreeBSD". jmmv.dev, 2025-12-07
Hacker News 讨论: "From Azure Functions to FreeBSD" 线程，关于 FreeBSD 服务管理的实践经验分享