TranquilXuan

问题：一条请求穿过了 6 个系统，日志散落在 6 个地方在 MySQL / Doris / ES 三角选型 描述的架构中，一条用户请求的链路是这样的： 12345用户请求 → Spring AI 应用 → MySQL（写入订单） → Canal（监听 binlog） → Kafka（消息队列） → Doris Routine Load（消费写入） → ES（双写更新索引） 加上 AI 调用： 123→ Spring AI ChatClient → LLM API（OpenAI/Anthropic） → RAG 检索（ES kNN 查询） → Tool 调用（查 MySQL） 一条请求可能穿过 8 个系统。 当用户反馈”我的订单查不到”时，你怎么定位是哪一环出了问题？ 日志在每个系统里： Sprin ...

存算分离不是”升级”，是架构选择Apache Doris 从 3.0 开始支持存算分离（Cloud 模式），到 4.0/4.1 已经有 2000+ 家公司在生产环境使用。但”2000 家在用”不等于”你该上”。 先搞清楚一个核心问题：存算分离不是存算一体的”升级版”，而是一种不同的架构选择，有不同的适用场景。 存算一体（Shared-Nothing）123BE 节点 1: [计算 + 本地存储] ← 数据分片 1BE 节点 2: [计算 + 本地存储] ← 数据分片 2BE 节点 3: [计算 + 本地存储] ← 数据分片 3 每个 BE 节点既负责计算也负责存储，数据存在本地磁盘。查到哪个节点，就在哪个节点本地计算。 优势： 计算和存储在同一台机器上，数据读取零网络开销，查询延迟最低。 劣势： 计算和存储耦合，扩容时必须同时加计算和存储资源。存储不够了但计算够用？也必须加整台机器。 存算分离（Cloud 模式）1234计算集群 A: [计算] ←→ 计算集群 B: [计算] ←→ 对象存储 (S3/OSS/MinIO) ↕ ...

为什么 MCP 突然重要了如果你一直在跟 Spring AI，可能已经注意到了一个变化：从 Spring AI 2.0 GA 开始，MCP（Model Context Protocol）不再是社区孵化项目，而是被合并进了 Spring AI 核心。 这意味着什么？ 你的 Spring Boot 应用现在可以同时扮演两个角色： MCP Client：连接外部 MCP Server（文件系统工具、数据库访问、第三方 API） MCP Server：把自己的业务逻辑暴露为 MCP 工具，供任何 MCP 兼容的 AI 客户端调用 以前你写一个 @Tool 方法，只有你自己的 ChatClient 能调用。现在写一个 @McpTool 方法，任何支持 MCP 的 AI 客户端都能调用——Claude Desktop、Cursor、Windsurf，或者另一个 Spring AI 应用的 MCP Client。 这不只是 API 变了，是架构选择变了。 @McpTool 和 @Tool 有什么区别先搞清楚边界。 维度 @Tool（Spring AI 1.x / 2.0） @Mc ...

问题在 MySQL / Doris / ES 三角选型 一文中，我给出了”MySQL 做事务、ES 做搜索、Doris 做分析”的分工框架。在 ES 与 MySQL 双写一致性 和 Outbox 模式 中，我写了怎么用 MQ 和 Outbox 尽量保证数据同步的一致性。 但有一个问题一直没正面回答： 同步链路再完善，最终也会不一致。怎么办？ CDC 可能丢消息、MQ 可能重复投递、消费者可能超时、ES 的 refresh interval 可能导致刚写入的数据查不到、Doris 的 Routine Load 可能因为数据格式错误跳过一批。这些不是”如果”，是”什么时候”。 当不一致发生时，你的系统需要一个兜底机制——对账。 先定义”不一致”是什么意思三个系统的数据不一致，有几种典型表现： 不一致类型 表现 典型原因 MySQL 有、ES/Doris 没有 新数据在 MySQL 但搜索/分析查不到 CDC 延迟、MQ 丢消息、消费者宕机 MySQL 没有、ES/Doris 有 已删除的数据在搜索/分析里还在 删除 ...

问题在 从 Canal 到 Doris 的数据同步链路 一文中，我写了用 Canal 做 MySQL → Kafka → Doris 的同步。但有一个问题一直没展开： Canal 一定是对的选择吗？ 如果你在做 MySQL → Doris 的实时同步，可选的 CDC 工具至少有四个：Canal、Debezium、Maxwell、阿里云 DTS。它们都能读 MySQL binlog，都能把变更发到 Kafka。但选错了，运维成本和踩坑深度完全不同。 四个工具各自是什么Canal（阿里）阿里开源的 MySQL binlog 增量订阅组件。国内 Java 生态使用最广泛。 架构：伪装成 MySQL Slave，接收 binlog 事件 数据格式：自定义 protobuf + JSON 部署模型：Server-Client 模式，Canal Server 作为独立进程 管理界面：Canal Admin（Web UI） 社区活跃度：国内活跃，国际几乎无人用 Debezium（Red Hat）Red Hat 开源，基于 Kafka Connect 框架，国际化标准 CDC 方案。 架构：Ka ...

一个被忽略的问题在 Spring AI 2.0 GA 升级清单 一文中，我提到了 Advisor 是 Spring AI 2.0 的核心抽象。但有一件事当时没有展开——Advisor 的顺序。 用 Spring AI 的 ChatClient 写一个带对话记忆 + 工具调用的 AI 助手，你可能会这样写： 1234567ChatClient chatClient = ChatClient.builder(chatModel) .defaultAdvisors( new MessageChatMemoryAdvisor(chatMemory), new ToolCallingAdvisor(toolCallbackProvider), new QuestionAnswerAdvisor(vectorStore) ) .build(); 看起来没问题。但这个顺序——Memory → Tool → QA——真的是对的吗？ 顺序不同，结果可能完全不同。 Advisor 链是怎么工作的先理解 Spring AI 的 Advisor 机 ...

问题在 之前的文章 里，我写了用 Outbox 模式保证 RAG 数据一致性。核心思路：业务数据和 outbox 记录在同一个数据库事务里写入，然后用 CDC（Canal/Debezium）把 outbox 记录搬到 MQ，消费者再去同步 ES/Doris。 但有一个问题一直被绕开了： 如果你的 MQ 是 RocketMQ，你还需要 Outbox 吗？ RocketMQ 原生支持事务消息——半消息 + 本地事务 + 回查机制。这本身就是”保证本地事务和消息发送原子性”的方案。既然 MQ 原生就能做，为什么还要写一张 outbox 表？ 这是做 AI 后端时真实会碰到的选择。两条路都能到终点，但代价不同。 先搞清楚两个方案各自在做什么Outbox + CDC1应用 → MySQL 事务 { 业务表 + outbox 表 } → CDC 监听 binlog → 发送到 MQ → 消费者 核心思想：把”发消息”变成”写数据库”。 只要业务数据和 outbox 记录在同一个事务里，要么一起成功，要么一起失败。消息的发送由独立的 CDC 组件异步完成，与 ...

Elastic 自己承认了什么2026 年 7 月 9 日，Elastic 官方工程博客发了一篇文章，标题是 Why Elasticsearch is becoming a columnar database。 这篇文章里有一句话值得反复读： “When your job is to read and reason about a lot of data, columnar storage turns nearly every dimension of cost and performance in your favor.” 这是一个做了 16 年文档搜索引擎的团队，在自己的工程博客上承认：他们最初选择的架构，对于今天大部分用户真正在跑的工作负载（日志、指标、遥测、分析），是错误的选择。 ES 9.5 将引入 Columnar Mode（列式模式），9.6 GA。数据只存一份，按列组织，不需要的索引不建。 这不是”ES 加了个新功能”很多人第一反应是”ES 又加了个存储引擎，跟以前加 doc_values、加 kNN 一样”。 不一样。 之前 ES 每加一个能力，都是在文档模型上” ...

一个正在形成的共识UberConf 2026 的安全议题中出现了一句话： Agents must earn autonomy rather than start with it.（Agent 必须挣得自主权，而不是一开始就拥有它。） 这句话来自 UberConf 2026 的 Agent Governance 分享。它不是技术建议，而是工程原则——和”最小权限原则”一样，正在成为 Agent 工程的默认约束。 为什么”挣得自主权”是正确的原则1. Agent 的 blast radius 比传统服务大得多传统微服务的 blast radius 是可预测的：一个 API 调用失败，影响范围是调用链上的下游服务。 Agent 的 blast radius 是不可预测的： Agent 可以调用任意工具（包括写数据库、删文件、执行 shell） Agent 的行为路径不是预定义的，而是模型推理出来的 Agent 可以在”推理”中决定改变自己的行为目标 这意味着：Agent 的权限边界不能用 API gateway 那种”路径+方法”模型来管。 2. OAuth 2.1 token 生命 ...

一个被忽视的截止日期2026 年 6 月 30 日，Spring Boot 3.5 正式停止维护（End of Life）。 这意味着什么？ 运行 Spring Boot 3.5 的系统不再收到任何安全补丁。Spring Security 和 Spring Cloud Gateway 中已知的可利用漏洞将不再被修复。 而 Spring AI 2.0 GA 要求 Spring Boot 4.0+。 也就是说：如果你在用 Spring AI 2.0，你已经在 Spring Boot 4.0 上了。但如果你还在 3.x，你需要知道这个时间窗口已经关闭了。 为什么这不是”可以慢慢迁”的事在 UberConf 2026 的安全议题中，有一个被反复强调的观点： Spring Boot 3.5 EOL 不是一个”建议升级”通知，而是一个”安全暴露窗口已打开”的警告。运行未打补丁的 post-EOL 版本面临的是已文档化的、可利用的漏洞，且无法获得后续 CVE 修复。 这不是理论风险。Spring Security 和 Spring Cloud Gateway 的漏洞历史已经证明：公开的 CV ...