架构讨论版 · 2026-09-28
中央统一管理，按企业划分完整业务服务区；每区独立业务数据库，区内 Worker 可横向扩展；邮件与文件基础设施独立。
多租户隔离与权限设计
新增六张权限专题图，配套 完整设计文档 与 Markdown 下载。均为待实施设计。
服务区开发文档
完整能力清单、组件职责、数据归属、六条流程和建议开发顺序见 服务区业务能力与流程开发说明 。仓库正文为 docs/service-zone-development.md，由地图构建自动生成网页与 Markdown 下载件。AI 编排与工具桥接标为待验证方案。
中央与服务区
中央负责统一 SSO、企业目录、成员权限和企业到服务区的分配，全局平台管理也归中央。按企业分区，不按用户永久绑定节点；同一企业成员进入同一区，用户切换企业时可能进入不同区。浏览器获中央授权后直连业务节点。
A、B、C、D……每个服务区运行相同的完整业务软件，提供获客、CRM、背调、知识库、AI 工作台、邮件业务、任务中心和企业业务设置与审计。总图并排完整展示 A、B 两区的同等能力，C、D……按同一结构扩展。每区都包含 Java API、Java Worker、WeKnora 服务与知识处理组件，以及本区业务数据库和 WeKnora 专用数据库。服务区是逻辑边界，初期可由一台服务器提供，后续可扩成多台。各区业务数据库独立，区内企业数据继续隔离。
区内业务协作
企业与产品资料 → 获客 → CRM 沉淀 → 背调筛选 → 邮件开发 → 沟通跟进。
WeKnora 知识库为背调和邮件提供己方资料。AI 工作台通过业务工具发起操作，服务端校验权限。Java 业务 API 处理交互请求，外贸耗时任务提交本区 Java Worker。
WeKnora 企业知识库与持久会话
每区独立接入 WeKnora，一家企业对应本区一个 Tenant／工作空间，仅配置一个企业共享知识库。中央仍负责统一 SSO、企业和成员权限；WeKnora 接入同一 Keycloak，服务端维护企业及用户映射，不建立另一套企业归属。
React 工作台 → 本区 Java 适配 API → WeKnora 会话与知识接口 → 本区 WeKnora 专用库。所有 AI 工作台会话持久保存，关联企业、用户、消息和引用；Java 业务库保存业务记录、任务及审计，通过会话 ID 关联。两套库独立管理表结构，不直接写对方内部表。
所有会话均持久保存；建议个人会话默认仅本人可见，成员间共享及管理员查看规则后续确定。企业知识库成员共享，知识库管理权限不自动授予成员会话查看权。保存会话不等于自动加入公共知识库，用户确认或收藏后再整理入库。API 与原生网页会话的身份和列表可见性需适配，不能仅凭企业 API Key 保证同一用户能看到相同历史。
WeKnora 是独立第三方知识系统，其后端及解析组件沿用项目技术栈；我们自己的业务 API 与 Worker 继续使用 Java。接入目前为目标设计，尚未完成部署或数据迁入。
数据库归属与企业共享
每个业务区拥有独立 PostgreSQL 业务库，区内企业共享表结构，以 tenant_id + 强制 RLS 隔离。固定 Schema 可按 CRM、邮件、任务等模块组织，不按租户创建 Schema，也不继续使用独立 SQLite 保存 CRM 主数据。A、B、C、D……采用同一结构，独立库初期不要求各占一台物理服务器。
中央目录库负责企业、有效成员、租户角色与企业归区；所属业务区保存 CRM、企业邮件设置、模块授权、WeKnora 映射、业务任务和审计。WeKnora 专用库由 WeKnora 管理知识索引、会话和消息，Java 通过 API 接入，不直接写其内部表。
CRM 客户、联系人和跟进记录归企业共享。tenant_id 决定企业归属，created_by 只记录贡献者，不能把共享数据变成创建者私有。查看、新增、修改、删除、导出按角色授权。企业邮件设置共享，配置与发送权限分开；企业可配置多个邮箱，凭据只保存于服务端受限配置或凭据存储。
每企业唯一 knowledge_binding 关联本区 WeKnora 租户与唯一共享知识库；成员身份另行映射。module_grant 按企业、成员、模块及权限记录委派。企业有效成员默认可阅读、检索和在 AI 中引用知识；租户管理员默认管理，也可授权其他成员上传、更新和删除文档。授予或撤销知识库管理员默认由租户管理员负责。
成员离开企业后立即失去访问资格，其贡献的 CRM 和知识资料仍属于企业。模块授权不能绕过中央成员资格校验，知识库管理员也不因此获得企业成员管理权限。
建议逻辑实体为 crm_customer、crm_contact、crm_followup、enterprise_mail_settings、knowledge_binding、module_grant、business_job、audit_event，名称供开发映射，尚非实际迁移表名。所有企业业务行带 tenant_id，唯一约束与外键保留企业身份，例如 (tenant_id, customer_id) 引用 (tenant_id, id)，防止关联到其他企业的数据。
API 与 Java Worker 使用非表所有者、非超级用户且无 BYPASSRLS 的受限账号。每次请求或任务先验证企业、成员和权限，再在同一事务内设置局部上下文，通过 FORCE ROW LEVEL SECURITY 限制查询与写入。浏览器提交的企业参数必须重新授权，连接池复用不能残留上一企业上下文。
业务库 RLS 不自动保护 WeKnora 或公共文件服务。访问这些接口也必须校验企业、成员和对象映射，不能仅依靠一个企业 API Key 或文件路径前缀。凭据不下发浏览器。
新增 Worker 仅扩展计算，共用所属区 PostgreSQL 与持久任务，不为每个实例新建 CRM 库。按租约互斥领取，执行与提交重新授权；重试必须保持业务幂等。
备份按业务区规划数据库时间点恢复、异机副本和恢复演练，覆盖业务库、WeKnora 数据与原文件的一致性。共享表下恢复单企业数据，需要先恢复到隔离环境，再定向提取，不能覆盖其他企业。具体工具、RPO/RTO、高可用和迁移步骤后续确定；实际迁移必须保留现有数据。
Worker 横向扩展
API 授权并持久化任务 → 本区队列 → 多个 Java Worker 互斥领取 → 执行业务 → 保存进度和结果 → 用户通过本区 API 查看。
Worker 可同机分进程部署，也可新增到独立服务器；新增实例只连接所属区的队列和数据。企业归属、用户入口和业务数据位置保持稳定。使用并发限制、租约心跳、故障重试与业务幂等；邮件等副作用在结果不确定时先核对，不盲目重发。
Java Worker 负责获客、CRM、背调、邮件等外贸任务；WeKnora 自身组件负责知识入库、文档解析、索引和问答。两类执行体系按负载分别扩展，不混用任务队列；增加 Java Worker 不会自动增加 WeKnora 的处理能力，WeKnora 多实例与会话接续仍需验证。
增加 Worker 主要解决后台任务积压，数据库、带宽和供应商配额仍各有容量边界。队列技术选型与具体调度参数后续确定。
独立基础设施
公共基础设施放在所有业务区之外。公共文件服务器由 A、B、C、D……全部业务区共用，保存知识库原文件、附件和图片；物理存储共用，企业与用户访问权限仍隔离。公共邮件基础设施也供各区共用，提供邮箱、收信和投递通道，各区保留自己的模板、开发任务和客户关联。总图连到公共区域的箭头表示各区可使用其中的文件与邮件两项服务。
实现状态与讨论范围
中央与 A 节点的认证、企业路由和基础节点能力已有实现。WeKnora 接入、完整业务模块迁入、多机 Worker 和独立邮件文件接入尚未完成。本版补充数据库归属、共享与权限的目标设计，尚未执行数据库迁移；备份恢复、高可用、迁移流程以及中间件细节另行讨论。