首页区块链技术和DeFi研究

从 Merithra 到服务边界：链上后端框架的五年演进

• 数据时间：2026-06-24 Asia/Shanghai
• 研究对象：Merithra Framework、BitFi Backend、下一代链上后端服务化架构
• 报告类型：区块链技术和DeFi研究博客
• 资料来源：BitFi Backend 文档、Merithra Framework 演进整理、BitFi Backend 与下一代后端核心源码入口

一句话

Merithra 的演进不是从零搭了几个相似项目，而是从 2021 年的跨链监听和补偿执行，逐步沉淀出一条稳定的链上后端框架主线：Indexer / Syncer 负责把链上事实落地，Collector 负责把原始事件转成业务语义，API 负责把可消费的数据和管理动作暴露给产品、集成方和运营系统。

到 bitfi-backend 1.4.x，这条主线已经能承载 EVM、BTC、Sui、bfBTC、bfUSD、BFI、points、management、monitor 等多个业务域。到下一代架构，重点不再是继续往框架里塞更多功能，而是把 indexer、API、执行面、市场数据、WebSocket、鉴权、缓存和依赖上下文拆成边界更清晰的服务。

这条演进线真正稳定的东西

如果只看项目名称，2021 到 2026 像是几段不同业务：跨链 DEX、NFT 数据服务、points campaign、异构链资产平台、交易和执行后端。但把目录结构、启动入口和数据流放在一起看，会发现长期稳定的其实是三层：

层级	早期形态	成熟形态	关键职责
链上事实入口	Listener / Syncer	Indexer / Syncer	读取链上事件、维护 checkpoint、保留接近原貌的 raw data
业务语义层	Worker / Runner	Collector	聚合、关联、计算业务状态、写入业务表
交付层	内部查询接口	Public / External / Management / Points API	按受众和风险级别暴露查询、审批和管理能力

缓存、鉴权、WebSocket、执行编排、积分规则、钱包代理、多链适配和监控告警，都可以围绕这三层生长。但如果这三层没有分清，后面的能力越多，系统越容易变成一团共享状态。

2021：先把链上事件和执行闭环跑通

第一代系统更接近一个跨链同步和补偿执行器。核心场景是 BSC 与 AVAX 之间的 Swap 状态同步：listener 按块轮询链上事件，把事件和交易状态写入数据库；runner 再读取这些状态，比较双链储备，触发补偿或同步动作。

这一代的价值不在抽象有多漂亮，而在它已经抓住了链上系统的几个硬问题：

• 链上事件必须落库，不能只存在内存任务里。
• 多链 provider、签名器、Gas 策略和失败恢复必须被系统性处理。
• 执行动作不能脱离状态机，否则无法解释为什么补偿、补偿到哪一步、失败后从哪里恢复。

所以 2021 年的关键词不是“平台”，而是“闭环”。先有可恢复的链上执行闭环，后面才有资格谈框架。

2022：从链上机器人走向数据平台

2022 年的数据服务把问题规模推大了。系统不再只是同步某个协议的事件，还要处理 NFT 全网数据、metadata、资源文件、检索和监控。启动角色拆成 syncer / worker / fetcher，存储也从单一关系型数据库扩展到 Postgres、MongoDB、S3、Elasticsearch、Prometheus、Sentry 等多种组件。

这一步很关键，因为它把框架从“链上机器人”推向“链上数据平台”：

• Syncer 负责链上原始数据入口。
• Worker 开始承担事件后处理和业务模型转换。
• Fetcher 把链下 metadata 和资源处理从主同步链路拆出来。
• 监控与错误追踪开始成为系统能力，而不是上线后的临时补丁。

后来的 Collector 思想已经在这里出现雏形：链上事实是一层，业务可用的数据是另一层，中间必须有明确的转换层。

2023：Collector 成为框架转折点

真正的框架拐点出现在 2023 年前后。系统开始清晰拆出 boot_syncer / boot_collector / boot_api，并把 points 规则、统计聚合和业务语义处理放入 Collector，而不是散落在同步器或接口里。

这件事看起来只是命名变化，实际是架构重心变化。

Syncer 的输出应该接近链上原貌：什么合约、什么事件、哪个区块、哪个交易、同步到哪个 checkpoint。它不应该承担太多产品语义，因为链上事件的意义会随着业务规则变化。

Collector 的职责则是把事件变成业务状态：用户积分、任务完成情况、余额快照、收益统计、withdraw 状态、epoch 变化。这一层开始维护自己的 checkpoint，说明它不再是一次性的 worker，而是系统里和 syncer 平级的长期运行单元。

这也是从“项目代码”走向“框架代码”的开始。统一的 syncer、collector、API 基类，加上 codegen，意味着每个新协议不再是一套临时脚本，而是框架的一个实例。

2024：从单业务后端到平台型 campaign backend

到 2024 年，系统进入多协议、多 partner、多规则的 campaign / points 平台阶段。启动入口进一步演进到 starter/，framework/ 层开始收拢 database、protocol config、redis、blockchain、kafka 等公共能力。

这时的复杂度已经不只是“多几个任务”：

维度	新增复杂度	框架变化
协议	多协议、多活动、多 partner	protocol_config 驱动接入
规则	points、推荐、wallet、check-in、NFT、桥接	Collector 注册和分类管理
存储	主业务库、分析库、ClickHouse、Redis	多数据源治理
访问	API key、用户查询、活动数据	鉴权和缓存开始平台化

这一代的意义是：框架开始服务产品矩阵，而不是只服务单一协议。平台化之后，最难的问题往往不是“某个规则怎么算”，而是规则之间如何隔离、配置如何驱动、数据如何复用、接口如何稳定演进。

2024-2026：BitFi Backend 把框架推到异构链资产平台

bitfi-backend 1.4.x 是 Merithra 1.x 最成熟的一代。它的主链路稳定为：

syncer -> raw event tables -> collector -> business tables -> APIs

这一代的业务域已经从 campaign 扩展到异构链资产平台：bfBTC、bfUSD、BFI 和 points 并存，EVM、BTC、Sui 被纳入同一平台骨架。源码入口也能看到服务按职责拆分为 syncer / mempool / public_api / external_api / management / points / points_api / monitor。

这种拆分有两个价值。

第一，风险边界更清楚。Public API 和 External API 以只读查询为主；Management API 面向内部审批和管理动作；monitor 负责告警；历史 automation 被保留但不再混同为标准运行路径。对于链上资产平台来说，这种边界比“接口都能调通”更重要，因为查询、审批、执行和告警的风险级别完全不同。

第二，多链差异被收敛到 capability 和 blockchain abstraction。某条 EVM 链是否启用 bfBTC、bfUSD、BFI，不是靠接口层临时判断，而是由链配置和 capability 决定。Sui 和 BTC 也有自己的链能力封装。这样做的结果是，业务模块可以按能力注册，框架则负责初始化、配置、数据库和链上下文。

成熟框架的标志不是完全没有业务代码，而是业务代码能被放到正确的位置：链上事实在 syncer，业务状态在 collector，产品接口在 API，管理动作有单独入口，监控告警不和主查询路径搅在一起。

2026：下一代重点是服务边界，不是功能堆叠

下一代后端样本的变化很明显：indexer 独立，backend 通过 SERVICE_MODE 拆成 api-public / api-admin / market-data / execution / ws 等模式；运行时上下文由 app context factory 和 registry 管理；鉴权走 policy-driven middleware；Redis 作为高速缓存和 WebSocket 扇出中枢。

这不是简单换一套目录名，而是从“框架内聚”走向“服务边界清晰”：

旧阶段关注	下一代关注
一个后台能启动多个能力	不同服务按扩容属性和风险属性拆分
框架内部统一初始化	runtime context 和 dependency registry 管理生命周期
API 层各自处理鉴权	策略化鉴权和统一请求上下文
业务后台直接同步链上事件	独立 indexer 成为链上事件唯一入口
缓存是接口优化项	Redis 成为缓存和实时分发基础设施

这一步的核心判断是：当系统已经能承载多链、多业务域和多 API 边界以后，继续把所有能力揉进同一个进程组，会让长期维护和安全治理变难。下一代架构要解决的不是“能不能做”，而是“不同风险、不同吞吐、不同生命周期的模块能不能分开治理”。

最重要的抽象其实是 Collector

很多链上后端都会重视 indexer，因为它决定数据是否完整；也会重视 API，因为它直接面对产品。但 Merithra 演进里最有价值的抽象，反而是 Collector。

原因很简单：链上事件本身不是业务事实。

一笔 mint 事件、withdraw 事件、staking 事件、epoch update 事件，只有经过关联、补时间、聚合、去重、状态推进之后，才会变成用户能理解、运营能处理、管理后台能审批的业务对象。把这些逻辑放在 API 里，会导致每次查询都重复解释历史；把它们塞进 syncer，又会污染原始事实层。

Collector 的存在让系统有了一个稳定中间层：

• 上游可以保留链上原貌，便于回放和重新计算。
• 下游可以消费业务表，不需要理解每个协议事件细节。
• 规则变化可以通过 collector 重新聚合，而不是重写同步器或接口。
• 多业务域可以共享同一套 raw data，但各自维护不同的业务状态。

这就是为什么 Indexer / Collector / API 比单纯的“同步器加接口”更像框架。

这条演进给链上后端的几个启示

第一，链上系统要先有可恢复的状态闭环，再谈平台化。没有 checkpoint、落库状态和失败恢复，抽象越多越危险。

第二，原始事实和业务语义必须分层。链上事件要尽量接近原貌保存，业务判断和产品状态放到 collector，接口只消费已经整理好的业务表。

第三，服务边界应该按风险和扩容属性拆，而不是按代码文件大小拆。只读查询、管理审批、执行路径、WebSocket、市场数据、monitor 的运行特征不同，部署边界也应该不同。

第四，配置驱动不是为了少写代码，而是为了让多协议、多链、多活动的差异有可审计入口。没有配置边界的“灵活”，最后会变成不可追踪的分支逻辑。

第五，下一步最值得补的是统一测试框架。Merithra 的生产主线已经证明了三层架构和多业务治理能力，后续真正提升企业级可维护性的，不是整体重写，而是为 indexer、collector、API、鉴权、缓存和执行面建立可回放、可隔离、可自动验证的测试体系。

结语

Merithra 1.x 的价值，不只是它支撑过多个项目，而是它把链上后端里最容易混在一起的三件事分开了：链上事实、业务语义和产品交付。

从 2021 年的 listener 和 runner，到 2022 年的数据平台，再到 2023-2026 年的 Syncer / Collector / API 生产主线，最后进入独立 indexer、模块化 API、策略化鉴权、Redis 缓存和服务化边界，这条演进线说明一个成熟链上框架不是靠一次设计完成的，而是在真实业务压力、风险场景和长期维护中逐步长出来的。

下一阶段最好的方向也很清楚：保留已经验证过的 Indexer / Collector / API 内核，把依赖注入、鉴权策略、缓存层和测试框架继续沉淀成公共基础设施；对于极致性能或执行隔离要求更高的内部平面，再逐步评估 Rust 化，而不是为了“下一代”而整体重写。