题库规划 / 05-后端架构与流式会话
← 上一章 下一章 →

05 - 后端架构与流式会话工程篇

核心定位：Go 语言企业级后端架构、SSE 流式长连接通信、会话上下文窗口治理、客户端断连中断与协程安全。

Q1: 请介绍一下「政务小灵通」后端系统的整体架构分层设计（Go 后端），各层的职责与依赖关系是怎样的？

回答（求职者口吻）：
我们的 Go 后端系统采用了清晰的经典整洁分层架构（Clean Architecture / DDD 分层），自上而下严格单向依赖：

  1. 接口与传输层（Transport / Handler Layer）：
    - 负责 HTTP / SSE 请求的接收、路由分发、中间件拦截（JWT 鉴权、跨域 CORS、租户解析、链路 TraceID 注入、接口限流）、入参 DTO 格式校验与统一 JSON/SSE 流式响应包装。
  2. 应用业务层（Application / Service Layer）：
    - 核心业务用例编排层。包含：Chat 业务服务（组装会话、调度 Query 改写与 RAG 检索）、Task Agent 编排服务（状态机推进、工具调度）、文档入库流转服务及权限审计业务。
  3. 领域与适配器层（Domain & Adapter Layer）：
    - 包含系统的核心领域模型定义（Session、Message、AgentTask、KnowledgeDomain），以及对外部第三方服务的驱动适配器：RAGFlowAdapter（封装底座调用）、LLMClient（统一大模型 API 调用抽象）、StorageAdapter（MinIO 文件操作）。
  4. 基础设施层（Infrastructure Layer）：
    - 底层数据库与中间件的具体实现，包括 GORM/MySQL 仓储实现、Redis 缓存与分布式锁封装、RabbitMQ/Kafka 消息生产者与消费者实现。

各层之间通过 Go interface 接口进行解耦，保证了核心业务逻辑的高内聚、低耦合，并极大提升了单元测试的可 Mock 性。

Q2: 为什么在大模型流式对话场景中，选择 Server-Sent Events (SSE) 协议而不是 WebSocket 或传统的 HTTP 轮询？

回答（求职者口吻）：
这是根据大模型流式输出的通信特征做出的最合理技术选型：

  1. 通信单向性与业务匹配度：
    - 大模型对话具有明显的“客户端发一次请求（提问），服务端单向持续多包下发（流式 Token）”的特征。SSE 本身就是基于标准 HTTP 协议构建的轻量级单向长连接通道，天然契合这一场景；而 WebSocket 是全双工双向通道，协议握手复杂，在单向吐字场景下属于过度设计。
  2. 穿透性与代理友好（Nginx / 政务网关）：
    - SSE 是纯文本的 HTTP 协议，对政务内网的防火墙、Nginx 负载均衡器、WAF 网关完全透明，无需像 WebSocket 那样配置复杂的 Upgrade 协议头转发和专用代理策略。
  3. 断线重连与工程复杂度：
    - SSE 规范原生支持 Last-Event-ID 机制，浏览器/客户端在异常断开时会自动携带 ID 触发重连，实现成本远低于 WebSocket 的心跳与重连协议维护。
  4. 相比长轮询（Long Polling）的优势：
    - HTTP 轮询不仅网络开销巨大、延迟高，且由于 Token 生成具有极高的实时性，轮询完全无法实现平滑的“打字机”视觉体验。

Q3: 详细讲讲 Go 语言在实现 SSE 流式输出时的核心代码逻辑与网络处理细节。

回答（求职者口吻）：
在 Go（以 Gin 框架为例）中实现高性能 SSE，关键在于正确设置协议头、利用 http.Flusher 实时刷新缓冲区，并监听 Context 退出信号：

func (h *ChatHandler) StreamChat(c *gin.Context) {
    // 1. 设置标准 SSE 响应头，禁用任何形式的代理缓存
    c.Writer.Header().Set("Content-Type", "text/event-stream")
    c.Writer.Header().Set("Cache-Control", "no-cache")
    c.Writer.Header().Set("Connection", "keep-alive")
    c.Writer.Header().Set("X-Accel-Buffering", "no") // 关键：告知 Nginx 禁用响应缓冲

    flusher, ok := c.Writer.(http.Flusher)
    if !ok {
        c.JSON(http.StatusInternalServerError, gin.H{"error": "Streaming unsupported"})
        return
    }

    ctx := c.Request.Context()
    eventChan := make(chan StreamEvent, 50)

    // 2. 启动异步业务协程调用 LLM/RAG
    go h.chatService.GenerateStream(ctx, req, eventChan)

    // 3. 事件循环消费并 Flush 到客户端
    for {
        select {
        case <-ctx.Done(): // 客户端断开连接或超时
            log.Info("Client disconnected, canceling stream")
            return
        case event, open := <-eventChan:
            if !open {
                // 通道关闭，正常结束
                fmt.Fprintf(c.Writer, "event: done\ndata: [DONE]\n\n")
                flusher.Flush()
                return
            }
            // 标准 SSE 格式: event: xxx \n data: xxx \n\n
            dataBytes, _ := json.Marshal(event.Payload)
            fmt.Fprintf(c.Writer, "event: %s\ndata: %s\n\n", event.Type, string(dataBytes))
            flusher.Flush() // 立即推送，不等待 TCP 缓冲区填满
        }
    }
}

核心细节在于 X-Accel-Buffering: no 确保 Nginx 不做缓存，以及每次 fmt.Fprintf 之后必须调用 flusher.Flush() 确保数据包即刻推送到客户端网络栈。

Q4: 当用户在小程序端点击“停止生成”，或者直接切出后台/网络断开时，后端是如何捕获并彻底中断下游 LLM 请求与释放资源的？

回答（求职者口吻）：
如果用户断开连接而服务端继续推理，会造成严重的算力与 Token 浪费，甚至引发 Goroutine 泄漏。我们通过 Go context.Context 树形级联传播机制 实现全链路即时熔断：

  1. 底层感知（Transport Trigger）：
    - 当客户端主动断开 TCP 连接（或发送 HTTP/2 RST_STREAM 帧），Go 的标准库 HTTP Server 会立即关闭 c.Request.Context() 的 Done() 通道。
  2. 级联取消传播（Propagation Tree）：
    - 我们在创建所有下游调用（调用 RAGFlow HTTP 客户端、调用大模型 API HTTP 请求、数据库查询）时，统一传递由请求 Context 派生出的子 Context：subCtx, cancel := context.WithCancel(c.Request.Context())。
  3. 下游 HTTP Client 立即中止：
    - 下游发送请求使用 http.NewRequestWithContext(subCtx, ...)。一旦父 Context 被 Cancel，Go 标准库底层的 Transport 会立即向大模型服务发送 TCP FIN/RST 报文切断连接，正在运行的推理流立刻被大模型服务端中止。
  4. 资源优雅回收：
    - 业务处理 Goroutine 监听到 <-ctx.Done() 后，退出事件消费循环，关闭本地 Channel 并将当前已生成的残余状态异步更新入库，释放所有局部内存对象。

Q5: 大模型流式吐字速率与前端渲染速率不一致时，如何防止内存暴涨、背压（Backpressure）问题或 Goroutine 泄漏？

回答（求职者口吻）：
大模型在爆发输出时 Token 速率可能很高，如果网络拥塞或客户端处理较慢，极易导致服务端内存堆积。我们采取了三项关键措施：

  1. 带容量上限的有界缓冲通道（Bounded Channel）：
    - 从下游 LLM 读取数据到 SSE 写入线程之间，使用容量受限的 Channel（如 make(chan TokenEvent, 64)）。当网络阻塞导致写入慢时，Channel 被填满，生产者协程自然阻塞在写入端，依靠 Go 运行时的调度机制形成天然的背压（Backpressure），绝不无限制申请内存。
  2. 写操作超时控制（Write Timeout）：
    - 在向 c.Writer 写入数据时设置超时监控。若客户端长期不读（如遭遇半开连接僵死），触发超时立即主动关闭连接，防止 Goroutine 永久挂起阻塞。
  3. Goroutine 防泄漏监控：
    - 确保每个派生出的 Goroutine 都有明确的退出路径（defer close()，监听 ctx.Done()，以及捕获 panic 进行 recover 兜底），在 CI/CD 中通过 uber-go/goleak 进行单元测试阶段的协程泄漏自动化检测。

Q6: 多轮对话的会话上下文（Session Context）是如何管理的？轮数过多时滑动窗口与摘要压缩策略是如何落地的？

回答（求职者口吻）：
长对话会迅速耗尽大模型上下文窗口并大幅增加延迟与费用。我们采用了“最新滑动窗口 + 异步会话摘要滚动压缩”的双轨机制：

  1. 会话存储结构：
    - 会话元数据及最新消息持久化在 MySQL 中，高频活跃会话缓存在 Redis List / ZSet 中。
  2. 滑动窗口截断（Sliding Window）：
    - 每次拼装 Prompt 时，默认只加载当前会话最近的 3 ~ 5 轮完整原始问答（Raw Messages），确保最新交流的上下文连贯性和语气准确。
  3. 滚动摘要压缩（Rolling Summarization）：
    - 当历史消息轮数超过阈值（如 > 5 轮），触发异步后台任务：调用小模型对更早的历史消息与现有旧摘要进行增量提炼，生成一段精炼的结构化摘要字符串（如：“用户身份为某区经信局科长，正在咨询 2024 年专精特新企业用地与补贴政策，此前已确认过两份政策文件编号……”）。
  4. 最终 Prompt 拼接结构：
    [System Prompt] [历史会话摘要（Summary）]：... [最近 3 轮详细对话（Recent Messages）]：... [当前检索到的 RAG 参考法规（Retrieved Chunks）]：... [用户当前最新提问]
    这种方案既保证了极早期的关键背景信息不丢失，又将上下文 Token 严格控制在安全预算内。

Q7: 针对多租户、多用户的并发请求，后端是如何保证会话状态隔离与协程安全的？

回答（求职者口吻）：
我们在设计之初就确立了“无状态服务节点 + 数据层严格租户上下文隔离”的原则：

  1. 会话无状态化（Stateless Design）：
    - Go 后端服务本身不保留任何内存态的 Session 变量，所有会话状态、任务状态全部托管于分布式 Redis 与 MySQL。任意后端节点挂掉，其他节点可无缝接管请求。
  2. Context 传递租户与用户上下文：
    - 鉴权中间件在解析 JWT 后，将 TenantID、OrgID、UserID 封装为不可变强类型 Struct 注入 context.Context。整个调用链路中的所有函数禁止使用全局变量，必须显式传递 Context。
  3. 并发写入的分布式锁保护：
    - 针对同一用户可能在快速连续点击发送两条消息导致的会话错乱，后端基于 Redis Redlock 实现会话级互斥锁 lock:session:{session_id}。前一条消息的 RAG 检索与会话更新未完成前，后一条请求被优雅排队或提示“助手正在思考中，请稍候”，彻底杜绝并发竞态写坏会话历史。

Q8: 系统中如何优雅处理敏感词/涉密词的流式实时过滤？如果违规词被大模型拆分成多个 Token 吐出来，怎么做流式命中拦截？

回答（求职者口吻）：
大模型是按 Token（可能是一个字或半个词）逐字流式输出的，如果直接用简单的正则匹配单个 Token，必然会漏掉跨 Token 的违规词（如词语“违规涉密”，大模型分别吐出“违”、“规”、“涉”、“密”）。

我们的技术解决方案是“带滑动缓冲区（Sliding Buffer）的流式 AC 自动机（Aho-Corasick Multi-Pattern Matcher）”：

  1. 流式滑动窗口缓冲器：
    - 服务端接收到 LLM 的 Token 时，并不立即推给前端，而是暂存入一个最大长度为 $N$（设为敏感词库中最长词的长度，如 16 字符）的滑动环形缓冲区。
  2. 动态多模式匹配：
    - 每次新 Token 进入缓冲区，AC 自动机在缓冲区窗口内进行高速多模式匹配。
  3. 延迟安全推送：
    - 若窗口内未命中任何敏感词前缀，将窗口左侧超出最长词边界的安全字符 Flush 推送给前端；
    - 一旦命中敏感违规词，立即触发拦截逻辑：中止下游 LLM 连接，清空缓冲区，向前端推送预设的合规安全提示（如“【内容涉及敏感合规风险，已终止生成】”），并记录审计安全日志。

Q9: 你们系统的 API 设计规范是怎样的？如何统一错误码（Error Code）、鉴权中间件以及标准响应封装？

回答（求职者口吻）：
我们遵循严格的 RESTful 与面向业务语义的 API 规范：

  1. 统一响应体结构（Standard JSON Response）：
    json { "code": 0, // 0 表示业务成功，非 0 表示特定业务错误码 "message": "success",// 面向开发者的人类可读提示 "data": { ... }, // 业务载荷 "trace_id": "c1a2b3"// 全链路追踪 ID }
  2. 分段式业务错误码体系：
    - 错误码采用 6 位数字定义：[服务模块 2位][错误类型 2位][具体编号 2位]。例如 200101 代表 AI 模块-RAG 检索-超时未命中，100403 代表 Auth 模块-权限不足-越权访问。
  3. 统一中间件流水线（Pipeline）：
    - 请求进入后依次经过：Recovery（防止 Panic 崩溃）-> TraceID（生成并绑定全链路追踪 ID）-> AccessLog（记录请求耗时与状态）-> RateLimiter（令牌桶限流）-> JWTAuth（解析用户与租户身份）-> RBACGuard（校验接口级权限）。

Q10: 生产环境中，后端服务是如何进行优雅停机（Graceful Shutdown）的？如何保证正在执行的流式会话或 Agent 长任务不被生硬切断？

回答（求职者口吻）：
在容器化（K8s）发布过程中，服务节点会频繁接收到 SIGTERM 信号。为避免用户对话中途被硬杀，我们实现了完善的优雅下线机制：

  1. 监听操作系统下线信号：
    - 使用 Go 的 signal.Notify(quit, syscall.SIGINT, syscall.SIGTERM) 捕获下线信号。
  2. 摘除负载均衡流量（Health Check Fail）：
    - 收到信号后，首先将 K8s 的 Readiness 探针标记为 Unhealthy，K8s Ingress / Service 会在数秒内将该 Pod 从后端 Endpoint 列表中剔除，不再分发任何新请求。
  3. 等待在途长连接完成（Graceful Drain）：
    - 调用 httpServer.Shutdown(ctx)，设置 30 秒的最大等待超时；
    - 内部维护一个全局的活跃长任务计数器（sync.WaitGroup），新请求拒绝接入，存量正在进行的 SSE 流式输出和 Agent 步骤允许在超时窗口内正常执行完毕；
  4. 资源安全关闭：
    - 在途任务清空后，依次按序安全关闭数据库连接池、Redis 客户端、MQ 消费者，最后主进程安全退出，实现发布过程对用户的“零感知”和“零断流”。

Q11: 简历中提到你在微服务中使用了 go-zero 框架，谈谈你对 go-zero 的架构设计、代码生成（goctl）与服务治理能力的理解？

回答（求职者口吻）：
go-zero 是我们在构建高并发、高可用微服务体系时的重要利器，它的工程哲学是“缩短业务开发路径，把高可用治理内聚在框架底层”：

  1. 契约驱动与 goctl 工业级代码生成：
    - 我们通过编写 .api 和 .proto 定义接口契约，利用 goctl 工具一键生成 Handler、Logic、Types、RPC 客户端及 Dockerfile。这种“契约即代码”的方式彻底杜绝了接口文档与实现脱节的问题，统一了团队代码目录骨架，大幅降低团队协作沟通成本。
  2. 内置的纵深服务治理体系（Zero-Config Governance）：
    - 自适应降载与限流（Adaptive Shedding & Rate Limiting）：go-zero 内置基于 BBR 算法的自适应限流器（CPU 负载过高时动态按比例丢弃非核心请求），配合令牌桶与漏桶算法，保障单节点极端流量下的存活性；
    - 自适应熔断（Circuit Breaker）：基于 Google SRE 熔断算法，依据错误率动态调整请求通过概率，无需人工繁琐配置固定阈值；
    - 缓存一致性与防击穿（Cache Cluster & SharedCalls）：集成 sqlc 自动实现基于主键与唯一键的 Cache-Aside 模式，并基于 syncx.SingleFlight 实现防击穿合并请求（SharedCalls），同一个 Key 的并发回源仅有 1 个请求真正打到 MySQL。
  3. 服务发现与 Etcd 集成：
    - RPC 服务启动时自动向 Etcd 注册带 Lease 租约的心跳，客户端基于 gRPC Resolver 监听 Etcd 前缀变更实现毫秒级端到端服务发现与负载均衡。

Q12: 针对微信小程序端与 Web 管理端不同的数据格式与交互诉求，你们是如何设计 BFF（Backend For Frontend）聚合层的？Node.js / Go BFF 在其中起到了什么作用？

回答（求职者口吻）：
在跨多端交付时，如果让端侧直接调用底层的通用微服务接口，会面临“小程序端字段冗余浪费流量”与“Web 管理端需要并发聚合多个接口导致页面加载慢”的矛盾。我们引入了 BFF（Backend For Frontend）聚合层架构：

  1. 两层架构解耦（BFF Layer + Core Microservices）：
    - 底层核心服务（Core RPC/Service）：保持领域原子性（如 UserService、RAGService、TaskService），提供通用的 gRPC 强类型接口，不关心具体前端形态。
    - BFF 聚合层（Go API Gateway / Node.js BFF）：专为特定终端定制数据流：
    • 小程序 BFF：将长公文元数据进行轻量裁剪，仅保留首屏渲染必需的摘要与卡片字段，并适配微信专用的流式分包协议；
    • Web 管理端 BFF：在一个接口内并发 RPC 调用底层知识库、权限中心与审计中心，做字段聚合与数据拼装，实现一站式大屏渲染。
  2. 异步并发聚合优化（Go ErrGroup 并发加载）：
    - 在 BFF 聚合接口内部，使用 Go 的 errgroup.WithContext 并发发起 3 个下游 RPC 请求（如查用户信息、查租户配额、查任务列表），整体接口耗时由“串行累加 $T_1+T_2+T_3$”骤降至“最大单项耗时 $\max(T_1, T_2, T_3)$”，页面加载速度提升 60% 以上。