Posts

OpenClaw 在保全操作自动化中的应用 1. 对应简历段落 这篇文章对应简历中“在传统保险业务系统难以改造的情况下，结合 OpenClaw 自动化流程对部分高频保全后台操作进行低侵入接入，支持 AI 客服生成操作计划、触发受控自动化、回传执行状态，并保留人工确认、权限校验和审计记录”的经历。 面试时这段不要讲成“用脚本点页面”。资深面试官会更关注：为什么保全场景需要自动化，哪些操作适合自动化，如何避免 AI 直接操作生产系统，如何处理页面变化、失败回滚、人工确认、审计追责，以及如何和传统 Java 系统集成。 可以这样表述： 面向保全业务中高频、规则明确但传统系统接口缺失的操作，设计 OpenClaw 自动化接入方案。AI 侧只负责生成操作意图和材料清单，后端根据权限和风险决策触发预定义自动化流程，由 OpenClaw 完成页面级操作或半自动填单，并将执行状态、截图证据和审计日志回传客服工作台。 这段经历体现的是“在不能大改存量系统时，如何工程化接入 AI 自动化能力”。 2. 业务背景 保险保全是指保单生效后对合同相关信息或权益进行变更、维护和服务的业务。常见保全操作包括联系方式变更、地址变更、受益人变更、缴费账号变更、保单贷款、减额交清、退保申请、补发保单、续期缴费方式调整等。 保全系统通常历史较长，流程复杂，权限严格。一些操作有完整 API，但也有不少操作只存在于内部后台页面，或者接口不适合外部系统直接调用。原因可能是系统年代久、接口文档缺失、改造成本高、交易风险大、厂商系统不开放。 客服或运营人员每天会处理大量重复保全请求。比如客户来电要求修改联系地址，坐席需要核验身份、查询保单、确认可办理项目、进入保全后台、选择保全项目、填写字段、提交初审或生成工单。整个过程规则明确，但跨系统点击多，容易出错。 AI 接入后，有两个诉求：一是让 AI 帮坐席判断办理路径和材料；二是对低风险、高频、规则固定的后台操作做自动化辅助。但这里绝不能让大模型直接“控制浏览器随便点”。金融生产系统里的保全操作可能改变合同信息，必须受控。 所以 OpenClaw 的定位不是替代业务系统，而是在接口缺失或改造困难时，作为低侵入自动化适配层，执行预定义、可审计、可回放的流程。 3. 核心原理 OpenClaw 可以理解为自动化执行框架，用于把页面操作、脚本任务或业务流程封装成可调用能力。放在 AI 工程化架构里，它不是直接暴露给模型，而是作为工具层背后的一个执行适配器。 核心原则有三个。 第一，流程预定义。自动化流程由研发或业务专家提前定义，包括入口页面、字段定位、输入规则、校验点、提交条件、异常处理和截图节点。模型不能临时生成任意页面操作脚本。 第二，AI 只产出意图，不直接执行。用户说“帮客户修改手机号”，模型可以识别为“联系方式变更”意图，生成所需字段和材料清单，但真正能否执行，要由后端权限、风控和业务规则决定。 第三，执行可观测。自动化每一步都要有状态、日志、截图或页面证据。失败时要能知道卡在哪一步，是登录失效、元素找不到、业务校验失败，还是页面提示不能办理。 在系统架构上，AI 编排服务调用 Tool Runtime，Tool Runtime 根据工具定义判断该工具底层由 OpenClaw 执行，然后创建 automation job。OpenClaw worker 拉取任务，打开目标系统页面或调用自动化脚本，按步骤执行，并把状态回写。 这种模式把风险控制在两个边界内：模型不能自由操作页面，自动化也只能执行预定义流程。 4. 项目落地 落地时先选择适合自动化的保全场景。不是所有保全都适合自动化。优先选择规则明确、字段少、失败可恢复、风险较低、人工重复度高的流程，比如联系方式变更草稿创建、保全材料清单生成、补发保单申请工单创建、保全进度查询。退保、受益人变更、银行卡变更这类高风险动作应先做半自动化或草稿生成。 然后对每个流程建模。一个保全自动化流程至少包括：流程编码、业务名称、风险等级、输入参数、前置条件、权限点、是否需要用户确认、执行步骤、校验点、回滚或中止策略、审计要求。 例如“联系方式变更草稿创建”可以设计成：输入 policyNo、customerId、newMobile、newAddress；前置条件是用户已完成身份核验，保单状态有效，当前坐席有保全受理权限；流程只创建草稿或待办，不直接终审生效；执行后返回草稿号和截图证据。 Java 系统中可以有一个 AutomationService： ...

Spring AI、AgentScope 与 ReAct 在研发效能工具中的实践 1. 对应简历段落 这篇文章对应简历中“在研发效能场景中探索 Spring AI、AgentScope 和 ReAct 思想，构建面向 Java 团队的智能研发助手，支持需求理解、代码检索、接口说明、日志分析、测试建议、发布检查和工单辅助处理”的经历。 面试时这段不要讲成“写了一个 ChatGPT 套壳”。资深面试官会关注：为什么研发效能工具需要 Agent，Spring AI 在 Java 体系里解决什么问题，AgentScope 适合做什么编排，ReAct 如何让模型边思考边调用工具，以及如何控制工具权限、上下文长度、误操作和结果可信度。 可以这样表述： 面向 Java 研发团队搭建内部研发效能助手，使用 Spring AI 统一接入模型、Prompt、Embedding 和向量检索能力，借鉴 AgentScope 的多 Agent 编排思想拆分需求分析、代码检索、日志诊断和测试建议角色，并基于 ReAct 模式让模型在推理过程中按需调用代码搜索、知识库、CI、日志平台和工单系统工具，提高排障和需求理解效率。 这段经历重点体现 AI 工程化框架选择、Agent 设计和研发流程结合能力。 2. 业务背景 大型 Java 团队的研发效率瓶颈不只在写代码本身。很多时间消耗在理解需求、查历史逻辑、找接口文档、定位日志、分析 CI 失败、补测试、写发布说明和处理工单上。 比如一个新需求来了，研发需要看产品文档、查相关服务、理解数据库表、找历史工单、确认接口影响面。一个线上问题来了，需要查日志、看链路追踪、定位最近发布、比对配置、判断是否回滚。很多信息散落在 Git 仓库、Wiki、接口平台、日志平台、CI、工单系统和聊天记录里。 AI 研发助手的价值是把这些分散信息通过自然语言入口串起来。但如果只是把问题发给模型，模型并不知道公司代码、内部接口、近期发布和日志。它必须能检索内部知识、调用工具、逐步分析。 这就引出三个技术点。 Spring AI 适合 Java 团队，因为它把模型调用、Prompt 模板、Embedding、VectorStore、ChatClient 等能力封装成 Spring 风格，便于接入现有 Spring Boot 系统。 AgentScope 更强调 Agent 编排思想，可以把复杂任务拆给不同角色或步骤，例如需求分析 Agent、代码检索 Agent、测试建议 Agent、发布检查 Agent。 ...

SSE 流式响应在 AI 对话系统中的使用 1. 对应简历段落 这篇文章对应简历中“在内部 AI 客服系统中基于 SSE 实现大模型对话流式响应，支持模型 token 增量输出、工具调用状态推送、RAG 引用展示、异常中断处理和前端会话体验优化”的经历。 面试时这部分不要只说“用了 SseEmitter”。资深 Java / AI 工程化面试会继续问：为什么选择 SSE 而不是 WebSocket，流式输出如何和工具调用结合，断线如何处理，后端线程怎么释放，网关和 Nginx 会不会缓冲，怎么做超时、取消、审计和敏感词拦截。 可以把项目描述成： 在 AI 客服对话链路中设计 SSE 流式响应协议，将模型 token、检索状态、工具调用进度、引用来源和最终审计结果以事件流形式返回前端，提升坐席等待体验，并在 Java 后端实现连接生命周期管理、异常兜底、用户取消、超时控制和代理缓冲配置。 这段经历的价值在于把“模型慢”变成“用户可感知的渐进式反馈”。 2. 业务背景 AI 客服系统和传统业务系统最大的体验差异之一是响应时间。传统接口通常几百毫秒到一两秒返回，而大模型回答可能需要数秒甚至十几秒。如果中间还要做 RAG 检索、rerank、工具调用、结果汇总，用户等待时间会更长。 客服坐席的工作节奏很快。如果系统在十秒内没有任何反馈，坐席会以为卡住了，可能重复点击、刷新页面或转去手工查询。AI 系统即使最终答案正确，体验也会很差。 SSE 的作用是让后端可以持续向浏览器推送事件。模型生成一个 token 或一小段文本，就推给前端展示；工具调用开始、完成、失败，也可以推送状态；最后再推送完整回答、引用来源和审计 ID。 为什么很多 AI 对话系统选择 SSE？因为 AI 文本生成通常是服务端到客户端的单向流，前端不需要频繁向后端推送消息。SSE 基于 HTTP，浏览器原生支持 EventSource，穿透代理比 WebSocket 简单，和现有 Spring MVC / WebFlux 系统集成成本较低。 当然，SSE 不是万能的。如果需要双向实时协作、多人编辑、语音实时交互，WebSocket 更合适。但内部客服文本对话场景，SSE 通常足够。 3. 核心原理 SSE，全称 Server-Sent Events，是一种基于 HTTP 长连接的服务端推送机制。响应头通常是： ...

MCP 思想与业务工具标准化封装 1. 对应简历段落 这篇文章对应简历中“借鉴 MCP 思想，将公司内部传统业务能力标准化封装为 AI 可发现、可调用、可治理的工具集合，统一接入保单、客户、产品、工单、保全、知识库等系统，降低大模型应用与存量业务系统的耦合”的经历。 面试时这部分不要只讲“MCP 是一个协议”。资深面试更关心你是否理解 MCP 背后的工程思想：工具描述标准化、上下文传递标准化、权限和审计标准化、资源访问标准化，以及如何把大量不统一的内部系统封装成稳定的 AI 工具层。 可以这样表述： 在内部 AI 工程化平台中，参考 MCP 的资源、工具和上下文抽象，将传统业务 API 封装为统一 Tool Registry。每个工具以标准 schema 描述能力、参数、权限、风险等级、调用方式和返回结构，AI 编排层通过统一协议发现和调用工具，从而避免每个 AI 应用重复对接保单、客户、产品、工单等系统。 这段经历的核心是“用标准化工具层把 AI 应用和传统系统隔离开”。 2. 业务背景 企业内部系统通常不是为大模型准备的。保险公司尤其明显：核心保单系统可能是多年前的 Java 单体，客户中心可能是 Dubbo 服务，产品中心可能有 REST 接口，影像系统可能是老 SOAP，保全后台可能只有页面操作，工单系统又有自己的一套权限和状态机。 如果每个 AI 应用都直接接这些系统，会出现几个问题。 第一，重复开发。AI 客服要查保单，研发助手也要查工单，运营助手也要查产品配置。每个系统各写一套适配器，维护成本很高。 第二，接口不稳定。传统 API 的字段、错误码、分页、鉴权方式不统一。模型应用如果直接依赖这些细节，会非常脆弱。 第三，安全难统一。不同团队各自接接口，权限校验、脱敏、审计、限流可能标准不一致，风险很大。 第四，模型难理解。内部 API 往往是面向系统调用设计的，比如 queryPolicyBaseInfoV2、getUwRuleByPrdAndPlan，模型不容易从这些名字判断何时使用。 第五，演进困难。以后要更换模型、增加 Agent、接入工作流平台，如果业务能力没有标准化，就会陷入大量点对点集成。 MCP 思想的价值在这里体现出来：不是简单追逐新协议，而是把企业内部能力抽象成模型和 Agent 能理解、能发现、能安全调用的工具与资源。 3. 核心原理 MCP 可以理解为大模型应用和外部能力之间的标准连接方式。它强调几个抽象：工具 Tool、资源 Resource、提示 Prompt、上下文 Context。落到企业业务系统里，可以转化为四个设计原则。 ...

RAG 在保险产品问答中的落地方式 1. 对应简历段落 这篇文章对应简历中“在公司内部 AI 客服系统中，基于 RAG 构建保险产品知识问答能力，支持产品条款、投保规则、续保政策、理赔材料、客服 FAQ 等多源知识检索，并通过引用溯源、版本控制和人工反馈闭环降低大模型幻觉”的经历。 面试时不要把这段说成“把 PDF 切片后丢进向量库”。资深 Java / AI 工程化面试更关心的是：保险产品知识为什么难，RAG 怎么和产品版本、渠道、地区、生效日期绑定，召回结果怎么评估，回答怎么受控，如何接入传统内容系统和客服工作台，以及出现错误回答后如何追责和修复。 推荐的简历复述可以是： 负责内部 AI 客服产品问答模块的 RAG 架构设计与落地，将产品条款、销售手册、运营公告、FAQ 和制度文档统一治理为可检索知识库；通过结构化切分、元数据过滤、混合召回、rerank、引用溯源和人工反馈闭环，提高保险产品问答准确率，并在合规边界内支持客服坐席快速解释产品规则。 这段经历的价值在于，它不是一个玩具级知识库，而是在金融业务上下文里把非结构化知识变成可控、可审计、可持续运营的问答能力。 2. 业务背景 保险产品问答有几个典型难点。 第一，文档复杂。一个产品往往同时存在条款、费率说明、销售手册、核保规则、理赔指引、运营公告和客服 FAQ。条款强调法律表达，销售手册强调业务解释，FAQ 强调话术，公告强调临时调整。用户问一句“这个产品还能续保吗”，背后可能涉及产品版本、保单年度、停售公告、渠道政策和客户年龄。 第二，版本复杂。同名产品可能有 2022 版、2024 版、互联网渠道版、银保渠道版，不同版本的等待期、责任免除、续保规则并不完全一致。如果 RAG 只按文本相似度召回，很容易拿旧版本回答新问题。 第三，问题表达不标准。坐席或业务人员不一定使用条款里的标准术语。他们会问“甲状腺结节能不能买”“百万医疗断缴了还能接着交吗”“这个病算不算重疾”“小孩买要不要体检”。系统必须把口语问题映射到条款概念、产品配置和业务规则。 第四，合规压力高。保险客服回答不能夸大保障，不能承诺一定赔付，不能把核保和理赔结论提前说死，也不能在证据不足时编造解释。AI 问答系统必须做到“有依据才回答，依据不足就拒答或转人工”。 第五，知识运营成本高。产品、公告、FAQ 会持续变化，客服质检也会不断发现不准确回答。RAG 如果没有知识更新、评测和反馈机制，很快就会变成一个“上线时可用、三个月后不可信”的系统。 所以保险产品 RAG 的核心目标不是炫技，而是建立一套稳定机制：让模型回答时绑定正确知识、正确版本、正确边界，并且能够被运营人员持续维护。 3. 核心原理 RAG 的基本链路是：问题理解、知识召回、证据重排、上下文构造、模型生成、引用溯源、反馈回流。保险场景要在每一步增加业务约束。 问题理解阶段，系统需要识别问题中是否包含产品名、产品代码、疾病名称、保单号、渠道、地区、时间、客户身份等要素。比如“尊享百万医疗去年买的还能不能续”至少要识别产品、续保意图和时间条件；如果当前会话绑定了保单，还要从上下文里拿到产品版本。 知识召回阶段，不能只依赖向量相似度。向量召回适合处理语义相近问题，但产品代码、条款号、病种名称、公告编号更适合全文检索。工程上通常采用混合召回：向量检索负责语义，BM25 或 Elasticsearch 负责关键词，元数据过滤负责版本边界，再通过 reranker 对候选片段排序。 证据构造阶段，要把召回结果转换成模型可理解的上下文。保险文档切片时必须保留标题路径、文档类型、版本号、生效日期、来源链接。否则模型即使答对了，客服也不知道依据来自哪里。 生成阶段，Prompt 必须明确约束模型：只能基于给定证据回答；证据不足要说明无法确认；涉及赔付、核保、退保金额时不能做最终承诺；必须给出引用来源；面向客户和面向内部坐席的话术要区分。 评测阶段，要建立黄金问题集。不能只看“回答像不像”，还要看证据是否正确、版本是否正确、有没有越权引用、有没有承诺性话术、是否给出转人工边界。保险 RAG 的评测更接近合规质检，而不是普通闲聊体验评分。 4. 项目落地 落地时可以拆成四个模块：知识治理、索引服务、问答编排、运营评测。 知识治理模块负责把 PDF、Word、HTML、FAQ 表格、公告系统内容统一转成标准文档。每份文档进入知识库前，需要记录 productCode、productName、docType、version、effectiveDate、expireDate、channel、region、ownerDept、riskLevel、sourceUrl 等元数据。对于保险条款，解析时要尽量保留章节编号和标题路径；对于表格，要转成“行列语义明确”的文本，不要简单拼接。 ...

Function Calling 如何安全调用业务 API 1. 对应简历段落 这篇文章对应简历中“在内部 AI 客服和业务辅助系统中，通过 Function Calling 将用户自然语言意图转换为结构化业务工具调用，安全接入保单、客户、产品、工单、保全等传统业务 API，并实现权限校验、参数校验、审批确认、脱敏审计和风险分级”的经历。 面试时这部分不要只说“模型可以调用函数”。真正有含金量的是：模型如何知道能调用哪些工具，工具参数如何校验，用户有没有权限，模型能不能越权查别人的保单，执行类接口如何二次确认，接口异常如何回到对话，以及调用记录如何审计追责。 可以把简历里的项目描述成： 在 AI 客服系统中设计工具调用编排层，将传统 Java 业务 API 封装为受控工具，供大模型通过 Function Calling 发起查询或辅助操作。工具层统一处理 schema 注册、参数绑定、身份透传、权限校验、风控拦截、结果脱敏、调用审计和人工确认，确保大模型只能在业务授权范围内调用接口。 这段经历的重点是把 Function Calling 从“模型能力”落成“企业可控的业务集成能力”。 2. 业务背景 内部客服系统里的很多问题都不能只靠知识库回答。比如用户问：“这个客户名下有几张有效保单？”“这张保单为什么续保失败？”“当前工单应该转哪个队列？”“能不能帮我生成保全变更材料清单？”这些问题需要访问实时业务系统。 传统做法是客服坐席在多个系统里手工查询。AI 接入后，希望坐席用自然语言提问，系统自动判断要查哪个接口，聚合结果后生成回答。这就是 Function Calling 的典型价值：模型负责理解意图和组织参数，后端负责执行确定性 API。 但是保险业务 API 很敏感。保单、客户、健康告知、银行卡、联系方式都属于敏感信息。一个普通坐席不能查全公司的客户，一个渠道人员不能看其他渠道保单，一个模型也不能因为用户说“帮我查张三身份证号”就绕过权限。 更复杂的是，有些接口是只读查询，有些接口会改变业务状态。查询保单摘要风险较低，创建工单风险中等，提交退保、变更银行卡、发起保全则风险很高。Function Calling 如果没有风险分级和确认机制，就会把自然语言入口变成一个危险的万能后门。 所以项目目标不是“让模型可以调用业务接口”，而是“让模型只能以受控、可审计、可回滚或可确认的方式调用允许的业务工具”。 3. 核心原理 Function Calling 的核心原理是把可调用能力描述给模型，让模型在对话中输出结构化调用请求。工具描述通常包含 name、description、parameters schema 和必填字段。模型根据用户问题选择工具，并生成参数 JSON。 但生产系统里不能让模型输出什么就执行什么。安全调用链路至少要分成五步。 第一，工具注册。每个业务 API 被封装成一个工具定义，包含工具名称、参数 schema、风险等级、权限点、是否需要确认、超时时间、限流策略、结果脱敏规则和审计类型。工具注册信息由服务端维护，不由前端或用户动态传入。 第二，模型选择。编排服务把当前用户可见的工具子集提供给模型。比如普通客服只能看到查询类工具，高权限主管才能看到部分工单处理工具。模型输出 toolName 和 arguments，但这只是“调用建议”。 第三，调用前校验。后端根据工具定义做 JSON schema 校验、业务参数校验、权限校验、数据范围校验、幂等校验和风控校验。比如 policyNo 必须属于当前机构或当前工单绑定客户；身份证号不能作为任意查询入口；批量查询要限量。 ...

公司内部 AI 客服系统整体架构设计 1. 对应简历中的哪一段 这篇文章对应简历中“内部大模型、智能客服、保险产品问答、RAG、Function Calling、MCP、SSE、工具调用、权限校验、审计脱敏、OpenClaw 自动化流程、传统金融系统低侵入接入”等描述。 面试时这段经历不能只讲“接了一个大模型接口”或者“做了知识库问答”。真正有含金量的点在于：在一个已有多年历史的保险业务体系里，把 AI 能力作为新的交互层和自动化编排层接进去，同时不能破坏原来的交易链路、权限体系、审计要求和合规边界。 可以把简历里的项目表述理解为下面这段更完整的背景： 在公司内部客服和业务支持场景中，设计并落地基于大模型的智能问答与业务辅助系统，支持保险产品条款问答、客户权益解释、保单状态查询、续保和保全办理指引等能力。系统采用 RAG 增强保险产品知识回答，通过 Function Calling 和 MCP 思想封装传统业务 API，通过 SSE 实现流式响应；同时接入统一身份认证、数据权限、敏感信息脱敏、操作审计和工具调用审批机制，并结合 OpenClaw 自动化流程对部分高频后台操作进行低侵入集成。 这段话面试官可能会继续追问： 保险产品问答为什么不能直接让大模型回答？ RAG 的知识库怎么切分、召回和防幻觉？ Function Calling 调业务接口如何做权限校验？ MCP 和普通 API 网关有什么区别？ SSE 流式输出怎么和工具调用结果组合？ 传统金融系统不能大改时，怎么接入 AI？ 涉及客户隐私、保单信息时如何脱敏、审计和追责？ 所以本文的重点不是介绍某个框架，而是讲清楚一套面向金融内部场景的 AI 客服整体架构。 2. 业务背景 保险公司的客服和内部支持系统通常有几个特点。 第一，产品规则复杂。一个保险产品不是简单的一段介绍，而是由主险、附加险、责任免除、等待期、犹豫期、缴费期、保障期间、职业类别、年龄限制、地区限制、续保规则、理赔材料等规则共同组成。客服人员和销售人员经常需要在多个 PDF 条款、产品手册、运营通知、FAQ 和后台页面之间来回查找。 第二，问题高频但表达不标准。用户可能会问“这个重疾险能不能赔甲状腺癌”“小孩买这个产品要不要体检”“断缴之后还能不能续”“这个客户去年买的保单现在能不能退”，这些问题背后既有产品知识，也可能涉及客户保单数据和交易状态。 第三，传统系统很多。保险系统里通常会有核心保单系统、客户中心、产品中心、订单系统、支付系统、理赔系统、保全系统、影像系统、营销系统和客服工单系统。很多系统历史较长，接口风格不统一，有的只有 RPC，有的是老 Spring MVC，有的是存储过程，有的是页面操作，没有办法为了 AI 项目大规模重构。 第四，合规要求高。保险行业涉及个人身份信息、联系方式、银行卡、保单号、健康告知、理赔材料等敏感数据。AI 系统不能把内部数据随意送给模型，不能让没有权限的人通过自然语言绕过原有系统权限，也不能让大模型直接生成不负责任的承诺性话术。 第五，客服效率压力明显。人工客服需要同时处理咨询、查询、解释和工单流转。内部业务人员也希望通过“问一句”的方式快速获得产品解释、客户保单摘要、下一步办理建议，减少查手册和切系统的时间。 所以内部 AI 客服的目标不是替代核心交易系统，而是做三件事： 让复杂知识更容易被检索和解释。 让多系统查询和低风险操作更容易被编排。 在权限、审计、脱敏和人工兜底之内，提高客服和业务人员效率。 3. 总体架构 整体架构可以分成七层：入口层、会话层、编排层、模型层、知识层、工具层、安全审计层。 ...

我的技术学习路线与规划 技术学习没有终点，但有了清晰的路线图，每一步都能走得更扎实。这篇文章记录了我在 AI、数据库、Java 框架、新技术和量化交易等方向的阶段性规划，既是 To-Do List，也是学习路标的公开存档。 持续更新中，欢迎交流。 AI / 机器学习 打好 AI 基础，重点在经典算法、深度学习框架和工程落地。 scikit-learn：经典 ML 算法库，掌握分类、回归、聚类、降维的工程实现 NumPy / Pandas：数据处理基本功，向量化操作、DataFrame 变换、缺失值处理 PyTorch：深度学习主流框架，从张量操作到模型训练、推理部署全链路 Spring AI / MCP：AI 工程化方向，将大模型能力整合到 Java 后端服务中 数据库 深入数据库内核原理，从理论到底层实现。 极客时间 MySQL 课程：系统学习 InnoDB 存储引擎、锁机制、性能优化 OceanBase OBCP 认证：分布式数据库原理、OceanBase 集群运维与调优 慕课网手写数据库：从零实现一个简单的关系型数据库，理解解析器、执行器、存储引擎的完整链路 Java 框架 源码阅读 + 手写实现，吃透核心框架的设计思想。 Spring / Spring Boot 源码 + 手写：IoC 容器、AOP 原理、自动配置、事务管理 MyBatis 源码 + 手写：ORM 映射原理、动态 SQL、插件机制 Tomcat 源码 + 手写：Servlet 容器、HTTP 处理、类加载架构 JDK 源码：重点攻集合框架、并发包（JUC）、NIO、Stream 与 Lambda 新技术 保持对 Java 生态前沿的关注。 ...

OceanBase 集群架构详解：从图书馆比喻到原理剖析 OceanBase 是蚂蚁集团自主研发的分布式关系型数据库，其集群架构包含集群、Zone、Observer、租户、分区、Tablet、日志流、副本等多个概念。这些概念相互关联，初次接触容易混淆。本文将用"图书馆"作为贯穿比喻，逐一拆解每个组件的职责，最后串联成完整的架构图景。 阅读本文前，建议先了解前文《数据库核心机制详解》中的 WAL、MVCC、Redo Log 等基础知识，这些是理解 OceanBase 底层机制的前提。 一、核心组件的形象比喻 在深入细节之前，先用一个"大型图书馆系统"的比喻建立直观印象： 概念 图书馆类比 核心功能 集群 整个图书馆系统（含所有分馆、书籍、管理员） 管理所有资源，对外提供统一服务 Zone 不同城市的分馆（如北京馆、上海馆、深圳馆） 物理隔离的独立区域，用于容灾和资源分配 Observer 分馆内的书架（每个书架含多排书籍） 物理服务器，存储和处理数据 租户 不同类型的借阅者（如学生、教师、员工） 逻辑隔离的用户组，拥有独立资源配额和权限 分区 书籍按类别划分的区域（如小说区、科技区、历史区） 将大表数据分散到多个 Observer，提升扩展性 Tablet 每个类别中的具体书架排（如小说区第 1-10 排） 数据的最小存储单元 日志流 书籍借阅/归还的记录台账 记录 Tablet 的所有变更，保证一致性 副本 同一本书的多个复本 数据冗余备份，保证高可用 二、组件关系的深度解析 1. 集群与 Zone：全球图书馆网络 集群（Cluster） 是整个 OceanBase 实例的最高层级，包含所有 Zone、Observer、租户和数据。一个集群对外提供统一的数据库服务。 Zone 是物理隔离的独立区域，通常对应不同的数据中心或机房。每个 Zone 有独立的供电、网络和冷却系统，可以应对城市级灾难。 典型的部署模式： 三地五中心：三个城市五个 Zone，适合金融级高可用场景 同城三中心：同城三个 Zone，延迟低，容灾能力适中 两地三中心：两个城市三个 Zone，平衡成本和可用性 图书馆比喻：集群是整个图书馆系统，Zone 是分布在不同城市的分馆。当北京馆因火灾关闭时，深圳馆的副本数据仍可提供服务，实现城市级容灾。 2. Observer 与租户：书架与借阅者 Observer 是 OceanBase 的运行节点，运行在物理服务器或容器上，负责数据的存储和计算。每个 Zone 包含多个 Observer。 ...

MDC 加 ELK 全链路日志系统建设 1. 对应简历段落 对应简历中可以这样描述： 在微服务稳定性治理中，负责建设基于 MDC、Logback、Filebeat、Logstash、Elasticsearch、Kibana 的全链路日志系统。通过 traceId、spanId、userId、bizId、eventId 等上下文字段贯穿 HTTP 请求、Feign 调用、MQ 生产消费和异步线程，统一 JSON 日志格式、索引模板、脱敏规则和查询看板，显著提升商机流转、活动报名、出单回写等跨服务问题的定位效率。 这段经历强调的是可观测性。资深 Java 面试中，日志系统不是“把日志打到 ES”，而是如何让一次业务请求在多个线程、多个服务、多个中间件之间被串起来，并且能在故障时快速缩小范围。 2. 业务背景 商机和营销系统往往是典型微服务链路：入口网关接收请求，活动服务处理报名，客户中心建档，商机中心生成商机，销售工作台生成待办，RocketMQ 发送事件，报表消费者异步落库。任何一个环节失败，业务方看到的可能只是“报名后没有待办”或“出单后商机没更新”。 如果每个服务只打普通文本日志，排查就会非常痛苦。你需要按时间猜测请求，登录多台机器 grep，查完 HTTP 日志再查 MQ 日志，再查消费者日志。遇到高峰期日志量大，几乎无法定位。 全链路日志系统的目标是：拿到一个 traceId、bizId 或 eventId，就能查到这次请求从入口到下游、从同步到异步的完整路径。它不替代链路追踪系统，但能作为最基础、最可控、最贴近业务的排查工具。 3. 核心原理 MDC 是 SLF4J 提供的线程上下文机制，本质上是基于 ThreadLocal 存储一组 key-value。日志框架输出日志时，可以把 MDC 中的字段写入日志。常见字段包括： traceId：一次入口请求或业务链路的全局追踪 ID。 spanId：链路中的局部调用片段。 userId：当前登录用户。 bizId：业务主键，如商机 ID、订单 ID、保单 ID。 eventId：MQ 事件 ID。 source：来源系统或渠道。 ELK 负责采集、解析、存储和查询。应用输出 JSON 日志到文件，Filebeat 采集并发送到 Logstash 或 Elasticsearch，Logstash 做解析、过滤、脱敏和路由，Elasticsearch 建索引，Kibana 用于检索和看板。 ...