D1 · 融合蓝图：Spring AI + 虚拟线程 + 服务网格——现代后端统一底座

D1 · 融合蓝图：Spring AI + 虚拟线程 + 服务网格------现代后端统一底座

系列第 15 篇 / D 线第 1 篇（全系列收官）

视角：架构师选型 · 深度长文 · 总纲

串联：A1 虚拟线程 · A2 JDK/GC · A3 原生镜像 · A4 Boot 4 · B1 架构优先 · B2 RAG · B3 MCP · B4 多智能体 · B5 模型路由 · B6 护栏可观测 · C1 网格 · C2 OTel · C3 适度微服务 · C4 Serverless
14 篇分开看是 14 个选型决策，合起来是一座现代后端系统的骨架。本文把它们拧成一张蓝图：一个跑着虚拟线程、原生镜像冷启、Spring AI 编排、网格护体、OTel 透视、Agent 多智能体、护栏守门的现代后端，到底长什么样。

一、蓝图总览：一座现代后端系统的分层骨架

复制代码

┌──────────────────────────────────────────────────────────────────┐
│  边界 / 接入层                                                     │
│   API 网关 · WAF · 身份(IdP) · 限流 · 提示注入防护(B6)             │
└──────────────────────────────────────────────────────────────────┘
                │  mTLS（网格加密，见 C1）
┌──────────────────────────────────────────────────────────────────┐
│  治理 / 控制面（平台团队统一建设，见 C1/C2/C3）                    │
│   服务网格 Istio Ambient / Cilium eBPF  ·  mTLS/重试/熔断/路由      │
│   OpenTelemetry Collector  ·  Trace/Metric/Log 统一(含 gen_ai.*)   │
│   平台工程 IDP  ·  Golden Path 流水线  ·  秘钥/策略(OPA)           │
└──────────────────────────────────────────────────────────────────┘
                │  服务间调用（Envoy/内核 eBPF 透明拦截）
┌──────────────────────────────────────────────────────────────────┐
│  AI 编排层（Spring AI，见 B1--B6）                                 │
│   ChatClient  ── Advisor 链 ──┬─ QuestionAnswerAdvisor(RAG, B2)   │
│                                ├─ SafeGuardAdvisor(护栏, B6)       │
│                                ├─ ObservationAdvisor(可观测, C2)   │
│                                └─ 自定义(配额/缓存/记忆)           │
│   VectorStore(PGVector/Milvus, B2)  ·  MCP Tools(B3)  ·            │
│   Model Gateway(路由/成本, B5)  ·  Multi-Agent Control Plane(B4)   │
└──────────────────────────────────────────────────────────────────┘
                │  业务调用（同步 / 事件驱动分治，见 C3/C4）
┌──────────────────────────────────────────────────────────────────┐
│  应用框架 / 运行时（Spring Boot 4，见 A1--A4）                     │
│   @Service / @Repository 业务域  ·  虚拟线程(默认并发, A1)         │
│   GraalVM 原生镜像(<50ms 冷启, A3)  ·  JDK 21/25 + ZGC(A2)        │
│   Jakarta EE 11 / HTTP Interface / 原生弹性注解(A4)                │
└──────────────────────────────────────────────────────────────────┘
                │  部署（按流量画像分治，见 C3/C4）
┌──────────────────────────────────────────────────────────────────┐
│  部署形态                                                            │
│   常驻微服务(ECS/EKS + 网格, C3)  ·  Serverless(Lambda/Knative, C4)│
│   ·  模块化单体(起步, C3)  ·  事件总线(Kafka/NATS, C3)             │
└──────────────────────────────────────────────────────────────────┘

这张图不是「全堆上」的购物清单，而是分层解耦、各层独立演进的底座。下面逐层对应到前面的篇目。

二、各层技术选型映射（一张表收束 14 篇）

层级	本文技术选型	决策依据	对应篇目
运行时	JDK 21（新项目）/ JDK 25（极致延迟）	虚拟线程 GA、生态稳、紧凑对象头省堆	A2
GC	G1（通用）/ ZGC·Shenandoah（P99<10ms 或堆>32G）	同步等待 + SLA 驱动	A2
并发模型	虚拟线程（默认）	同步写法、异步性能、近全生态兼容	A1
构建/冷启	GraalVM 原生镜像（Serverless/弹性）	<50ms、内存降 4×、构建 10--15min	A3
框架	Spring Boot 4（Jakarta 11 / HTTP Interface / 原生弹性）	两跳升级、能力红利	A4
AI 编排	Spring AI 1.1.x（ChatClient + Advisor）	1.0 GA 2025-05、生产稳定线	B1--B6
检索	RAG（混合检索 + rerank + GraphRAG 路由）	检索卫生决定 80% 效果	B2
工具	MCP（tools/resources/prompts）	后端能力 ↔ 模型统一协议	B3
多智能体	Control Plane（协调/评估/护栏/人审）	多智能体 = 新型微服务	B4
成本	Model Gateway（SLM+LLM 路由）	成本降 60--80%	B5
护栏	四层护栏 + LLM-as-judge	生产化最后一道门	B6
服务网格	Istio Ambient / Cilium eBPF	sidecar 退场、按场景选	C1
可观测	OpenTelemetry（含 gen_ai.*）	Trace/Metric/Log 一把梭	C2
拆分	适度微服务（模块化单体起步）	微服务税近似线性	C3
部署	常驻 / Serverless 分治	流量画像决定部署模型	C4

这张表就是全系列的「选型字典」。架构师的功力不在记住每一项，而在知道每一项在什么情境下该被触发。

三、融合的关键：Spring AI 如何把 B 线串成一条链

整座蓝图里，Spring AI 是「AI 编排层」的胶水 。它的核心设计哲学------「一切皆可 Advisor」------正好把 B2 检索、B6 护栏、C2 可观测全部插进同一条调用链，不侵入业务代码。

java 复制代码

@Configuration
public class AiConfig {
    @Bean
    public ChatClient chatClient(ChatClient.Builder builder,
                                 VectorStore vectorStore,
                                 ChatMemory memory) {
        return builder
            .defaultSystem("你是专业客服助手，禁止捏造信息")
            // RAG：自动从向量库召回并注入上下文（B2）
            .defaultAdvisors(
                new QuestionAnswerAdvisor(vectorStore,
                    SearchRequest.defaults().withTopK(5)),
                // 护栏：PII/敏感词过滤、越狱拦截（B6）
                new SafeGuardAdvisor(),
                // 多轮记忆
                new MessageChatMemoryAdvisor(memory),
                // 可观测：每次调用自动打 OTel span（C2）
                new ObservationAdvisor(),
                // 结构化日志
                new SimpleLoggerAdvisor())
            .build();
    }
}

@RestController
@RequestMapping("/api/chat")
public class ChatController {
    private final ChatClient chatClient;
    public ChatController(ChatClient.Builder b, VectorStore vs, ChatMemory m){
        this.chatClient = aiConfig(b, vs, m); // 见上
    }
    // 虚拟线程下并发处理（A1）；流式用 Flux 转 SSE
    @GetMapping(value = "/stream", produces = TEXT_EVENT_STREAM_VALUE)
    public Flux<String> stream(@RequestParam String msg,
                               @RequestParam String cid) {
        return chatClient.prompt()
            .user(msg)
            .advisors(a -> a.param(CONVERSATION_ID, cid))
            .stream().chatResponse()
            .mapNotNull(r -> r.getResult().getOutput().getText())
            .timeout(Duration.ofSeconds(60))
            .onErrorReturn("[服务暂不可用]");
    }
}

这段代码把 B 线五篇（架构优先/检索/工具/护栏/成本）收敛到 defaultAdvisors(...) 一行配置里------这正是 B1 说的「架构优先于模型」：模型只是 ChatClient 的一个配置项，真正的护城河在这条 Advisor 链上。

模型切换是部署关注点，不碰代码：

yaml 复制代码

spring:
  ai:
    openai: { api-key: ${OPENAI_API_KEY}, chat.options.model: gpt-5 }
    # 切到便宜模型只改这里（配合 B5 Model Gateway 做自动路由）

四、与 A 线咬合：Java 底座是「免费午餐」

蓝图跑在 A 线的 Java 底座上，四条链路彼此咬合：

虚拟线程（A1）是默认并发模型 ：AI 调用大量是 I/O 等待（等模型 Provider、等向量库、等 MCP 工具），虚拟线程把同步写法跑出异步吞吐，且 Advisor 链、Spring 生态全兼容。⚠️ 但 A1 强调的 synchronized pinning 与 ThreadLocal 泄漏在这里会被放大------Spring AI Advisor 链内部用 InheritableThreadLocal 传上下文，开虚拟线程后任务切换不保证线程连续，必须用 ScopedValue 或显式传参替代 （同时回扣 C2 的 context 传播、B6 的 trace 关联）。
GraalVM 原生镜像（A3）是冷启解 ：Serverless/弹性扩容场景（C4）下，AI 推理服务若常驻浪费、若常规模型冷启几秒------原生镜像 <50ms 冷启 + 内存 30--80MB，正好让 AI 服务「缩容到零、峰来即弹」。Spring AI 1.0.3+ 已支持原生镜像。
JDK 21/25 + ZGC（A2）：高吞吐长运行服务用 ZGC 把 P99 停顿压到亚毫秒，AI 批量推理/向量写入不卡顿。
Spring Boot 4（A4） ：Jakarta EE 11 基线、HTTP Interface 替代 Feign 调内部服务、原生弹性注解（@Retryable/@CircuitBreaker）替代 Resilience4j、OTLP 开箱即用------把 A3 原生镜像、C1 网格、C2 可观测拧成出厂默认。

五、与 C 线咬合：治理是「平台团队统一买单的税」

蓝图里 C 线的三篇不是「可选装饰」，是 AI 系统上生产的硬前提：

服务网格（C1）：MCP Server、Multi-Agent、护栏网关彼此服务间调用，mTLS/重试/熔断/路由由网格透明提供，应用零改造；选型按场景（已用 Cilium CNI 直接开、已有 Istio 迁 Ambient、最简选 Linkerd）。
OpenTelemetry（C2） ：gen_ai.* 语义约定是 OTel 一部分，一次 Agent 调用从「网关 → 业务 → MCP Server → 模型 Provider → 护栏拦截」的 waterfall 无侵入可得 ------前提是 A1 的 context 传播修好、A3 的 build-time hints 登记好。
适度微服务 + Serverless（C3/C4） ：蓝图的部署形态是分治的------同步低延迟用户面（RAG 检索、护栏网关、Model Gateway、Control Plane）走常驻微服务 + 网格 ；事件驱动的 AI 任务（异步文档解析、批量 Embedding、Agent 后台步骤）走 Serverless 。这是 C3 适度精神在部署层的延伸：能托管就别自建，按流量画像分治。

六、一次真实请求的端到端链路（14 篇全串起来）

用户问「我们上月华东区退款率是多少，归因给哪些环节？」------这条请求穿过整座蓝图：

边界（B6）：网关层 WAF + 提示注入防护先拦一遍越狱/投毒；
网格（C1）：请求经 Envoy/eBPF 透明加 mTLS，按路由规则转发；
应用框架（A4/A1） ：Spring Boot 4 接到请求，虚拟线程承载，进入 ChatController；
Spring AI 编排（B1） ：ChatClient 触发 Advisor 链------
- QuestionAnswerAdvisor 调 VectorStore（B2） 做混合检索 + rerank，召回退款率文档；
- SafeGuardAdvisor 校验输出不含 PII/越权数据（B6）；
- ObservationAdvisor 给本次调用打 OTel span（C2） ，带 gen_ai.* 属性；
工具调用（B3） ：模型决定要实时数据，经 MCP 调「退款率查询」工具（后端 Spring @Bean Function，类型安全）；
模型路由（B5）：Model Gateway 把这条「需推理+需工具」的请求路由到前沿模型，简单分类请求则由 SLM 吃掉（成本降 60--80%）；
多智能体（B4）：若问题跨域，Control Plane 编排「数据 Agent + 归因 Agent」协作，人审门（Tier 分级）决定是否需要人工确认；
护栏回退（B6）：输出经事实性校验、命中红线则降级到安全回复；
可观测（C2） ：全程 trace 串起网关→业务→MCP→Provider→护栏，tenant_id/feature 在 span 创建时打标，成本归因从 span 算而非账单（避开推理 token 5--20× 低估陷阱）；
部署（C3/C4） ：这条同步链路跑在常驻微服务 + 网格上；而背后的批量 Embedding 任务跑在 Serverless，同一套 @Service 只换入口。

这一条链路，就是 14 篇的全部落地。你写的不是一个「AI 功能」，是一套数据---工具---编排---成本---护栏---证据 六位一体的系统------B6 收官时说的那句话，在这里成为现实。

七、落地路线图（分阶段，每阶段可独立回退）

不要把蓝图一次性推倒重来。按「底座 → 治理 → AI → 融合」四阶段演进，每阶段都有回退开关：

阶段	目标	关键动作	回退
阶段 0：Java 底座（A 线）	并发/冷启/框架现代化	JDK 21 升级、开虚拟线程、Boot 4 两跳迁移、评估原生镜像	虚拟线程开关 `spring.threads.virtual.enabled=false`；Boot 3.5.x 安全补丁兜底
阶段 1：云原生治理（C 线）	服务间安全 + 统一可观测	网格（按场景选）、OTel Collector + `gen_ai.*`、平台 IDP	网格可先窄范围 mTLS，观测先 Collector Gateway 前置不破坏现有
阶段 2：AI 编排（B 线）	把 AI 能力产品化	Spring AI 接 ChatClient、先建 eval harness、RAG 检索卫生、MCP 工具、Model Gateway、护栏	模型无关抽象层 + 影子发布；护栏可降级为「仅告警不阻断」
阶段 3：融合（D 线）	全链路打通	Advisor 链串 RAG+护栏+可观测、Control Plane 治理多智能体、按流量分治部署	每层的开关独立，可逐层回退到上一阶段

元原则（回扣 B5）：先有 eval harness，再开任何高级能力。没有度量的 AI 系统，上线即负债。

八、系列回顾与架构师寄语

15 篇，三条主线，一个底座：

A 线 · Java 后端演进（4 篇）：虚拟线程 → JDK21/25+GC → GraalVM 原生镜像 → Spring Boot 4。底座升级彼此咬合：虚拟线程要 JDK 21、原生镜像要 AOT、Boot 4 把三者拧成出厂默认。
B 线 · AI 工程化（6 篇）：架构优先于模型 → RAG 检索卫生 → MCP 工具协议 → 多智能体 Control Plane → 模型路由成本 → 护栏与可观测。模型会被替换，你建的那套「数据---工具---编排---成本---护栏---证据」体系才是抄不走的护城河。
C 线 · 云原生治理（4 篇）：服务网格选型 → OpenTelemetry 统一可观测 → 适度微服务 → Serverless 与 Java 冷启动。能不能托管就别自建、按流量画像分治部署，是「适度」精神的延伸。
D 线 · 融合蓝图（1 篇）：把 A/B/C 拧成一座现代后端系统的骨架。

三句给架构师的话：

模型是配置项，架构是护城河。 你围绕模型建的那套系统，比模型本身更值钱、更难被抄。
每一层都有税，聪明在于知道什么时候不交。 微服务税近似线性、Serverless 暖机税真实存在、原生镜像构建税 10--15min------用「按情境触发」替代「盲目追新」。
分层解耦、独立演进。 蓝图之美不在堆技术，而在每一层都能单独升级、单独回退、单独度量。这正是 15 篇每一篇都能独立成立、合起来又能咬合的原因。

全系列 15 篇至此收官。 如果你要把它变成一份可分享的「现代后端选型手册」，我可以帮你：① 生成一份系列目录/索引页（带每篇一句话结论）；② 把 15 篇合并成一份 PDF/Word 长文档；③ 提取全系列的「决策表合集」做速查卡。说一声即可。

附录：全系列 15 篇速查

编号	篇目	一句话结论
A1	虚拟线程落地	I/O 密集新项目优先虚拟线程，同步写法异步性能
A2	JDK21/25+GC	新项目 JDK 21，极致延迟上 25；GC 按 SLA 选
A3	GraalVM 原生镜像	Serverless/弹性首选，<50ms 冷启、内存降 4×
A4	Spring Boot 4 迁移	两跳升级，Jakarta 11 + 能力红利
B1	架构优先于模型	模型趋同，架构才是护城河
B2	RAG 实战	检索卫生决定 80% 效果
B3	MCP 通解	后端能力 ↔ 模型的 USB-C 标准
B4	多智能体 Control Plane	多智能体 = 新型微服务，治理面是护城河
B5	模型路由与成本	SLM+LLM 路由降本 60--80%
B6	AI 护栏与可观测	生产化最后一道门
C1	服务网格选型	sidecar 退场，按场景选 Ambient/eBPF/Linkerd
C2	OpenTelemetry	Trace/Metric/Log 一把梭，含 gen_ai.*
C3	适度微服务	微服务是税，适度才理性
C4	Serverless 与冷启动	冷启动已非死穴，按流量分治
D1	融合蓝图	把 A/B/C 拧成一座现代后端骨架