企业官网建设流程全解析

Java 大厂面试实录：企业协同 SaaS 场景

面试官：今天我们聊一个企业协同 SaaS 场景。假设你们团队要做一个“审批流 + 消息通知 + 文件协作 + 智能检索”的平台，要求支持多租户、高并发、审计合规和一定程度的 AI 辅助能力。我们按轮次来聊。

第一轮：基础架构与业务拆分

面试官：先说说这个系统你会怎么拆服务？

燕双非：嗯……我觉得可以拆成用户服务、审批服务、消息服务、文件服务，还有一个 AI 服务。反正先拆开，后面出问题也好定位。

面试官：思路是对的，至少知道微服务边界不能一锅炖。那你用什么技术栈做主框架？

燕双非：Spring Boot。这个启动快，配置也少，适合大厂。

面试官：不错。那多租户怎么区分？

燕双非：可以在请求头里带 tenantId，然后用拦截器和 AOP 统一塞到上下文里，后面查库的时候自动带上租户条件。

面试官：可以，至少方向没偏。再问一个，审批流里经常要发通知、写审计日志、同步搜索索引，这些动作怎么处理？

燕双非：我会把主流程和副作用解耦。主流程先落库，再发 Kafka 事件，通知、审计、索引更新都异步消费。

面试官：很好，这样能避免把同步链路拖得太长。Kafka 的思路是对的。

第二轮：性能、缓存与安全

面试官：现在用户量上来了，首页需要展示待办、已办、消息未读数，怎么优化？

燕双非：缓存呗。像待办数量这种可以放 Redis，设置合理过期时间。热点数据可以做本地缓存，避免每次都打数据库。

面试官：可以。那 Redis 和本地缓存一起用时，最怕什么问题？

燕双非：缓存一致性……呃，反正就是更新的时候别忘了删缓存，最好用先更新数据库再删缓存。要是对一致性要求高，还得配合消息通知或者延迟双删。

面试官：回答得还可以，至少知道常见坑。那权限控制呢？协同平台里文档、审批、群组都要鉴权。

燕双非：Spring Security + JWT。登录后发 token，后续请求带 token 做身份校验；权限的话根据角色和资源维度控制。

面试官：不错。那如果企业客户要求对接统一身份认证，比如 OAuth2 / Keycloak，你怎么接？

燕双非：可以把系统作为 OAuth2 Client，统一走 SSO 登录；用户身份映射到本地账号，权限再做一次同步或按需拉取。

面试官：行，听起来你不是完全没接触过企业级认证。那审计日志怎么保证可追踪？

燕双非：关键操作要记录谁、什么时候、对什么资源、做了什么操作、结果如何。日志最好结构化，方便后面查。

面试官：这点很重要，尤其是 SaaS 合规场景。

第三轮：AI 能力与复杂链路

面试官：假设产品现在要加一个“智能问答”功能，用户可以问“某个合同审批卡在哪里”“这份制度文档怎么走流程”，你怎么设计？

燕双非：我会先做文档加载，把合同、制度、流程说明切片后向量化，放到向量数据库里，比如 Milvus 或 Redis Vector。用户提问后，先做语义检索，再把相关上下文喂给大模型。

面试官：继续说。

燕双非：这块本质是 RAG。检索增强生成能减少大模型瞎编。再进一步可以做 Agent，遇到需要查审批状态、查工单、查消息的，就让模型调用工具，去查业务系统的数据。

面试官：工具调用怎么控制边界？

燕双非：得做标准化工具接口，限制可调用范围和参数校验，不然模型乱调接口就麻烦了。

面试官：如果 AI 回答错了、编造了内容，怎么办？

燕双非：这个叫幻觉吧。要么提高检索质量，要么要求回答必须引用依据；关键场景让它只做辅助，不让它直接拍板。

面试官：最后一个问题，系统里有实时协作编辑和消息推送，怎么做在线状态和实时更新？

燕双非：WebSocket。在线状态和实时编辑通知可以走长连接，后端再结合 Redis 记录连接与会话状态。多人协作的话，还得做版本控制和冲突处理。

面试官：嗯，整体思路还算完整。今天就先到这儿，你回去等通知吧。

详细解答

1. 服务拆分与多租户

企业协同 SaaS 常见模块包括用户中心、审批引擎、消息中心、文件中心、搜索服务、AI 服务等。拆分时要优先按业务边界和数据边界划分。多租户通常通过 tenantId 做隔离，可以采用：

• 共享库共享表 + tenant_id 字段；
• 共享库分表；
• 独立库独立表。

中小规模 SaaS 常用共享库共享表，配合拦截器、ORM 插件、AOP 统一注入租户条件，降低开发成本。

2. Spring Boot 与异步解耦

Spring Boot 适合快速构建业务系统，配置集中、生态成熟。审批流这类系统最怕“一个请求串起所有动作”，所以常用“主流程同步 + 副作用异步”的模式：审批落库成功后发送 Kafka 事件，由通知、审计、搜索索引更新等消费者分别处理。这样既能提升响应速度，也能让系统更易扩展。

3. Kafka 在业务中的作用

Kafka 很适合做事件驱动架构中的消息总线。审批完成、文档更新、权限变更等都可以作为领域事件发布出去。消费者各自幂等处理，避免重复消费造成脏数据。实际生产中要重点关注：消息顺序、重复消费、失败重试、死信队列、监控告警。

4. Redis 与缓存一致性

待办数量、未读消息数、热点用户信息都适合放 Redis。对于高并发场景，可以再加本地缓存做二级缓存。缓存一致性常见策略是“先更新数据库，再删除缓存”，因为更新成功后删除缓存能避免脏读。若业务对一致性更严格，可结合消息通知、订阅失效或延迟双删。

5. Spring Security、JWT、OAuth2 与 Keycloak

Spring Security 负责认证授权体系的骨架，JWT 适合无状态认证，适合前后端分离和微服务场景。企业客户接入统一身份认证时，常会引入 OAuth2 或 Keycloak 作为 SSO 方案：系统作为 Client 接入统一登录中心，再把外部身份映射成本地用户与角色。细粒度权限通常要落到资源、操作、租户三个维度。

6. 审计日志与合规

SaaS 产品尤其在企业协同场景，审计日志是必备能力。建议结构化记录操作者、租户、时间、资源 ID、动作、结果、来源 IP、TraceId 等字段，便于检索和追责。对于关键操作，最好做不可篡改存储或定期归档。

7. RAG、向量检索与 Agent

智能问答的核心是 RAG：先检索，再生成。业务文档、制度、合同、流程说明先做切片、清洗、Embedding 向量化，存入 Milvus、Chroma 或 Redis Vector 等向量数据库。用户提问时做语义检索，拿到相关片段后再交给大模型生成答案，这样能显著降低幻觉。

如果系统不仅要回答问题，还要帮用户“查审批、查工单、查群消息、发通知”，就可以引入 Agent。Agent 的关键在于工具调用标准化：每个工具都有明确的输入输出、权限边界、参数校验和审计记录，避免模型越权操作。

8. 幻觉治理

AI 幻觉指模型生成看似合理但实际错误的内容。治理方式包括：提升检索召回质量、控制回答范围、要求引用来源、对关键结论加规则校验、降低模型自由发挥程度。在企业场景中，AI 更适合做辅助决策，而不是直接替代审批或合规判断。

9. WebSocket 与实时协作

实时协作、在线状态、消息推送适合用 WebSocket。后端需要维护连接状态、心跳、断线重连和消息补发机制。多人编辑还要结合版本号、乐观锁或 CRDT/OT 方案处理冲突。对于文档协同，实时推送只是第一步，真正难点在于一致性与冲突解决。

感谢阅读

感谢阅读，希望这篇围绕企业协同 SaaS 场景的 Java 面试实录，能够帮助大家更好地理解大厂面试中的技术拆解思路、业务落地方式和高频考点。祝大家面试顺利，早日拿到满意的 offer！