20. 🌟 Funboost 核心设计思想

📖 本章从架构哲学层面总结 funboost 的设计理念，帮助读者理解框架的定位、取舍和边界。具体用法见各教程章节。

20.1 🗽 函数至上，零侵入

核心命题：业务函数是核心资产，框架的职责是为函数赋能，而非约束函数。

from funboost import boost, BoosterParams, BrokerEnum

@boost(BoosterParams(queue_name='calc_queue', broker_kind=BrokerEnum.REDIS, qps=10))
def calculate_data(x, y):
    return x + y

# 本地直调（@boost 不改变函数行为）
result = calculate_data(1, 2)  # → 3

# 分布式发布
calculate_data.push(1, 2)

# 启动消费
calculate_data.consume()

门面一体：一个 @boost 对象同时具备本地调用、发布（fun.push(x, y)）、消费、队列运维全部能力。去掉 @boost 装饰器，函数退化为普通函数——框架零侵入、可拆卸。上下文走 fct.task_id 而非 bind=True 侵入签名。

20.2 🏛️ 去中心化：无全局 app，import 即注册

🏷️

🐢 Celery 集权式

✨ funboost 联邦式

中心对象

全局 Celery(app) 实例

无——每个 @boost 函数自洽

注册机制

include/imports 字符串列表

import 模块即完成注册

路由配置

task_routes + task_queues

队列名在装饰器参数中声明

启动

命令行 celery -A proj worker ...

python xx.py

新增函数

修改 include 配置 + 重启 Worker

写新文件 + import + 启动

架构选择理由：去中心化消除了「函数→app→目录结构强制」的连锁约束。消费函数写在任意深层级文件夹下都行，不强制目录范式、不绑定固定工程脚手架。

20.3 🔌 万物皆可 Broker：直连 + 短调用链

funboost 内置 53 种 broker_kind，并支持 register_custom_broker() 注册自定义实现。

20.3.1 🌐 远超"多支持几种MQ"

🏷️ 类别

📝 代表

🏆 主流 MQ

RabbitMQ, Kafka, RocketMQ, NATS, Pulsar, NSQ, MQTT, SQS

🔴 Redis 系列

REDIS, REDIS_ACK_ABLE, REDIS_STREAM, REDIS_ZSET_DELAY

💾 数据库

MongoDB, PostgreSQL, MySQL(SQLAlchemy), SQLite

🔌 网络协议

TCP, UDP, HTTP, gRPC, WebSocket

🔮 事件驱动

MYSQL_CDC（Binlog 变更即消息）, WATCHDOG（文件变更即消息）

🦖 框架集成

Celery, Dramatiq, Huey, RQ, Kombu 皆可作为 funboost 的底层驱动

🧠 同进程

MEMORY_QUEUE——零序列化、同进程背压队列，让 @boost 在非分布式场景也有意义

💡 范式升维：传统队列是"有人 push 才执行"；funboost 通过 CDC/Watchdog/Socket 等，把"世界发生变化"直接变成可调度事件——从消息驱动走向事件驱动。

20.3.2 ⚡ 为什么不用 Kombu 统一抽象

Celery 通过 Kombu 提供统一 MQ 抽象，代价是多层转换损耗 + 绑死 Kombu 支持范围。funboost 选择直接操作各 MQ 原生三方包：

  • 从取消息到执行函数仅 3 层调用（_dispatch_task → _submit_task → _run → 用户函数）

  • 新增 Broker 只需实现 _dispatch_task 和少量钩子，不需要写 Kombu adapter

  • 自研 FlexibleThreadPool（有界队列背压 + 空闲缩容 + 按需扩容）与短调用链紧密配合

img_91.png

20.4 📦 纯 JSON 消息 + 执行模型透明

funboost 的消息体是开发者发布的原始参数 JSON（加 task_id/publish_time 等少量元数据），不包含 Python 模块路径、类名等框架私有信息。

执行模型的本质：fun(**消息字典) ——消费就是把消息体解包为关键字参数调用用户函数。

因此：

  • 非 funboost 发布的消息也能被消费（_user_convert_msg_before_run 清洗管道）

  • Java/Go 等异构系统可直接往队列写 JSON 触发 Python 函数

  • Canal/Debezium/Flink CDC 的 binlog 消息无需适配即可消费

  • funboost 也能作为万能发布者——对 53 种队列发送不带任何框架协议的原始消息

20.5 🛡️ 声明式控制 + OOP 扩展

第一层：声明意图

开发者通过 BoosterParams（Pydantic 模型，IDE 全补全）声明"想要什么"，框架负责"怎么实现"。30+ 种控制能力全部收束于参数模型，拒绝 *args/**kwargs 黑盒：

QPS 控频 · 分布式全局控频 · 心跳 ACK · 重试（基础/指数退避）· 死信队列 · 优先级 · 延时 · 任务过滤 · 函数超时 · 远程 Kill · 暂停/恢复 · RPC · 消息过期 · 结果持久化 · 定时 · 多进程 · ...

第二层：经典 OOP 无限定制

当内置行为不满足需求时，用户通过继承重写 Consumer/Publisher 任意方法（self.xxx 访问所有属性，100% 可定制）。

对比 Celery 只能用预留的 Signals 钩子网——没暴露 hook 就无法扩展。funboost 用子类化与组合替代散点事件列表。

已有 Mixin：熔断器、微批消费、Prometheus、OpenTelemetry、周期额度、告警通知。

20.6 🌐 PyPI 即生态：拒绝封闭插件宇宙

核心立场：funboost 不发明 Middleware/Pipeline/Extension 等"只有框架形态才能进场"的墙。

业务函数体内 import 任意 PyPI 三方包（Playwright、httpx、Pandas、TensorFlow...），零适配成本——因为 funboost 调度的是函数本身，不限制函数内部做什么。

💡 funboost 认为 PyPI 海量三方包就是最大的"插件生态"，框架不应该在用户和 PyPI 之间竖一道墙。

20.7 🚀 从任务队列到 FaaS 平台

设计取舍：传统任务队列的边界止于"接收消息并执行"；funboost 选择向上延伸——管理面与执行面解耦（Web 端通过 Redis 元数据动态发现消费函数，无需共享代码），让同一套 @boost 函数既能异步消费、也能被 HTTP 同步调用。

funboost 自我定位不是"后台 Worker"，而是可私有化部署的函数计算平台 + 轻量 DevOps 系统（详见 c13 funweb、c15 FaaS 章节）。

20.8 🧠 定位：通用函数调度平台

funboost 调度的是函数逻辑，而非某种特定的请求类型。

🏷️ 场景

📝 说明

🤖 AI 推理

GPU 任务排队、QPS 限速保护 API

📊 数据处理

ETL 流水线、报表生成

📧 通知服务

邮件/短信/推送异步发送

🕷️ 分布式爬虫

配合 boost_spider / funspider 做高并发采集

📈 量化交易

行情事件驱动 + 严格控频下单

🔄 CDC 事件

MYSQL_CDC Broker 监听 Binlog 变更触发处理

☁️ FaaS

通过 HTTP 接口暴露任意函数为微服务

20.9 👑 总结

funboost 将 消息队列、任务调度、函数即服务、分布式控频、并发池、RPC 等复杂分布式能力，统一封装为一个 @boost 装饰器。

✅ 核心价值

📝 一句话

🎯 极简

一个装饰器上手，无八股配置，无中心 app

💪 极强

53 种 Broker，多进程叠加并发，30+ 种任务控制功能

🛡️ 极稳

心跳 ACK，进程崩溃秒级回收孤儿消息

⚡ 极快

从取消息到执行函数仅 3 层调用 + 自研高性能并发池

💡 极友好

Pydantic 配置全部 IDE 可补全，拒绝黑盒 *args/**kwargs

🔓 极自由

零目录约束，纯 JSON 跨语言，PyPI 即生态

🌐 极开放

事件驱动、CDC、跨语言——不只是"Python 任务队列"