Continuwuity 26.9.1 介绍与选型指南
Continuwuity(conduwuit 社区后继的轻量级 Matrix homeserver)介绍与选型:定位与血缘、单体架构与 RocksDB 存储、功能特性清单、适用场景与限制,以及与 Synapse/Conduit 系的量化选型对比,基于 2026-10-25 官方源实查。
Continuwuity 26.9.1 介绍与选型指南
目标:读完本文即可判断 Continuwuity 是否适合你的场景——它是谁、从哪来、核心架构与功能边界是什么、与 Synapse / Conduit 系等 Matrix homeserver 相比如何选型。本文为认知篇,全部信息均溯源官方渠道(官网、Forgejo 仓库、官方文档与 Releases 页,查询日期 2026-10-25),未做本地实测;安装与部署实操请见本专栏后续篇章。
一、环境信息(资料来源与查询口径)
本章说明本文全部事实性信息的来源与查询口径,便于读者复核。本文为认知篇,不做本地实测,所有版本号、镜像地址、特性清单均直接取自下列官方渠道,查询日期统一为 2026-10-25:
- 官方网站:https://continuwuity.org/ (项目定位、官方文档站,最后更新时间页面底部实时可见);
- 主仓库:https://forgejo.ellis.link/continuwuation/continuwuity (Forgejo 实例,组织名
continuwuation;截至查询日 Star 116、Fork 133、Release 42 个); - GitHub 镜像:https://github.com/continuwuity/continuwuity (官方页面注明 Star 操作指向 GitHub,代码发布与制品以 Forgejo 为主源);
- Releases 页:https://forgejo.ellis.link/continuwuation/continuwuity/releases (最新 Stable 版 v26.9.1,2026-09-28 发布,由维护者 nex GPG 签名,Key ID
0FA334385D0B689F); - 官方部署文档:https://continuwuity.org/deploying.html (部署形态清单、二进制与配置文件命名约定);
- 官方配置参考:https://continuwuity.org/reference/config.html (
conduwuit-example.toml全量配置项); - 官方维护文档:https://continuwuity.org/maintenance.html (管理命令形态、备份与媒体管理口径)。
💡 说明:Continuwuity 的版本号采用 CalVer(日历版本),格式为
年.月.序号,例如 v26.9.1 表示 2026 年 9 月的第 1 个稳定版。这与 Synapse 的语义化版本(1.x)不同,从版本号即可读出发布时间,判断新旧版本时先换算这一规则。
二、软件概述
本章回答「Continuwuity 是什么、从哪来」。它是一个社区驱动的 Matrix 联邦聊天服务器(homeserver),使用 Rust 语言编写,主打轻量、高性能与低资源占用。理解它必须理清三条血缘线:
- Conduit(Rust):Matrix 生态最早的轻量级 homeserver 实现,证明了「单二进制 + 嵌入式存储」跑 Matrix 的可行性,后维护节奏放缓;
- conduwuit(Rust):在 Conduit 基础上深度 fork 的性能强化版,长期由个人维护者驱动,性能与功能大幅领先上游,但于 2025 年停止维护(项目归档);
- Continuwuity(Rust):conduwuit 停更后由社区组建
continuwuation组织接续维护的社区后继(community successor),延续 conduwuit 的代码基线与配置兼容性,按 CalVer 稳定发版。截至 2026-10-25,最新稳定版 v26.9.1(2026-09-28 发布),此后 main 分支仍有持续提交,社区活跃。
三个易混事实在此一并澄清(均为官方口径实查):
- 二进制与配置文件名:Continuwuity 的可执行文件名仍是
conduwuit,默认配置文件名是conduwuit.toml(官方部署文档「Mind the name!」明确说明)。这是延续 conduwuit 命名的有意行为,不是文档写错; - 与 Conduit 的关系:Conduit 是另一个独立项目(本平台有独立专栏),Continuwuity 与 Conduit 仅有「同一血统的 fork 关系」,代码与配置并不互通;
- 与 Tuwunel 的关系:Tuwunel 是 conduwuit 停更后出现的另一个社区后继分支,与 Continuwuity 同源并行发展,选型时按维护方与发布节奏区分即可(见第七章对比)。
💡 技术拓展:Matrix 体系里的「服务器」不止一种角色,首次接触容易混淆——
角色 职责 典型实现 Homeserver(主服务器) 存放账号、房间状态与消息历史,参与联邦同步 Synapse、Conduit 系、Continuwuity Identity Server(身份服务器) 提供邮箱/手机号到 Matrix ID 的映射查找 vector.im 公共服务(可不用) Appservice(应用服务) 以「桥接」方式把其他平台接入 Matrix mautrix 系列桥 客户端 用户聊天界面 Element、Fluffychat 等 Continuwuity 承担的是 homeserver 角色:一个 Matrix 域名必须有且只有一个 homeserver,客户端与联邦流量都由它承接;桥接、身份服务是可选的外围组件。
三、核心架构
本章拆解 Continuwuity 的架构组成与关键设计取舍,帮助读者理解它「为什么轻、为什么快、边界在哪」。
3.1 单进程单体架构
Continuwuity 是一个单体(monolithic)架构:客户端 API、联邦 API、媒体仓库(media repository)与房间目录全部在同一个进程、同一个 HTTP 监听端口上提供服务。它不依赖任何外部数据库或缓存中间件,仅需要:
- 一个持久化目录(RocksDB 数据库 + 媒体文件,同根目录);
- 一个反向代理(官方文档示例用 Caddy,Nginx 亦常见)承担 TLS 终结与
.well-known委派。
对比 Synapse 需要 PostgreSQL(或 SQLite)+ Redis(联邦工作器场景)+ 多进程工作器的组合,Continuwuity 的部署面只有一个二进制 + 一个数据目录,这是其「易部署」标签的来源。
3.2 存储引擎:RocksDB
Continuwuity 的所有状态(账号、房间、事件流)与元数据存放在 RocksDB(Facebook 开源的嵌入式 KV 存储引擎,LevelDB 的 Rust 绑定封装),媒体文件直接落盘在数据库目录下的 media/ 子目录。官方维护文档给出的关键口径:
- RocksDB 的 Compaction(压实)由 Continuwuity 按内置阈值自动触发,不建议手动压实或定时器压实(会造成无谓的 I/O 放大);
- 编译时启用了 io_uring(via liburing)以提升读性能;
- 数据库目录下的
.log、.sst等文件是 RocksDB 内部文件,严禁人工删改(官方文档专门警告过用户误删 WAL 相关文件的事故); - 支持 RocksDB 在线备份(
!admin server命令 +database_backup_path配置)。
💡 技术拓展:homeserver 的存储引擎选型是各家实现的核心分歧点——
引擎 代表实现 特点 适用场景 PostgreSQL Synapse(推荐后端) 独立数据库服务,可专业运维、可扩展 已有 DBA 团队、大规模部署 SQLite Synapse(默认)、早期 Conduit 零运维单文件 极小规模、个人测试 RocksDB Continuwuity、Conduit 系 嵌入式 LSM-KV,写入吞吐高、无独立进程 单实例自托管、资源敏感场景 Continuwuity 采用 RocksDB,理由是嵌入形态免去了独立数据库进程的运维面,同时 LSM 引擎对消息追加写(append-heavy)负载友好;代价是数据库与进程同生命周期、横向扩展无从谈起(见 3.3)。
3.3 扩展性边界:明确不支持水平扩展
官方 Kubernetes 部署文档开篇即声明:Continuwuity 原生不支持水平扩展(horizontal scalability)或分布式负载。整个服务是单实例形态,扩容方向只有「纵向」(加 CPU/内存/磁盘)。这不是缺陷隐瞒而是架构事实:RocksDB 嵌入式存储决定了状态只能在单节点上。因此:
- 适合:个人、家庭、中小团队/社区(几百到几千用户量级的自托管场景);
- 不适合:对高可用(HA)、多活容灾有硬性要求的大型部署(该场景应选 Synapse + PostgreSQL 主从/工作器架构)。
3.4 协议覆盖与管理形态
- 房间版本:官方支持 Matrix room versions 6–12,默认
default_room_version = "12"(官方配置参考实查); - 联邦:完整参与 Matrix 联邦网络,v26.9.1 修复了一个影响所有联邦部署的关键安全漏洞(官方建议无法升级者临时
allow_federation = false或在反代封禁联邦路由); - 管理形态:官方维护文档明确——管理操作通过 admin room 管理命令(在与管理 bot 的会话房间里发送
!admin前缀命令,如!admin users、!admin rooms moderation、!admin media);「独立二进制管理命令」与「admin API」在官方路线图中处于**计划(planned)**状态,截至查询日尚未落地。这一事实决定了本平台对该组件的运维篇按 Matrix Client-Server API 展开(见《Continuwuity 26.9.1 API 使用详解》); - 推送:v26.9.1 起内置加密 Web Push(MSC4174)并默认启用,手机端可在无常驻连接时收到推送;
- 应用服务:支持 Matrix appservice 协议,可接入 Discord、Telegram 等平台桥。
四、功能特性
本章汇总官方渠道可确认的功能清单,并标注来源。总体上 Continuwuity 的功能主张是「以极小资源占用提供完整 Matrix 体验」,具体如下:
| 功能 | 说明 | 来源 |
|---|---|---|
| Matrix 联邦 | 完整联邦协议,room versions 6–12(默认 12) | 官方配置参考 |
| 单端口服务 | client API + federation API 共用一个 HTTP 端口 | 官方部署文档 |
| RocksDB 存储 | 嵌入式 KV,io_uring 加持,自动 Compaction | 官方维护文档 |
| 全量环境变量配置 | 每个配置项都有对应 CONTINUWUITY_* 大写环境变量(下划线映射双下划线) | 官方 K8s 文档 |
| admin room 管理 | !admin 命令族管理用户/房间/媒体/联邦 | 官方维护文档 |
| 加密 Web Push | MSC4174,v26.9.1 起默认启用 | v26.9.1 Release Notes |
| 应用服务桥接 | 接入 Discord/Telegram 等桥 | 官网 features |
| 多部署形态 | 通用二进制、Docker、Deb/RPM 包、NixOS、Arch、FreeBSD、Kubernetes、Nomad | 官方部署文档 |
| 多构建变体 | glibc 动态、musl 静态二进制,haswell/x86-64-v3「max-perf」变体 | v26.9.1 Release 制品清单 |
| 媒体治理 | 按 MXC URI/事件 ID/时间段/来源服务器删除媒体,媒体目录可挂 S3 文件系统 | 官方维护文档 |
| 在线备份 | RocksDB backup engine 在线热备(!admin server) | 官方维护文档 |
| DNS 调优指引 | 官方强烈建议联邦服务器配置本地缓存 DNS 解析器 | 官方部署文档 |
表格解读:这份清单的权重明显偏向「部署与运维简单性」——单端口、单二进制、单数据目录、环境变量全量配置,都在压缩部署与维护成本;而「横向扩展」「admin API」这类大型部署特性被明确放在了边界之外或路线图中。选型时应按自己团队的实际规模对照取含。
五、快速开始(最小可用示例)
本章给出官方文档口径的最小可用启动示例,让读者对「跑起来长什么样」建立直观认知。本章为认知篇转述(未本地实测),逐命令实测版请直接阅读本专栏部署篇。
官方 Docker 部署文档的最小形态是:一条 docker run 挂载数据目录与配置文件,映射一个端口(客户端与联邦共用):
docker run -d \
--name continuwuity \
-p 8448:6167 \
-v /var/lib/continuwuity:/var/lib/conduwuit \
forgejo.ellis.link/continuwuation/continuwuity:latest
要点解读(均来自官方文档口径):
- 镜像:官方主源是 Forgejo 自带 registry
forgejo.ellis.link/continuwuation/continuwuity,ghcr.io/continuwuity/continuwuity与 Docker Hubjadedblueeyes/continuwuity是官方承认的镜像源(官方注明镜像源可能滞后,生产建议主源或按 digest 固定); - 端口:容器内默认监听 6167,一个端口同时承载客户端与联邦流量;对外 8448 是 Matrix 联邦约定端口,配合
.well-known委派也可走 443; - 数据目录:数据库与媒体全部在挂载点内,备份即拷贝该目录;
- 配置:无配置文件也能以默认值启动,再通过挂载
conduwuit.toml或注入CONTINUWUITY_SERVER_NAME等环境变量逐项覆盖。
启动后的第一件事是在管理房间内用 !admin 命令创建账号、开关注册(官方维护文档口径)。完整的从零部署(含系统依赖、systemd 托管、反向代理与联邦验证)见《Ubuntu 22.04 安装 Continuwuity 26.9.1 指南》与《Continuwuity Docker Compose 部署指南》。
六、适用场景与限制
本章给出选型判断的「正面清单」与「负面清单」,全部对照官方文档口径与架构事实。
6.1 适用场景
- 个人/家庭/小团队自托管:一个 VPS(官方 K8s 示例的资源请求仅 2 vCPU / 512Mi 内存起步)即可承载完整联邦体验,无外部数据库依赖;
- 资源受限环境:旧服务器、NAS、小型云主机——Rust + RocksDB 的内存占用显著低于 Synapse(官方以「designed to run smoothly even on modest hardware」为主张);
- 从 conduwuit 平滑延续:conduwuit 已停更,Continuwuity 延续其代码基线与
conduwuit.toml配置兼容性,是既有 conduwuit 部署的现成去处; - 想要「装完就不用管」的联邦服务:自动 Compaction、在线备份、内置 Web Push 把日常运维面压到最小。
6.2 限制与注意事项
- 不支持水平扩展/HA(官方明示):状态在单节点 RocksDB 中,无法多副本分摊负载;对高可用有硬要求的场景选 Synapse;
- 无独立管理 CLI、admin API 仍在计划中(官方维护文档口径):一切管理操作依赖 admin room 聊天命令,自动化运维需走 Matrix Client-Server API 自行封装;
- 联邦安全需紧跟版本:v26.9.1 修复影响全部联邦部署的关键漏洞——选择 Continuwuity 就默认接受了「应跟随 main 或及时升级稳定版」的运维节奏(官方甚至鼓励生产直接跟随 main 分支);
- 升级可能触发后台迁移:v26.9.1 升级后有一次性数据库后台迁移,期间 CPU 与磁盘 I/O 显著升高、可能持续数小时(Release Notes 明示),容量规划要留余量;
- 生态位认知:第三方集成文档、商业支持多以 Synapse 为第一假设,Continuwuity 用户需自行验证桥/机器人兼容性。
七、同类选型对比
本章对 Matrix homeserver 生态的主要可选实现做量化对比,数据均标注查询口径(2026-10-25)。先给对比总表,再给「如果…则…」选型建议。
7.1 对比总表
| 维度 | Synapse | Dendrite | Conduit | conduwuit | Continuwuity | Tuwunel |
|---|---|---|---|---|---|---|
| 开发语言 | Python | Go | Rust | Rust | Rust | Rust |
| 维护方 | matrix.org(官方参考实现) | matrix.org 二方实现 | 原独立项目 | 个人维护者(已停止维护) | 社区组织 continuwuation | 社区分支 |
| 维护状态(2026-10-25) | 活跃 | 维护节奏放缓(以官方仓库为准) | 维护停滞 | 2025 年归档停更 | 活跃,v26.9.1(2026-09-28) | 活跃 |
| 版本策略 | 语义化版本 | 语义化版本 | 语义化版本 | 语义化版本 | CalVer(年.月.序) | 语义化版本 |
| 数据库 | PostgreSQL(推荐)/SQLite | PostgreSQL | RocksDB 等 | RocksDB | RocksDB | RocksDB |
| 外部依赖 | 需独立 DB(联邦场景加 Redis) | 需独立 DB | 无 | 无 | 无(单二进制+数据目录) | 无 |
| 水平扩展 | 支持(工作器架构) | 部分支持(实验性) | 否 | 否 | 否(官方明示) | 否 |
| 资源占用 | 较重 | 中 | 极轻 | 极轻 | 极轻(官方主张 modest hardware) | 极轻 |
| 管理面 | 管理 API/CLI 生态成熟 | 基础 | admin room | admin room | admin room 命令(admin API 规划中) | admin room |
| 一句话定位 | 功能最全的官方参考实现 | Go 生态尝试 | 轻量先驱(停滞) | 性能强化 fork(已终) | conduwuit 的社区后继主线 | conduwuit 另一后继 |
表格解读:这张表的本质分岔口有两条——第一条是要不要 HA/水平扩展:要则只有 Synapse 一条路;不要则全部轻量实现都可进入候选。第二条是轻量系里选谁:Conduit 已停滞、conduwuit 已终版,实际候选只剩 Continuwuity 与 Tuwunel 两个 conduwuit 后继,再按维护组织、发版节奏与社区口碑二选一即可。
7.2 量化参考数据
- Continuwuity:Forgejo 仓库 Star 116 / Fork 133 / Release 42 个(2026-10-25 实查仓库页);稳定版 v26.9.1 发布于 2026-09-28,main 分支在此之后仍有 100+ 提交(Releases 页实查),发版与修复节奏健康;
- conduwuit 终局:GitHub/Forgejo 归档状态,官方 README 由 Continuwuity 社区承接迁移指引;
- Synapse:Python 生态内以 PyPI 分发,版本节奏为月度级(具体最新版本号建议查询时以 https://pypi.org/project/matrix-synapse/ 实时为准,本文不硬编码以免失真)。
💡 说明:Star 数这类活跃度指标在「Forgejo 主仓 + GitHub 镜像」双仓库形态下会分散统计,不应直接与单一 GitHub 仓库的项目(如 Synapse)对比绝对值;更可靠的活跃度信号是 Release 频率与 main 分支提交密度(本文已按此口径给数)。
7.3 选型建议(如果…则…)
- 如果你要官方背书、插件/桥生态最全、有 DBA 可依赖 PostgreSQL → 选 Synapse;
- 如果你要单机轻量、零数据库依赖、配置一个文件、资源占用小 → 选 Continuwuity(本文主角);
- 如果你是既有 conduwuit 用户 → 直接平滑迁移 Continuwuity(配置文件同名同构,官方即后继);
- 如果你在 Kubernetes 中评估轻量 homeserver → Continuwuity 官方提供 StatefulSet 样例与社区 Helm Chart(见《Continuwuity Docker Compose 部署指南》末章 Kubernetes 形态附节);同时可对照评估 Tuwunel;
- 如果你追求绝对最小依赖的概念验证 → Continuwuity 单二进制静态版(musl)拷贝即用,是成本最低的 Matrix 体验路径。
八、参考链接
- 官网首页:https://continuwuity.org/
- 官方文档(部署):https://continuwuity.org/deploying.html
- 官方文档(维护/管理命令口径):https://continuwuity.org/maintenance.html
- 官方配置参考:https://continuwuity.org/reference/config.html
- Forgejo 主仓库:https://forgejo.ellis.link/continuwuation/continuwuity
- Forgejo Releases(v26.9.1 Release Notes 与制品清单):https://forgejo.ellis.link/continuwuation/continuwuity/releases
- GitHub 镜像:https://github.com/continuwuity/continuwuity
- Matrix 协议概念(matrix.org):https://matrix.org/docs/matrix-concepts/elements-of-matrix/
- 本专栏部署篇:《Ubuntu 22.04 安装 Continuwuity 26.9.1 指南》《Continuwuity Docker Compose 部署指南》《Continuwuity 26.9.1 配置参数详解》《Continuwuity 26.9.1 API 使用详解》(发布后可从专栏目录点击跳转)