简介点狮OA是一套多租户企业办公系统面向集团级企业与SaaS服务商支持多公司入驻租户可独立配置个性化流程、人员与用户管理、角色权限及单据申请信息解决集团化组织协同与流程差异化难题。资源包共2000个文件压缩后约37.61MB主体为485个Java源码、850个HTML页面、414个JavaScript脚本与107个CSS样式另有SQL脚本、XML配置、Markdown笔记及Word文档等涵盖前端页面、后端逻辑、数据库和部署说明便于直接部署或二次开发。目前已有77人学习下载适合企业信息化建设者、Java开发工程师及SaaS平台运维人员参考。系统基于点狮后台管理构建可无缝扩展点狮HRM、CRM、IM、ERP等企业应用亦能作为OA应用与小程序的后端服务集成Flowable流程引擎支持并行、串行、会签、回退、取回等审批模式并内置任务转办、委托与抄送功能。流程设计器允许指定具体办理人或岗位助力租户搭建灵活个性化的审批体系。1. 多租户企业办公系统集团与SaaS运营都绕不开的三个能力点狮OA这类多租户企业办公系统一套后端要同时服务集团内部多公司和外部入驻的SaaS客户。每个租户要能自定义自家审批流程、人员角色和单据模板租户之间的数据又绝不能串。落到工程上就是三件事数据隔离与路由、租户级流程配置能力、SaaS化的部署与计量。这篇笔记从架构选型、流程引擎、权限体系讲到五个最常翻车的坑最后收在“让系统租得出去”的灰度与自检上。适合正在做多租户改造、或准备把内部办公系统转成SaaS对外运营的开发者新手能照步骤落地熟手可以直接对照参数和边界。2. 从零拆多租户架构租户隔离、路由与初始化2.1 三种数据隔离方案怎么选独立库、共享库共享表、共享库独立Schema多租户系统第一个要拍板的问题是租户的数据放哪。常见做法有三种每个租户独立数据库、所有租户共享数据库共享表、共享数据库但每个租户独立Schema。独立库隔离性最强备份恢复、慢查询优化都可以按租户来做但数据库连接数会随租户数线性增长几十个租户时还能维护几百个时每个租户的库表结构升级就是耗时的体力活。共享表最省资源入门时很轻松可租户一多所有人在同一张表单表里某个租户导入十万条历史单据全表扫描会直接拖慢其他人的查询稍有不慎还会出现跨租户更新。我一般会推荐做办公OA类系统时选「共享数据库、独立Schema」数据库实例数量可控备份粒度可以到Schema排错时能单独导出某个租户的数据又不至于把连接池压垮。到了集团大客户、要求数据彻底隔离做私有化部署时再切成独立库。这个决策决定了后面所有的路由和权限实现前期不拍板后期换隔离方案比换数据库还痛苦。选型主要看三个维度租户数量级、单租户数据量、SaaS部署复杂度。隔离方案隔离性资源成本运维复杂度适用规模每个租户独立库最强最高高连接数随租户数涨大型集团、私有化共享库独立Schema中中中备份到Schema几十到几百租户共享库共享表最弱最低低但风险高小规模试用2.2 租户路由的落地实现从请求到数据源的上下文传递隔离方案定了之后核心问题变成请求进来系统怎么知道这是哪个租户。最常见的做法有三种给租户分配独立域名、URL路径带租户标识、登录后从Token解析。办公系统里用户每天打开固定入口域名方案体验最好也能顺带做各租户的独立品牌页但对外招募入驻时域名绑定和证书签发的流程比较重我一般会做成“域名Token双通道”系统自动识别主域名命中某租户则直接用没命中则走统一登录入口再从Token里解析租户ID。落地时先做租户上下文Java后端最常见的做法是放进ThreadLocal由拦截器统一赋值和清理。// TenantContext.java 租户上下文 public class TenantContext { private static final ThreadLocalString CURRENT new ThreadLocal(); public static void setTenantId(String tenantId) { CURRENT.set(tenantId); } public static String getTenantId() { return CURRENT.get(); } public static void clear() { CURRENT.remove(); } }再写一个拦截器在请求进入业务逻辑前解析域名和Token统一写入租户ID。// TenantResolveInterceptor.java Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { String tenantId resolveFromDomain(request.getServerName()); // 租户主域名映射 if (tenantId null) { tenantId extractTenantFromJwt(request.getHeader(Authorization)); // 登录态兜底 } if (tenantId null) { throw new TenantNotResolvedException(无法识别租户); } TenantContext.setTenantId(tenantId); return true; } Override public void afterCompletion(...) { TenantContext.clear(); // 防止线程池线程复用后串租户 }这里有两个参数容易写错resolveFromDomain要处理www前缀和测试环境域名否则本地联调永远命中默认租户afterCompletion里必须clear()不然线程池下一条请求会读到上一个租户的ID这类bug表现为偶发数据错乱重启后消失。有了上下文还不够所有SQL仍然要手动带tenant_id条件人总会漏几个接口。我一般会在ORM层再配一层租户插件解析SQL时自动追加tenant_id ?INSERT自动填充租户ID业务代码里完全不感知。派生出来的子查询也交给插件处理这样能挡住大多数跨租户查询风险。2.3 租户初始化与套餐配置创建租户时分配什么租户不是建一条记录那么简单。新公司入驻后如果看不到一套能用的菜单、角色、部门结构就会觉得产品不成熟。我一般把租户初始化做成带状态机的流程步骤有建立租户主记录、开通Schema或租户标识、创建存储目录、写入基础字典、导入默认角色模板、安装默认流程定义最后把租户状态标记为“已就绪”。// TenantInitializer.java 租户初始化主流程 public void initTenant(TenantCreateRequest req) { String tenantId IDGenerator.next(); // 生成全局唯一租户ID createTenantRecord(tenantId, req); // 第一步租户主表 try { createSchemaIfNeeded(tenantId); // 第二步独立Schema initDataDictionary(tenantId); // 第三步基础字典 installDefaultRoles(tenantId); // 第四步默认角色模板 installDefaultFlows(tenantId); // 第五步默认流程定义 markTenantReady(tenantId); // 最后置为就绪 } catch (Exception e) { markTenantFailed(tenantId, e.getMessage()); // 失败可重跑不置就绪 } }这段流程里最大的坑在事务边界建表和初始化字典如果分布在不同物理库全局事务就不存在了。我一般不做强事务而是把整个初始化设计成可重入的任务每次执行前检查“当前完成到第几步”已做的步骤跳过未做的补做。中间哪一步崩了重跑一遍就能恢复不会出现“字典建了一半、流程没装上”的半成品租户。套餐配置也要在创建时写清楚租户能开多少账号、多少流程实例、多少存储空间都应记入租户套餐表。后续SaaS计费、超量提醒都依赖这张表别等用户用超了才想着去查日志。创建租户时顺手分配的还有消息通知渠道、对象存储目录前缀和导出任务队列这些资源维度在初始化阶段不分配后面每个业务功能都会来问一句“这个租户能不能用”。提示初始化脚本必须支持幂等重跑失败后不能只靠人工补数据否则租户数量超过五十个后手工修复会成为每周都要做的事。3. 租户自定义流程引擎把“公司独有的审批流”变成配置3.1 流程定义与表单模型为什么不能用硬编码办公系统的核心业务是审批流。多数公司入驻时都会提出“我们要的和标准版不一样”费用报销超过一万要走副总售前单必须抄送商务请假三天以上要总监批。如果每个租户的特殊规则都以代码分支来实现第一个租户还能接受第十个租户时代码里会充满if (tenantA) ... else if (tenantB) ...租户改一次流程就要发一次版平台运维会先崩溃。所以流程必须是数据不是代码。流程定义我用JSON表示表单部分由动态表单引擎渲染流程部分由节点和连线组成。一个租户自定义流程本质上是通过可视化配置生成一段JSON系统把它存到流程定义表运行时由流程引擎解释执行。这样有三个收益租户配置即时生效、流程版本可回溯、平台升级不会覆盖任何一家公司的个性化设置。表单字段也在同一个JSON里而不是把表单存储和流程存储做成两套孤立的数据模型否则改字段时还要同步改流程容易漏。3.2 流程节点配置审批人、条件分支、抄送的参数说明一段流程定义长什么样直接看例子更直观。下面是最小可用的费用报销审批流员工提交后先由部门主管审批金额大于5000再走到部门总经理否则直接到财务。{ processKey: expense_approval, name: 费用报销审批, version: 1, formSchema: { fields: [ { name: amount, label: 报销金额, type: number, required: true }, { name: reason, label: 报销事由, type: textarea } ] }, nodes: [ { nodeId: start, type: startEvent, next: manager_approve }, { nodeId: manager_approve, type: approval, name: 部门主管审批, assignee: departmentLeader, next: amount_gateway }, { nodeId: amount_gateway, type: conditionGateway, conditions: [ { expression: amount 5000, target: gm_approve }, { expression: default, target: finance_approve } ] }, { nodeId: gm_approve, type: approval, name: 部门总经理审批, assignee: role:general_manager, next: finance_approve }, { nodeId: finance_approve, type: approval, name: 财务审批, assignee: role:finance, next: end } ] }这个JSON里有几个关键参数assignee支持三种写法固定用户ID、角色标识、特殊解析器如departmentLeader由系统根据发起人的部门自动找人conditionGateway节点用表达式引擎解析分支条件amount 5000里的amount取自表单字段这是实现“不同金额走不同审批链”的关键version用于流程版本管理租户改配置时生成新版本已发起的历史流程仍走旧版本避免运行中的单据突然换了审批链。待办和抄送可以在节点上加ccUsers字段支持角色和固定人列表。会签和或签用countersign参数控制all表示所有指定人都审批any表示任意一人审批即可。还有一类容易漏的参数是节点超时提醒比如“部门主管超过24小时未审批自动催办”这部分最好在节点上配置而不是写死在代码里。流程引擎的热部署能力就体现在这些配置项对租户完全开放而不是只要调整就要动代码。3.3 流程实例运行时的租户感知流程定义解决了“流程长什么样”运行时要解决“流程跑到哪”和“下一步找谁”。流程定义表、流程实例表都必须带tenant_id查询待办时第一条件先用租户隔离否则性能和多租户安全都守不住。-- 查询某租户下某个用户的所有待办 SELECT t.task_id, t.node_id, p.process_name FROM flow_task t JOIN flow_instance p ON t.instance_id p.instance_id WHERE t.tenant_id #{tenantId} -- 租户隔离条件ORM插件或SQL强制带上 AND t.assignee #{userId} AND t.status PENDING;这段SQL的要点有两个tenant_id不能只靠人眼自觉我一般会在ORM层自动拼上assignee字段在会签节点存多个用户ID时要用任务候选人表存储否则匹配会漏掉会签任务。流程引擎执行到下一步时要按节点配置动态解析审批人可能取角色下的人员列表也可能按发起人的部门层级往上找主管。租户的部门结构是租户私有数据所以解析审批人时必须限定在该租户的组织架构内查不能从全局表里捞人。流程定义一旦发布租户再调整节点顺序不会影响正在运行的流程实例因为实例持有的是发起时的流程快照。我建议在流程实例表里冗余一份definition_snapshotJSON字段而不是后台流程定义一更新运行中的实例也跟着变。这个快照既能让历史单据显示当时的审批链也方便以后审计“这张单到底经过谁的手”。条件表达式解析失败时要明确报错并停止实例不能默认走某个分支否则金额过万的单据被当成小额单据处理财务那边就出事了。4. 人员、用户、角色与单据的租户内管理体系4.1 租户内用户管理和角色权限RBAC体系怎么落地对外是SaaS对内是每个公司自己的管理系统所以“用户”要理解成两个层面平台账号与租户内用户。平台账号用于登录认证租户内用户用于各个公司内部的部门、角色、单据归属绑定两者之间靠user_id tenant_id关联。一个账号可以被同一个集团下的多个公司邀请并在不同公司里拥有不同角色这是集团级使用场景的常见需求也是和单租户系统最大的区别。角色权限我做成三层菜单权限、操作权限、数据权限。菜单权限控制用户能看到哪些功能页操作权限控制能点哪些按钮数据权限最敏感——普通员工只能看到自己提交的单据部门主管能看到本部门所有单据财务角色能看到公司全部的财务类单据。角色模板在租户初始化时预置系统管理员、部门主管、普通员工、财务。租户管理员可以复制模板再调整这就既保证“每个公司个性化”平台又不干预租户内部管理。一个容易翻车的地方在于平台系统和租户系统的管理员后台往往都叫“系统管理”权限边界必须分清楚。平台管理员只能管租户开通和平台配置不能看租户内部业务数据租户管理员只能管本公司人员角色不能碰平台功能。这两个后台如果共用一套菜单权限模型就会出现租户管理员跑到平台管理界面改套餐的越权漏洞。员工离职时要支持“交接”而不是直接删除账号历史单据需要保留创建人记录离职账号应标记为停用并把待办任务转给交接人这个动作也要记录在操作日志里。4.2 单据申请信息表单数据、附件和流程怎么绑定租户系统里“所有的单据申请信息”包含三类单据主信息、动态表单内容、附件材料。单据主信息指单据类型、编号、当前节点、创建人、状态等存在固定的主表中动态表单内容因为不同公司模板不同我用JSON字段存储表单快照字段名以流程定义的formSchema为准。-- 单据申请主表 CREATE TABLE bill_application ( bill_id BIGINT PRIMARY KEY, tenant_id VARCHAR(32) NOT NULL, bill_type VARCHAR(64) NOT NULL, -- 单据类型编码如 EXPENSE process_key VARCHAR(64) NOT NULL, -- 关联流程定义 instance_id BIGINT, -- 流程实例ID form_data_json JSON, -- 表单快照如 {amount:12000,reason:出差} status VARCHAR(32) NOT NULL, created_by VARCHAR(64) NOT NULL, created_at DATETIME NOT NULL ) PARTITION BY HASH(tenant_id);表单快照化存储比外接一张EAV表维护起来更简单但统计查询要小心。要跨单据汇总分析时JSON字段没法直接用SQL聚合。常见做法是另外建宽表或把单据数据同步到分析库业务库只负责读写单据分析库负责报表。单据编号规则也是租户个性化的一部分有的公司用纯流水号有的按部门日期流水这个规则要支持租户自行配置而不是全局统一。附件方面文件存储按租户目录隔离比如存储桶下建tenant/{tenantId}/bill/{billId}/前缀权限校验时业务接口要同时校验“访问人的租户ID”和“单据归属租户ID”文件URL不能直接暴露永久签名用临时签名能在泄漏时降低风险。4.3 集团管控与租户自治的边界集团级企业用户和普通SaaS租户不同它下面有多家公司各家要有独立的流程和人员管理但集团总部又要统一的经营看板。我分两层处理集团总公司是“超级租户”子公司是普通租户。超级租户能跨租户只读查看汇总数据但具体明细仍受子公司的数据权限约束。汇总数据不能实时去各子公司库表join线上库压力会很大。比较稳的做法是各租户把日报、单据汇总结果异步写入集团汇总库总部从汇总库里出报表。租户自治和集团管控冲突最多的点在流程上子公司想改自己的流程但集团要求某些环节必须保留。我的处理方法是建两层次的流程模板集团模板能锁定节点子公司在这个基础上增加自己的节点锁定节点在子公司的可配置项里直接置灰。人员流动上员工从子公司A调岗到子公司B账号可以复用但角色必须重新分配而且两个租户的角色互不可见。这套边界解释清楚集团客户才愿意签下来否则售前演示做得再漂亮实施时也会卡在“总部管不了分公司”的抱怨上。5. 多租户系统常见问题排查数据串联、缓存污染、配置漂移与安全边界5.1 日志里看不出是谁的数据排查时抓瞎现象线上用户反馈“单据丢了”开发翻半天日志查不出是哪家公司的数据要拉DBA导数据才能定位。原因日志输出没带租户维度SQL日志里只有单据ID没法对应到租户问题复现时也无从下手。解决在租户路由拦截器里把租户ID写入日志MDC日志格式里固定输出。MDC.put(tenantId, TenantContext.getTenantId());MDC是SLF4J提供的映射诊断上下文配合日志配置文件里的%X{tenantId}能让每条日志自带租户标签。日志检索平台也按租户分组问题定位能缩短到分钟级。这是多租户系统第一个应该做的事别等出了生产事故再回头补。5.2 ThreadLocal残留引发跨租户串数据现象A公司员工刷新页面偶尔看到B公司的待办名称和角色重启后消失。原因租户上下文用ThreadLocal保存但请求处理完成后没清理线程池中的线程被复用后下一条请求读到上一个租户的上下文。解决拦截器的afterCompletion必须清理上下文。异步任务拿不到主线程的ThreadLocal需要显式把租户ID传进任务里处理。executorService.submit(() - { TenantContext.setTenantId(task.getTenantId()); // 显式传入租户不依赖继承 try { doAsyncJob(task); } finally { TenantContext.clear(); } });还有一类和连接池相关的残留数据库连接池里的连接被不同租户复用如果中间件给连接绑定了租户级别的临时变量或SET语句复用前必须重置。这类问题排查起来很折磨人教训是在连接池层面禁止做租户级设置。5.3 流程表单升级后历史单据渲染崩了现象租户把某个字段从“必填”改成隐藏后历史单据详情页直接报错或白屏。原因表单渲染引擎按最新的formSchema渲染历史数据旧数据里的字段被删掉了前端读取时找不到定义直接崩。解决删除表单字段用“下线”而不是物理删除。下线字段对新增单据隐藏但历史数据渲染时还能兜底显示。字段类型变化也要做兼容数字改成文本时历史数字按字符串处理下拉选项被移除时历史值显示为“原值已失效”。流程表单升级前建议先跑一遍数据兼容检查脚本统计所有历史单据里涉及变更字段的数量评估影响面再发布。5.4 一个租户的大导出任务拖垮整个平台现象某租户管理员在早上9点导出了全量历史单据其他租户的接口响应从200毫秒涨到3秒。原因共享线程池和数据库连接池被这个租户的任务占满没有做租户级隔离。解决大导出任务切到独立的异步任务队列并且对租户做并发限制。数据库连接池可以按租户分池或加租户级别限流写接口上也要有租户粒度的信号量。整体限流能挡住部分问题但误伤所有租户要做到单租户超限不影响别人监控指标必须能按租户拆分才能看到“是谁占满了资源”。关键指标包括租户请求量、慢SQL次数、队列堆积数、导出任务耗时这四个指标按租户维度出图比看全局平均值有用得多。5.5 配置漂移发布一次某个租户的个性化设置就没了现象某次正常发布后客户反馈自定义的审批流模板被还原成默认模板。原因发布脚本里执行了“清空配置表再初始化”把租户配置当成了默认数据全量覆盖这类脚本通常是早期开发环境留下的坏习惯。解决平台发布脚本必须区分“平台内置数据”和“租户业务数据”初始化脚本只插入不存在的平台数据使用幂等SQL。租户配置表的更新走版本化迁移不做删表重建。上线前用对比脚本检查租户配置数量是否变化一旦发现某个租户的配置数减少立刻中止发布流程。这条坑值得反复讲因为数据隔离做得再好一次配置漂移就会让租户对整个平台失去信任。6. 让系统再多撑几年SaaS化部署、灰度与租户自检系统最终要对外提供SaaS服务、多公司入驻共享部署模式下平台升级不能所有租户同时停服。我一般会按租户灰度上线先升级试用租户和小体量租户观察日志和错误率稳定后再升级头部大租户。升级脚本对每个租户单独执行迁移迁移完成后自动跑核心单据的冒烟用例比如提交一张测试单走完主流程确认流程节点、表单字段、待办通知都正常。健康检查也要按租户做而不是只看进程是否存活。我习惯写一个租户自检脚本每天凌晨跑一遍检查每个租户的流程定义JSON是否可解析、最近24小时单据是否有金额字段为空的异常数据、附件存储里的文件与单据引用是否有孤儿文件。自检结果落到租户运营报表里有异常自动告警。诊断命令其实很简单统计租户流程定义状态分布就能秒级看见坏数据# 统计各租户流程定义可解析状态发现异常立即定位到租户 sql select tenant_id, status, count(*) from flow_definition where statusINVALID group by tenant_id我在这方面吃过亏早期所有检查都是整体维度某租户的流程模板因为半次失败迁移变成坏JSON没有告警两周后租户提交单据才发现。之后自检脚本成了每次发布必跑项。多租户系统能不能长期稳定运行靠的不是一次架构评审而是把租户维度的路由、日志、检查都变成系统内建能力。做一个多租户办公系统的时候每到一个阶段就问三个问题数据隔开了没有日志查得出是哪个租户没有配置升级完还在不在三关都过了再聊加功能。希望帮到你。本文还有配套的精品资源点击获取