开源通信核心 · Apache-2.0
强大·简洁·稳定·通用
开源通信三层栈,一条链路嵌入你的业务。高性能长连接与 seq 有序投递保障稳定;IMClient 统一入口、栈可裁剪,接入足够简洁——从协作、客服到行业系统,场景通用。
强大 · 高并发长连接
简洁 · 三层栈统一 API
稳定 · seq 有序投递
通用 · 任意业务可嵌入
消息通道
同步编排器已上线,会话增量同步正常
ack · read · sync · offline
开源 · 可集成
通信核心与业务域分离
Apache-2.0 的 flare-core / flare-im-core / SDK 可独立接入你的系统;含协议语义与 API 速查。
开源范围 · 说在前面
通信这一层全部开源,账号体系由你自带
免得你评估到一半才发现:开源的是通信基础设施,不含账号体系。但它自带完整且可插拔的鉴权契约——手签一个 token 就能跑起来做 POC,不需要任何用户体系。
开源范围(Apache-2.0)
协议 · 传输 · 服务端 · 6 个客户端 SDK(Kotlin / Swift / Dart / TypeScript / ArkTS / 仓颉)· 跨端 UI Kit · 鉴权与 hooks 契约
- 不设人数、连接数、消息量限制
- 鉴权与 hooks 契约永远开源,不会为逼迫付费而阉割
- 已发布的内容不会被追溯收回
需要你自带的部分
账号体系 · 好友关系 · 群治理(角色/审批/禁言)· 朋友圈
- 多数团队已经有账号体系了——接上即可,不必重建
- 没有也不挡路:手签 token 就能先跑通评估
自带身份:两种接法,都在开源侧
CoreJwtTokenValidator本地验 JWT。你的用户系统用同一密钥签发即可,改配置不改代码。
HttpHookTokenValidator把 token POST 到你自己的接口去验。适合已有独立鉴权服务的场景。
五分钟跑通 · 已实测
不搭用户体系,也能先跑起来
下面每条命令都在 macOS 上实跑验证过。手签一个 token 即可调通接口——评估阶段不需要先接入你的账号系统。
起服务并调通
- 01起依赖(只需 Consul / Redis / Postgres / NATS / RustFS 五个)
docker compose -f deploy/docker-compose.yml up -d \ consul redis postgres nats rustfs - 02起 IM 微服务
./scripts/start_server.sh - 03签一个接入 token(密钥由上一步生成;签名工具在同级仓 flare-server-core)
export FLARE_TOKEN_SECRET="$(cat logs/.dev-token-secret)" cd ../flare-server-core TOKEN=$(cargo run -q --example mint_token -- alice) - 04调接口验证
curl -H "Authorization: Bearer $TOKEN" \ http://127.0.0.1:50050/api/v1/conversations
实测结果:带 token 返回 200,不带 token 与伪造 token 均返回 401。
或直接装包
Rust 服务端与客户端核心
cargo add flare-core # 1.1.1
cargo add flare-im-core-sdk # 1.2.0TypeScript SDK 与 Vue 组件库
npm i @flare-im/sdk # 1.0.6
npm i @flare-im/vue-ui # 1.0.9IM 核心插件
消息与会话 — 已实现的核心能力
有序消息、会话状态与多端同步。三层开源栈可裁剪:仅传输、仅客户端或完整私有化部署。
App + PC 实时协同
双端收发消息动效
架构组
tenant=0 · conversation=ops
App 会话
已同步
- 01
消息引擎
每会话 max_seq 单调递增;幂等发送;禁止 seq 回退。
- 02
会话模型
会话列表、未读、置顶与免打扰;由 flare-conversation 统一投影。
- 03
多端同步
通过 syncMessages(conversation_id, last_seq) 游标增量拉取,不使用偏移分页。
- 04
离线与一致性
JetStream 领域事件驱动,最终一致,支持重放补偿。
开发者优先
Client SDK — 几行代码接入 IM
各端统一 FlareImClient:init → login → events.on* → messageBuilder.buildText → messages.sendMessage → sync。Flutter / TypeScript / Swift / Android 共用一套 API 与模型。
一期 Client 接入路径
接入生命周期
覆盖平台
App 日常接入请直接使用对应平台的 Client SDK;SDK 已封装连接、同步、离线恢复和事件监听。
import 'package:flare_core_flutter_sdk/flare_core_flutter_sdk.dart';
// 1. 创建客户端 → init → login
final client = FlareCoreSdk.createClient();
await client.init({'wsUrl': 'wss://im.example.com/ws'});
await client.login({'userId': 'user_a', 'token': token});
// 2. 监听:消息 / 连接 / 会话
final subMsg = client.events.onMessageReceived((event) {
final msg = event.message;
renderMessage(msg.conversationId, msg.timelineKey, msg.content);
});
final subConn = client.events.onConnectReady((event) {
showStatus(event.state);
});
client.events.onTotalUnreadMessageCountChanged((event) {
updateBadge(event.conversation?.unreadCount ?? 0);
});
// 3. 拉会话 & 发消息
final list = await client.conversations.listConversations();
final draft = await client.messageBuilder.buildText(
BuildTextMessageRequest(conversationId: convId, text: 'Hello Flare'),
);
final ack = await client.messages.sendMessage(
SendMessageRequest(message: draft),
);
markSent(ack.clientMsgId, ack.seq);
// 4. 同步 & 释放监听
await client.sync.syncConversationSummaries();
subMsg.unsubscribe();
subConn.unsubscribe();
await client.logout();
await client.dispose();架构
事件驱动微服务
接入 → 编排 → JetStream → 存储;状态变更经领域事件驱动,禁止服务直连改库。
禁止服务直连 — 状态变更经领域事件:命令 → 聚合 → 事件 → 处理器
命令 / 事件流水线
01
客户端
网页 · 移动 · 桌面
02
接入层
业务网关 · 信令
03
IM 核心
路由 · 编排
04
JetStream
事件总线
05
存储
写入 · 查询
能力
核心能力一览
消息、会话、同步、在线与安全传输 — 生产级 IM 主干能力一览。
即时消息
编排与存储链路打通;基于 seq 的有序投递与幂等。
会话系统
单聊/群聊会话态、未读、最近会话;读写分离(CQRS)。
群组
大群、@提醒、成员与权限;会话聚合根可扩展。
全局同步
基于 last_seq 的增量拉取与多端漫游。
在线状态
经 flare-signaling/online 提供在线态,多设备策略可配置。
安全传输
令牌鉴权、TLS;端到端加密能力可扩展。
完整 API 与接入步骤见文档中心 /docs/core。
性能
为规模而设计
以下为架构演进方向,非固定服务等级协议;请以实际监控与压测为准。
0ms
P99 消息延迟目标
0M+
并发连接设计方向
0%
可用性架构目标
0
客户端 SDK 语言
一期 Client
一套 API,覆盖主流客户端
flare-core-flutter-sdk · @flare-im/sdk · flare-core-apple-sdk · flare-core-android-sdk。业务 App 用一期 Client SDK 即可。
开源生态
单仓模块化开源
flare-core、flare-im-core、flare-im-core-sdk 与 flare-proto,按需裁剪组合。
参与进来
从跑通到提交,路径是明的
不用先问「我该从哪开始」。报问题、报漏洞、提代码各有入口,提交前要跑什么也写在下面——与 CI 同一套,不会到 review 阶段才被告知。
报个问题
用起来不对劲、文档说的和实际不符、缺个能力——都开 issue。说清楚复现步骤比说清楚原因更有用。
去提 issue →报安全漏洞
请走私密渠道,不要开公开 issue:公开会在修复发布前把所有使用者暴露出去。GitHub Security Advisory 或邮件均可。
看披露流程 →提代码
项目分成多个仓库,CONTRIBUTING 里有一张表告诉你改动该去哪个仓,以及分层纪律:同一逻辑不要在多端各写一遍。
看贡献指南 →提交前跑这条
CI 跑的就是它。本地过了,PR 大概率也过——这条命令的存在是为了让你不必靠猜。
cargo fmt --all -- --check && cargo clippy --all-targets -- -D warnings && cargo testnpm run typecheck && npm testCI 另有一条与主流程解耦的供应链审计(cargo audit / cargo deny):advisory 数据库每天在变,不该因为上游新披露的 CVE 就让一个无关的功能 PR 变红。
常见问题
常见问题
什么是 IM 核心插件?
指 flare-im-core 提供的消息与会话主干能力,可作为独立模块嵌入业务后端,通过 gRPC 或领域事件与现有系统对接。
如何嵌入现有业务系统?
按 /docs/core 选型:仅长连接用 flare-core;完整 IM 用 SDK + 自建或托管 flare-im-core;业务逻辑通过 Hook / gRPC 扩展,无需 fork 核心代码。
消息顺序如何保证?
每个会话维护单调递增的 max_seq;客户端通过 syncMessages(conversation_id, last_seq) 做增量同步。
支持哪些客户端?
一期支持 Web、Tauri、iOS、Android 和 Flutter,业务侧使用统一 Client SDK 接入。
能否私有化部署?
可以。flare-im-core/deploy 提供 Docker Compose 与 Consul、JetStream、PostgreSQL 等模板。