TranquilXuan

为什么要升级Spring AI 2.0 GA 在 2026-06-12 发布，距离 1.0 不到一年。但这次的升级不是版本号小跳，而是把 1.x 时代所有”能用但别扭”的地方做了重写。 如果不升级，1.x 还能用，但你会逐渐被以下问题卡住： 工具超过 20 个时 token 爆掉 不同 ChatModel 的 Tool Calling 行为不一致 配置项命名混乱（.options 段、toolNames() 等） MCP 集成停留在早期规范 项目想升级 Spring Boot 4 时和 Spring AI 1.x 不兼容 反过来，升级的代价是真实的：Spring AI 2.0 硬依赖 Spring Boot 4.0/4.1 + Spring Framework 7.0 + Java 17（推荐 21），整个项目的依赖链都要跟着走。 变化 1：基线重定义，升级是”全家桶”2.0 依赖： Spring Boot 4.0 / 4.1 Spring Framework 7.0 Jackson 3（不是 Jackson 2） Java 17 起步，推荐 21 MCP J ...

问题“我应该把数据放在哪？” 这是任何一个数据密集型 AI 后端项目启动时第一个会撞上的问题。但不是”哪个最好”的问题，而是”应该用哪几个、各自负责什么”的问题。 今天 Java 后端做 AI 应用，可选的”核心数据组件”基本就是这三件套：MySQL、Doris、Elasticsearch。再加一个 MQ 做异步。 但这三个东西看起来都能存数据、都能做查询，凭什么非要全用上？为什么不能只用一个？ 重新认识这三件东西在聊选型之前，必须先纠正一个常见误解：这三件东西不是同类。 组件 真正擅长的事 不擅长的事 MySQL 强一致事务、随机点查、行级更新、垂直扩展 大规模 OLAP 聚合、模糊搜索 Doris 大数据量 OLAP 聚合、列存压缩、向量化执行 强事务（只能最终一致）、行级单点更新 Elasticsearch 倒排索引全文搜索、近似向量检索、多维度过滤 强事务、复杂 JOIN、精确聚合统计 它们在 2026 年都开始”补对方的能力”：MySQL 9.2 有了向量搜索，Doris 4.x 有了全文搜索+向量+AI Functions，ES 也有了 PPL 之类 ...

Agent 会先改变代码评审，而不是完全替代编码AI 编程工具让代码生产速度大幅提升，但代码审查速度没有同步提升。 这制造了一个新的瓶颈：审查队列变长、大型 PR 被”扫一眼就过”、人类审查者疲劳加剧。Agent 最先切入的，不是取代程序员写代码，而是接管审查流程中结构化、可规模化复制的部分。 审查正在成为瓶颈Anthropic 内部数据显示，在使用 Claude Code Review 之前，只有 16% 的 PR 收到实质性审查意见。这意味着 84% 的 PR 只是被快速浏览后就合并了。 原因很直接： AI 让单个工程师的代码产出增长了约 200%。 但审查者还是那些人，每天还是那么多小时。 PR 数量增加、单个 PR 复杂度上升、审查者上下文切换成本更高。 结果不是代码质量下降，而是质量保障体系开始跟不上生产节奏。 为什么 Agent 先改变的是审查？代码评审有几个特点，让它特别适合 Agent： 1. 任务高度结构化审查有明确的输入（diff、测试、上下文）和输出（评论、建议、风险标记）。这比”从零写一个新功能”更容易被形式化。 2. 上下文可枚举一次 PR 改动了什么 ...

为什么模块化单体正在回归？微服务曾经是一种信仰。 2015 到 2020 年间，几乎所有技术大会都在讲 Netflix、Amazon、Google 的微服务故事。结论是：大公司用了，我们也应该用。于是无数团队把系统拆成十几个、几十个服务，仿佛服务数量本身就是工程成熟度的指标。 2026 年，钟摆正在回摆。不是回到混乱的大泥球，而是回到一种更克制的中间态：模块化单体。 发生了什么？微服务被过度推销了。 Netflix、Amazon 采用微服务，是为了解决数百个工程团队、数亿用户带来的问题。这些问题对于一家 20 人的初创公司来说并不存在。但很多人忽略了这个前提，直接复制了答案。 结果是可预测的： 服务发现、分布式追踪、网络可靠性、数据一致性、部署编排——基础设施工作吞噬了大量本应用于产品的工程能力。 一个原本简单的功能，现在要跨多个服务协调部署。 调试生产问题意味着追踪几十个服务各自的日志和监控。 到了 2023 年前后，一些公司开始公开往回走。Amazon Prime Video 团队发布案例：将微服务整合为单体后，**成本降低 90%**。Shopify 则一直坚持自己的模块化 ...

AI 时代，后端工程师的哪些能力正在贬值？2026 年，后端工程师这个群体正在经历一次静默而剧烈的价值重估。 不是岗位消失，而是市场对”后端工程师”的定义在重写。过去十年里被视为核心竞争力的许多能力，正在快速贬值；而另一些长期被低估的能力，突然变得稀缺。 这不是贩卖焦虑，而是一组正在发生的信号。 一组值得正视的数据 Anthropic 内部数据：生产环境超过 80% 的代码由 Claude 生成，工程师日均代码产出提升约 8 倍。 猎聘 2026 报告：纯编码岗位招聘量暴跌 **52%**，但编程相关岗位总量反增 15%。 GitClear 2026 报告：AI 参与编写的代码，一年内有 47% 被完全重写。 智联招聘 2026 一季度报告：普通后端、前端开发岗位需求同比下降 **52%**。 麦可思《2026 年中国大学生就业报告》：计算机类专业跌出绿牌榜，自动化专业首次跻身绿牌。 这些数据拼在一起，指向一个结论：**市场不再需要”会写代码的人”，市场需要”能用 AI 解决问题的人”**。 这两个身份曾经高度重合，现在正在快速分离。 正在贬值的能力1. 纯语法与 API 记忆过 ...

Doris 在做什么Apache Doris 从 4.0 开始，加入了一个新方向：AI 支持。具体包括： 向量搜索：原生支持向量存储和 ANN 检索，类似专用向量数据库的能力。 AI Functions：SQL 中可以直接调用大模型（如 ai_generate() 函数）。 全文搜索增强：和向量搜索结合做混合检索。 这听起来有点像”Doris 想做向量数据库”。但它的实际意图比这更有趣。 为什么一个 OLAP 数据库需要向量搜索？Doris 的核心用户是数据分析师和运营人员。他们的问题是：”上个月销售额最高的品类是哪些？和去年同期比有什么变化？” 但现在的问题是：”为什么这个品类的销量突然下降了？帮我分析原因。” 这个问题的答案不在结构化数据（数字）里，而在非结构化数据里——用户评价、客服对话、社交媒体反馈。传统的 Doris 只能算数字，不能”理解”文本。 Doris 加向量搜索不是为了抢 Milvus 的饭碗，而是为了把”结构化分析”和”非结构化检索”放在同一个引擎里。 具体能做什么？1. “找出和这个问题最相似的历史案例”123456-- 用向量搜索召回与当前问题最相似的历史 ...

两个框架，一个生态2026 年，Java AI 开发生态最核心的两个框架是 Spring AI 和 Spring AI Alibaba。很多人听到名字以为后者是前者的”阿里版封装”，但实际关系比这复杂。 Spring AI 2.0：2026 年 6 月 12 日发布 GA，基于 Spring Boot 4.1 和 Spring Framework 7.0。官方定位是”连接企业数据和 API 与 AI 模型”——让 LLM 像 JDBC、JMS 那样成为企业系统里一个可插拔的中间件。 Spring AI Alibaba 1.1.2.0：基于 Spring AI 规范构建，但聚焦于多智能体编排（Multi-Agent Orchestration）。内置 Agent 框架、Graph 工作流引擎、MCP 双端支持。 通俗类比：Spring AI 是 Java 的 LangChain（怎么接入 AI），Spring AI Alibaba 是 Java 的 LangGraph（怎么让多个 AI 协同工作）。两者不是竞争关系，是互补关系。 架构层次对比12345678910应用层： ┌───── ...

MQ 的传统角色MQ 在后端架构里一直是”老三样”： 异步解耦：订单创建后，发消息通知库存、物流、通知系统，各系统独立消费。 削峰填谷：秒杀流量来了，MQ 先扛着，后端慢慢消费。 最终一致性：分布式事务的兜底方案——本地事务 + MQ 消息 = 可靠异步通知。 这三个角色在今天仍然重要。但 AI 后端的出现，给了 MQ 一些新的可能性。 Agent 需要一个事件总线看一个场景：用户在 Spring AI 应用里发起一个对话，Agent 需要串联多个操作——搜索 ES、查 MySQL、调用外部 API、生成回答。 传统做法是把这些调用写在 Agent 的逻辑里，串行执行。但如果 Agent 需要等待一个长时间操作（比如跑数据分析、等第三方回调），串行就不行了。 这时候 MQ 可以扮演 Agent 事件总线： 1234用户提问 → Agent 发布"需要搜索文档"事件 → MQ → ES 搜索 Worker 消费 → 返回结果事件 → MQ → Agent 消费结果 → 发布"需要生成回答"事件 → MQ → LLM ...

问题一个业务系统通常有两套”检索”： 关键词搜索：用户在搜索框输入”Java 教程”，ES 用 BM25 返回最匹配的文档。这是传统搜索。 语义检索：用户在 AI 对话里问”怎么学 Java”，RAG 用向量相似度从知识库召回相关内容。这是 AI 搜索。 传统做法是两套栈：ES 做关键词搜索，Milvus/Qdrant 做语义搜索。但 ES 从 8.x 开始原生支持 kNN（k-Nearest Neighbors）向量检索。于是就有一个诱人的想法：能不能只用 ES 一套，同时做关键词搜索和 RAG 语义搜索？ ES 的 kNN 做了什么ES 8.0 引入了 dense_vector 字段类型 + knn 查询。8.12 后做了性能优化，支持 HNSW 索引。 123456789101112131415161718192021222324// mapping 定义{ "mappings": { "properties": { "content": { &qu ...

背景Doris 不是凭空产生数据的。它是个”理解数据”的引擎，数据需要从别处来。 在数据密集型后端架构里，数据来源通常是： 业务数据库（MySQL）：用户、订单、商品等结构化数据 日志/埋点：用户行为、系统日志等半结构化数据 外部数据：第三方 API、合作伙伴数据 这些数据到达 Doris 的路径大致是： 1数据源 → 消息队列 → Doris 消息队列是整个数据管道的”中央动脉”。理解不同的接入方式及其取舍，是搭建数据处理链路的基础。 方式一：Routine Load（最常用）Routine Load 是 Doris 从 Kafka 持续消费数据的方式。提交一个例行导入任务后，Doris 会持续从 Kafka 拉取数据，实时写入。 12345678910111213CREATE ROUTINE LOAD example_db.routine_load_job ON user_behaviorCOLUMNS(user_id, event_type, event_time, page_url)PROPERTIES( "desired_concurrent_ ...