JC-IM 自研业务中台说明 更新时间：2026-07-12 03:54 +07 一、先说结论 JC-IM 项目采用“OpenIM 做消息底座 + 自研业务中台做业务规则”的架构。 OpenIM 主要解决“即时通讯能力”，例如发消息、收消息、单聊、群聊、消息历史、在线连接、文件消息等。 自研业务中台主要解决“这个产品自己的业务规则、运营管理、权限体系、商业化能力和客户端发布管理”。这些内容不是 OpenIM 原生要解决的问题，也不建议硬塞进 OpenIM 的原生数据库结构里。 管理后台-自研版不是从零另起一个只有业务功能的后台，而是以管理后台-OpenIM原生版为底座复制和延展。OpenIM 原生后台已有的用户、群组、组织等管理功能需要保留，自研业务能力在这个基础上继续叠加。 可以理解为： OpenIM = 通讯发动机 业务中台 = 产品大脑和管理系统 二、为什么不能只用 OpenIM OpenIM 是一个 IM 消息底座，它很适合负责聊天相关能力： 1. 用户之间发送文本、图片、文件等消息 2. 单聊、群聊、会话列表 3. 消息存储、消息同步、已读未读 4. 好友、群组等 IM 基础关系 5. WebSocket 长连接和多端消息同步 但是一个完整产品不只是“聊天”。实际运营中会有大量与 IM 相关、但不属于 IM 底层的问题，例如： 1. 用户是否实名 2. 用户属于哪个公司、部门、岗位 3. 哪些人可以创建群、解散群、查看报表 4. 被举报的消息如何审核 5. 用户违规后如何封禁、限流、解除封禁 6. App 是否强制升级 7. 哪些用户可以使用高级功能 8. 是否有会员、套餐、订单、支付、账单 9. 企业客户如何开通、续费、停用 10. 管理员做过哪些操作，如何追溯 这些都需要由自研业务中台来处理。 三、业务中台具体做什么 1. 账号扩展 OpenIM 可以有用户账号，但我们的产品通常还需要更多用户资料和状态。 业务中台可以管理： - 会员等级 - 实名认证状态 - 用户来源渠道 - 邀请码和邀请关系 - 用户标签 - 设备绑定 - 登录设备列表 - 黑名单 - 风险等级 - 用户状态：正常、禁用、冻结、注销中 举例： 用户在 OpenIM 里可以发消息，但业务中台可以判断这个用户是否已经实名、是否被封禁、是否允许创建群、是否允许上传文件。 2. 组织和权限 如果产品以后面向企业、机构、团队或内部管理，就需要组织和权限体系。 业务中台可以管理： - 公司 - 部门 - 岗位 - 员工 - 管理员角色 - 角色权限 - 数据可见范围 - 员工入职、离职、禁用 - 部门群自动创建 - 组织通讯录 举例： OpenIM 可以负责“把某些人拉进一个群”。 但“哪些员工属于哪个部门、谁有权限建部门群、离职后是否自动退出所有群”，这些应该由业务中台决定。 3. 运营审核 IM 产品上线后，运营和风控是必须考虑的。 业务中台可以管理： - 用户举报 - 群举报 - 敏感词 - 违规消息记录 - 封号记录 - 解封申请 - 群资料审核 - 用户头像审核 - 用户昵称审核 - 操作日志 - 管理员处理记录 举例： 用户举报一条消息后，OpenIM 可以提供消息内容和消息 ID。 业务中台负责记录举报工单、分配给审核人员、判断是否违规、决定封禁用户或解散群。 4. 商业业务 如果项目后续涉及付费、企业版、增值功能，就必须有业务中台。 业务中台可以管理： - 套餐 - 订单 - 支付 - 退款 - 发票 - 余额 - 账单 - 企业客户 - 商户配置 - 开通时间 - 到期时间 - 功能额度 - 存储空间额度 - 群人数上限 - API 调用额度 举例： 某企业购买了 500 人版本。 OpenIM 只负责聊天能力。 业务中台负责判断这个企业是否已经付费、是否到期、还能不能新增员工、群人数是否超过套餐限制。 5. 客户端发布管理 项目规划中有很多客户端，包括 Android、iOS、鸿蒙、Web、H5、PC、Mac、Linux、iPad、Android Pad、Watch、Car、TV、XR 等。 业务中台可以统一管理： - Android APK / AAB 版本 - iOS IPA / App Store 版本 - 鸿蒙 HAP 版本 - H5 版本 - Web 版本 - 桌面端版本 - 最新版本号 - 最低可用版本号 - 是否强制升级 - 灰度发布比例 - 下载地址 - 更新说明 - 安装包 SHA256 - 版本回滚记录 举例： Android v1.0.3 有严重 bug，需要强制升级到 v1.0.4。 这个判断和提示不应该写死在 App 里，而应该由业务中台下发配置。 6. 自研管理后台 OpenIM 原生管理后台主要管理 OpenIM 自己的用户、群组、组织等。 但我们自己的管理后台应该管理产品自己的业务。 自研管理后台可以包含： - 用户管理 - 组织管理 - 角色权限 - 审核中心 - 举报处理 - 客户管理 - 套餐管理 - 订单管理 - 版本发布 - 公告管理 - 系统配置 - 数据统计 - 操作日志 举例： OpenIM 原生后台适合看 OpenIM 的用户和群。 自研后台适合运营、客服、财务、管理员等不同角色使用，处理真实业务流程。 四、OpenIM 和业务中台如何配合 典型流程如下： 1. 用户注册 用户在 App 注册。 业务中台记录用户来源、邀请码、实名状态、设备信息。 业务中台再调用 OpenIM Chat API 创建或同步 OpenIM 账号。 2. 用户登录 用户登录时，业务中台先判断用户是否正常、是否被封、是否需要强制升级。 通过后，再给用户 OpenIM 登录所需信息。 3. 创建群 用户点击创建群。 业务中台判断用户是否有权限、群人数是否超限、是否触发风控。 通过后，业务中台调用 OpenIM API 创建群。 4. 举报消息 用户举报某条消息。 OpenIM 提供消息 ID 和消息内容。 业务中台生成举报工单，审核人员在自研后台处理。 5. 企业到期 某企业套餐到期。 业务中台限制企业新增成员或高级功能。 OpenIM 仍负责基础消息能力，但业务规则由业务中台控制。 五、为什么建议业务中台使用独立 MySQL 当前测试机原本已有一套野火 IM 和 MySQL。 OpenIM 当前使用 MongoDB、Redis、Kafka、etcd、MinIO 等组件。 后续自研业务中台建议使用独立 MySQL，原因如下： 1. 不污染旧野火 IM 的数据库 2. 不影响 OpenIM 原生 MongoDB 结构 3. 业务表更适合用 MySQL 管理，例如订单、权限、审核、配置、日志 4. 方便备份、迁移、权限控制 5. 方便自研后台查询、分页、统计和报表 6. 后续上线正式环境时更容易拆分和扩容 建议结构： OpenIM 原生数据：MongoDB OpenIM 缓存和状态：Redis OpenIM 消息队列：Kafka OpenIM 服务发现：etcd 文件对象存储：MinIO 自研业务中台数据：独立 MySQL 六、哪些数据放 OpenIM，哪些数据放业务中台 适合放 OpenIM： - IM 用户基础信息 - 好友关系 - 群组信息 - 群成员 - 消息记录 - 会话相关数据 - OpenIM 自己需要的配置和状态 适合放业务中台： - 会员等级 - 实名认证 - 邀请关系 - 组织架构 - 角色权限 - 订单支付 - 套餐额度 - 审核工单 - 举报记录 - 封禁记录 - 客户资料 - 运营配置 - App 版本发布 - 公告 - 操作日志 - 统计报表 七、一句话说明 我们不是只做一个聊天工具，而是在 OpenIM 消息底座之上做一套可运营、可管理、可扩展的 IM 产品。 OpenIM 解决消息收发问题。 自研业务中台解决产品管理、权限、审核、商业化、版本发布和运营支撑问题。 这样后续无论是做企业 IM、社交 IM、客服系统、直播互动、RTC 音视频、会员体系，还是多客户端发布，都有自己的业务控制层，不会被 OpenIM 原生能力限制。 八、当前阶段建议 第一阶段： - 继续稳定 Android、Web、自研登录注册、OpenIM 消息链路 - 明确自研管理后台需要哪些菜单 - 设计业务中台数据库表 - 准备独立 MySQL Docker，给自研业务中台使用 第二阶段： - 建立自研业务 API - 建立自研管理后台 - 接入用户扩展资料、角色权限、版本发布 - 与 OpenIM Chat API / Admin API 做账号和群组联动 第三阶段： - 接入审核、风控、订单、套餐、数据统计 - 接入直播和 RTC 媒体服务 - 支撑 PC、Mac、Linux、iPad、Pad、Watch、Car、TV、XR 等更多客户端 九、最终目标 最终系统应该形成三层： 第一层：OpenIM 消息底座 负责稳定的即时通讯能力。 第二层：自研业务中台 负责产品自己的业务规则、数据、权限、运营和商业化。 第三层：多端客户端 包括 Android、iOS、鸿蒙、Web、H5、桌面端、Pad、Watch、Car、TV、XR 等。 这样架构清晰，后续扩展不会混乱，也方便对外说明项目价值。