Kubernetes on 小盒子的技术分享

拒绝内卷！为什么我们应该抵制用 LeetCode 考查真实的工程师？

Wed, 04 Mar 2026 08:41:32 +0000

拒绝内卷！为什么我们应该抵制用 LeetCode 考查真实的工程师？

如果你要招募一位主刀医生，你会让他当场默写《人体解剖学》的第一章吗？如果你要找一位米其林大厨，你会蒙住他的眼睛，让他比赛在一分钟内切出多少根标准厚度的土豆丝吗？

显然不会。但在如今的软件工程招聘中，我们却在做着同样荒谬的事情：让那些在复杂的业务泥潭中摸爬滚打、主导过千万级并发系统、熟练操纵复杂云原生架构的资深工程师，站在白板前，徒手写出一个“翻转二叉树”或者“接雨水”的最佳时间复杂度解法。

不知从何时起，“刷 LeetCode”已经从一种思维训练，演变成了一场病态的军备竞赛。是时候戳破这个泡沫了：LeetCode 根本选拔不出优秀的软件工程师，它正在毁掉我们的行业生态。

一、真实的工程世界，从来不是一道“闭卷考试”

让我们先来看看，一个现代软件工程师的真实一天是怎样度过的。

你可能会花一整个上午，在一堆没有注释的“屎山”代码中追踪一个诡异的内存泄漏问题；你可能会在下午和产品经理反复拉扯，确定一个新功能在微服务架构下的 API 边界；你可能会在排查为什么 Kubernetes 集群里的 HPA（水平Pod自动扩缩容）没有按预期触发，或者研究 Istio 网关的流量路由策略。

如果你身处最前沿的 AI 领域，你可能正在评估是用 LangGraph 还是 AutoGen 来构建多 Agent 协同流，或者在调试大模型 API 的 Top-p 采样参数，试图让生成的回答既准确又具有随机性。甚至，在业余时间，你可能在设计一款解决自己痛点的小工具——比如一个用来清理、分类和管理繁杂书签的浏览器插件。

这些工作有一个共同点：它们都是极其复杂的、高度依赖上下文的、开放性的问题。

而在真实的工作环境中，我们解决这些问题依靠的是什么？

1.查阅文档与搜索能力：我们有 Google、有官方文档、有开源社区，甚至现在还有 AI 助手。

2.调试与试错能力：我们通过打日志、单步调试、看监控指标来定位问题。

3.架构视野与经验直觉：我们知道什么时候该用单例模式，什么时候该用工厂方法；我们知道在高并发下如何设计缓存策略，如何保证数据一致性。

4.沟通与协作：我们需要阅读别人的代码，也需要让别人看懂我们的设计。

反观 LeetCode 面试，它创造了一个极其不真实的无菌实验室环境：

●题目边界清晰，输入输出明确。

●只有单一的“最优解”（通常是时间复杂度和空间复杂度的极限）。

●不允许查阅文档，甚至不允许使用趁手的 IDE（有时只能在网页的纯文本框里写代码）。

●偏离日常使用的技术栈（你可能用 Python 写了十几年业务，却要用 C++ 的思维去考虑指针和内存管理）。

这就像是要求一个现代战争中的王牌飞行员，在面试时去比拼谁的射箭准头更好。它考察的不是“解决问题的能力”，而是“在极其受限条件下的默写能力”。

二、刷题面试，正在惩罚真正有经验的“老兵”

在软件开发领域，经验是一笔巨大的财富。一个拥有 10 年、15 年工作经验的研发架构师，他最大的价值并不在于写代码的速度有多快，而在于他踩过足够多的坑。

资深工程师知道，一个系统最大的危机往往不是算法复杂度从变成了（很多时候硬件资源和缓存机制完全能弥补），而是：

●数据库连接池配置不当导致的雪崩。

●缺乏熔断降级机制导致的服务级联故障。

●领域模型设计错误导致的后续需求无法扩展。

●业务逻辑耦合过深导致的测试困难。

然而，当这位资深架构师带着一身的实战本领走进面试房间时，等待他的却是一道“动态规划（DP）”的 Hard 题。

这是一种极大的资源浪费。一个能在生产环境中稳稳掌控全局、能设计出高可用 AI 基础设施、能带领团队攻坚克难的资深人才，仅仅因为最近几个月忙于项目交付、或者忙于应对生活中的变故（比如寻找新机会、照顾家庭），没有抽出几百个小时去死记硬背算法题库，就被无情地贴上“技术不过关”的标签淘汰出局。

这种现象导致了一个极其荒谬的倒挂：

那些刚刚毕业、没有写过一行生产环境代码、不懂得什么是持续集成、不知道如何进行线上排障的学生，只要花三个月把 LeetCode 刷个滚瓜烂熟，就能在面试中大杀四方；而那些真正在一线扛过枪、打过仗，能够解决复杂工程灾难的老兵，却在白板前因为忘记了一个状态转移方程而涨红了脸。

企业以为自己招到了“绝顶聪明”的天才，结果新人一入职，面对极其复杂的微服务依赖和一团乱麻的业务逻辑，立刻束手无策。因为真实的业务系统里，没有人会为你准备好整洁的 ListNode 或者 TreeNode。

三、算法题面试的本质：一场低效的“智商服从性测试”

为什么即便怨声载道，这么多公司依然痴迷于 LeetCode 面试？很多面试官会辩解说：“算法题能考察候选人的聪明程度和逻辑思维。”

这其实是一个伪命题。

1. 算法题早就不测智商了，它只测“准备度”。

在互联网早期，用算法题面试确实能筛选出一些思维敏捷的人，因为那时没有题库。但现在，LeetCode 已经有上千道题，“面经”满天飞。面试不仅变成了开卷考试的闭卷化，更变成了一门应试产业。能解出 Hard 题，往往不意味着你绝顶聪明，只意味着你刷到过原题，或者你花了大把时间去背诵套路。这充其量是一场“服从性测试”——看候选人愿不愿意为了这份工作去吃毫无意义的苦。

2. 忽视了工程中最关键的“可维护性”。

在 LeetCode 的评价体系里，“代码跑得快”是唯一的真理。哪怕你的代码里全是 i, j, k, dp, res 这种毫无语义的变量名，哪怕你的逻辑晦涩难懂如天书，只要能 AC（Accepted），你就是赢家。

但在实际工程中，这种代码是灾难。好的工程师写出的代码是给人看的，其次才是给机器执行的。如果你的代码在生产环境中出了 Bug，同事半夜被叫醒排查，看到满屏追求极致技巧却毫无注释的“炫技代码”，他大概率会在心里把你骂上一万遍。LeetCode 培养出的“做题家”思维，与团队协作所需的工程素养往往是背道而驰的。

3. 面试官的“安全牌”与偷懒。

其实，很多面试官也根本不知道该怎么面试。对他们来说，从题库里随机抽一道题扔给候选人，是最省事、最没有风险的做法。如果你没写出来，那是你不行，面试官不需要承担招错人的责任。这种做法掩盖了面试官自身架构视野和识人能力的匮乏。要深入了解一个人的项目经验、技术深度和系统设计能力，需要面试官投入极大的精力和极高的技术水平去进行深度的技术探讨，而“考一道题”则轻易地把压力全抛给了候选人。

四、如何打破僵局：回归工程本质的面试方法

批判之后，我们需要建设。如果不考 LeetCode，我们该怎么筛选优秀的软件工程师？真正的面试，应该是一场对日常工作的高度模拟。

1. 结对编程 (Pair Programming)

不要让候选人在白板上写代码，给他一台配置好 IDE 的电脑。面试官准备一个真实但简化过的业务小项目，或者直接在公司的一个开源代码分支上，两人结对协作。

●“我们现在有一个 Python 的服务端，用 FastAPI 写的，现在需要增加一个中间件来做简单的限流，你打算怎么做？”

●允许候选人查阅文档，允许使用 Google。

●观察他的编码习惯、他对框架的熟悉程度、他如何拆解问题，以及更重要的——他如何与你沟通和协作。

2. 代码审查 (Code Review)

给候选人一段存在各种“坑”的代码（可以是以前团队写出的真实烂代码，隐去敏感信息）。这段代码可能存在并发竞争、内存泄漏、或者设计模式的滥用。

让候选人进行 Code Review。优秀的工程师能立刻嗅出代码中的“坏味道”，并提出合理的重构建议。这比让他默写快速排序要有效得多。

3. 深度系统设计与项目复盘

抛弃那些假大空的“如何设计一个推特”的八股文。让候选人深度讲解他简历中最自豪的一个项目。

●“你在简历中提到主导了容器化改造，能画一下当时的 Kubernetes 架构图吗？”

●“在使用 Ingress 和服务网格（比如 APISIX 或 Istio）时，你们遇到了什么性能瓶颈？是如何排查的？”

●“你提到在做 AI 相关的研发，在整合底层大模型接口时，你们是如何处理长上下文带来的延迟问题和 token 消耗的？”

通过深度的追问，直到触及他的知识边界。真正的行家，在谈论自己亲手一砖一瓦建起来的系统时，眼里是有光的，细节是经得起推敲的。

4. 聊聊他创造的“小玩意儿”

一个真正的工程师，往往是对技术充满热情的创造者。与其问算法，不如问问他平时都在折腾什么。如果他告诉你，他因为受不了浏览器书签太乱，正在自己设计开发一个管理书签的插件；或者他为了解某种新技术栈，自己搭了一个爬虫和数据展示网站。请让他展示一下！这种对痛点的敏锐察觉和动手解决问题的能力，是任何算法题都无法衡量出的核心特质。

五、结语：放过工程师，也放过企业自己

技术招聘走到今天“无算法不面试”的地步，是整个行业的悲哀。它消耗了工程师们原本可以用来学习新框架、钻研底层原理、甚至陪伴家人的宝贵精力；它也让企业错失了大量踏实肯干、经验丰富的实战派人才。

编程，是一门结合了逻辑、工程、设计甚至艺术的创造性活动。它不该被简化为一场机械的背诵比赛。

作为面试官，下次当你准备掏出一道 LeetCode Hard 题时，不妨停下来问问自己：“这道题，真的能帮我找到那个能和我并肩作战、一起扛住双十一流量洪峰、一起在深夜排查诡异 Bug 的可靠队友吗？”

如果不能，请放下那道该死的算法题，和候选人像真正的工程师一样，聊聊真实的架构，看看真实的代码。

把时间还给工程，把尊严还给工程师。

AI 模型推理平台架构设计与实践

Sun, 30 Nov 2025 04:11:10 +0000

一、背景

为什么要搞推理平台

从实用的角度讲，搞推理平台的目的就是为了给部署、运行、维护模型打造一个良好的 “环境”。

为什么要自己部署、运行、维护模型呢？全部用 API 不行吗？

这个问题涉及到模型的功能分化。简单来讲，传统的 LLM 基座模型是很强，类似全能型选手，但在企业落地场景下并不完全适用。企业需要的是 ROI 极高的方案，企业场景下会考虑并发、延迟、成本等非常具体的指标。所以用满足单一场景且成本极低的小模型 + 基座大模型是比较务实的选择。

一定要有 GPU （显卡资源）吗？

不一定，有些模型在 CPU 也跑的很好。比如 all-MiniLM-L6-v2，但绝大多数模型是需要 GPU 的。

二、资源规划与集群架构

我们假设你的生产环境是如下图所示的 K8S 集群环境

不止 k8s

对于一个 “模型在线推理平台（Serving 平台）”，光靠 k8s 是不够的。

如果光有 k8s 我们会遇到以下几个问题：

资源利用率极低，成本高昂：Kubernetes 的原生调度单位是 Pod。它不理解 “模型” 这个概念，也不知道如何在一张 GPU 上高效地运行多个模型。那就意味着一个模型会独占一张 GPU 卡。中小模型的计算量不大，大部分时间里，这个 Pod 和 GPU 都是空闲的。当模型数量增加时（例如 10 个或 50 个模型），成本会呈线性增长，变得非常昂贵。
运维复杂度极高：原生 Kubernetes 缺少一个更高层次的抽象来描述 “模型服务” 这个场景，必须手动组合多个底层资源来完成一个任务（手动编写和维护一套复杂的 Kubernetes YAML 文件（Deployment, Service, HorizontalPodAutoscaler 等）。
缺乏标准化的模型服务能力：这些都是应用层的逻辑，原生的 Kubernetes 并不直接提供这些开箱即用的功能

如何进行 A / B 测试或金丝雀发布（Canary Rollouts）来平滑升级模型？
如何处理模型的预处理和后处理逻辑？
如何监控模型的 QPS、延迟、成功率等指标？ 可观测性不足（难以按 “模型维度” 看指标）
流量高峰时如何自动扩容，没有流量时如何缩容以节省成本？

KServe

“

Standardized Distributed Generative and Predictive AI Inference Platform for Scalable, Multi-Framework Deployment on Kubernetes

为了解决上述问题，社区催生了专门针对 Kubernetes 的模型服务平台，KServe 就是其中的佼佼者。它通过引入一个名为 InferenceService 的自定义资源（CRD）来解决这些问题。

解决资源利用率问题：
模型复用 (Multi-Model Serving)：KServe 可以与 NVIDIA Triton Inference Server 或 TorchServe 等高性能推理服务器集成。这些服务器支持在 单个 Pod 和单个 GPU 上加载和运行多个模型。当请求进来时，由推理服务器动态地将计算任务分配给 GPU。这样，多个中小模型就可以共享一张 GPU，极大提高资源利用率。
自动缩容至零 (Scale to Zero)：当一个模型在一段时间内没有收到任何请求时，KServe 可以自动将该模型的 Pod 缩减到 0。当新的请求到来时，它又能快速拉起一个新的 Pod 来提供服务。这对于流量不稳定的中小模型来说，是巨大的成本节省。
解决运维复杂度问题：
单一抽象 (InferenceService)：不再需要编写 Deployment, Service 等一大堆 YAML。只需要定义一个 InferenceService 对象，在里面声明用的是什么框架（TensorFlow, PyTorch, Triton 等）以及模型的存储路径（如 S3）。KServe 会自动创建和管理所有底层的 Kubernetes 资源。这极大地简化了运维工作。
解决标准化服务能力问题：
开箱即用的高级部署：在 InferenceService 的配置中，只需修改几行代码，就可以轻松实现金丝雀发布。例如，您可以指定将 10% 的流量发送到新模型，90% 的流量发送到旧模型，验证通过后再全量切换。
请求日志、监控指标：KServe 自动提供了标准化的接口和可观测性指标，方便接入 Prometheus、Grafana 等监控系统。
推理图谱 (Inference Graph)：对于需要多个模型串联（例如预处理 -> 模型 A -> 后处理 -> 模型 B）的复杂场景，KServe 也提供了标准化的解决方案。

对于 “在 Kubernetes 上部署多个中小模型” 这个场景， KServe 是目前最好、最主流的开源解决方案之一。

直接采用 KServe 将会极大降低成本、简化管理、并提升部署的稳定性和灵活性，让我们可以更专注于模型算法本身，而不是底层的基础设施。

KServe 架构

KServe 架构概览：

核心架构：

控制面架构：

数据面架构：

模型 runtime 支持：

vLLM 和 Triton

从 KServe 的运行体系图中可以看到在推理层面，大致有两种最流行的软件，一个是 vLLM，一个是 Triton

vLLM 是 LLM 专用推理引擎（只跑 Transformer，极快但单一）
Triton 通用推理平台（CV/NLP/LLM/推荐都能跑，全能但略重）

在 KServe 里，两者的选择就是： “要极速跑 LLM，还是要一车拉所有模型” 。在实践中，KServe 是一个统一平台，可以支持我们按需选引擎，所以不用 all in 其中任何一种，比较灵活、方便。

三、部署思路

架构

结构如下：

这里我们需要解释几个问题

1. 整体链路是谁在做自动扩缩容？

在 KServe + Knative 模式下，职责大致是：

KServe：
写 InferenceService CRD（YAML）
KServe Controller 把它翻译成一个 Knative Service（和一些 K8s 资源）
同时通过 annotations / 字段把我们希望的 autoscaling 配置写进去
Knative Serving：
一个 Revision
一个对应的 Deployment（里面的 Pod 跑模型容器）
一个自动伸缩器：
要么是 KPA（Knative Pod Autoscaler）
要么是一个真正的 Kubernetes HPA（如果配置了 autoscaling.knative.dev/class: hpa.autoscaling.knative.dev）
接管 Knative Service，创建：
Istio：
负责入口网关、路由、mTLS 等
把请求导入到 Knative 的 activator / queue-proxy 上
为 Knative 提供 HTTP 请求 metrics（QPS、并发等）
不直接做扩缩容决策，只是提供流量和指标
真正做扩缩容决策的是：
Knative 的 KPA 或 HPA，再通过 Deployment 控制最终 Pod 数量
KServe 只是 “声明模型 + 帮我们写好 Knative 配置”，并不直接操作 replicas

2. enable-scale-to-zero: “true” 的含义是什么？

1# 文件： knative-config.yaml
2enable-scale-to-zero: "true"

在 Knative 的 config（比如 config-autoscaler）里，表示允许某个 Knative Service 被 KPA 缩到 0 个 Pod。再配合 InferenceService / Knative Service 上的配置：

若没有设置 minScale / minReplicas，默认允许从 0 → N
若在 InferenceService 里（或 annotations）配了 minReplicas: 1 或 autoscaling.knative.dev/minScale: “1”，则不会缩到 0，而是至少保留 1 个 Pod（即 1 块 GPU 一直常驻）

缩到 0 的流程大致是：

一段时间内没有请求（由 Knative 的 autoscaler 统计）
KPA 认为可以缩减，就把 Deployment 的 replicas 降到 0
Pod 把 GPU 释放掉；节点上的 GPU 就空闲了

从 0 唤醒：

有新请求到达 Istio 网关 → 被路由到 Knative 的 Activator
Activator 缓冲请求，并通知 autoscaler
autoscaler 把 Deployment 从 0 扩到 1（或更多）个 Pod
Pod 启动，模型加载进 GPU，处理缓存的请求（这就是冷启动）

3. 单模型多 Pod ，如何占多机多卡？

把上面的流程套到 GPU 上看就是：

1. 每个推理 Pod 的容器请求：

1resources:
2 limits:
3 nvidia.com/gpu: 1
4

2. K8s 调度时确保：

每个 Pod 分配到一个有空闲 GPU 的节点
默认 nvidia.com / gpu 是「不可共享资源」，所以 1 Pod 独占 1 块卡

3. 当 autoscaler 决定从 1 Pod 扩到 N Pod 时：

K8s 再调度 N-1 个新的 Pod 到其他 GPU 节点
最终你就是：同一个模型，多 Pod，分布在多台单卡机器上
Istio / Knative 负责把请求均衡到这些 Pod 上

4. 当流量变小：

autoscaler 把 replicas 从 N 缩回 1，甚至缩到 0
对应地释放掉一部分 / 全部节点上的 GPU

总的来说：

目前有两种模式：

单模型 + 单 Pod = 占用一台单卡机
单模型 + 多 Pod = 水平扩展到多台单卡机，多卡并行处理请求

多 Pod 的自动扩缩容流程：
决策逻辑在 Knative（KPA 或 HPA）这层
KServe 只是根据 InferenceService 的 spec & annotations 帮我们创建出合适的 Knative Service / autoscaler 配置
Istio 不做扩缩容决策，只负责网关和路由，同时为 Knative 提供 metrics / 流量通路
enable-scale-to-zero: “true” 是 Knative 的全局开关，允许在 InferenceService 里配置成真正可缩到 0 的无流量模型服务。

面临的问题

整个架构从水平扩容的角度讲是没有太大的问题，但当我们把视角切换到机器内部，看 pod 内部的情况，是有问题的，比如：

一个显卡 48G 显存，一个小模型可能只需要 10G 显示，但它独占了一张显示，这会造成资源的浪费
当我只有一两个模型需要部署时候问题不大。浪费也不大，但如果我有多个小模型（单卡能放下）都需要同时部署，如果不仔细计算显卡的使用率，那么有可能造成大量的资源浪费。

解决办法

对一个 LLM 来说，显存大致分三块：

模型权重（weights）
运行时开销（activations / 临时 buffer 等）
KV Cache（连续 batching 的关键，vLLM 会尽可能把剩余显存拿来做这个）VLLM Docs

vLLM 通过 –gpu-memory-utilization 控制 “自己能用的显存占比”（默认 0.9），在这个额度内，剩下的空间基本都会拿去做 KV Cache，以提升吞吐和并发。

所以：

如果我们看到 “模型只占 10G”，很可能只是在低并发、短上下文下的一瞬间观感；
一旦并发、上下文长度、请求峰值上去，KV Cache 会吃掉大量显存，这时候那 “剩余的 30+ G” 就会逐步被用起来。

如果在业务高峰期，这几个指标都比较高（比如显存长期 >70%，KV cache 使用率也不低），那 “单模型独占一张卡” 并不浪费，而是在换 性能 & 稳定性。

其实我们问题的本质是：“我有好几种小模型都要在线，单卡其实装得下，但一机一模型的部署方式会造成卡粒度上的浪费。”

要解决这个问题，大致有几条思路：按 “现实可行度” 从高到低排序：

业务层合并：能不用多模型就别用多模型

能用一个 “能力足够强” 的主模型 + Prompt / LoRA 搞定，就不要真部署 N 个完全独立的小模型。
多数 “业务小模型” 的差异，其实是 “提示词 + 风格 + LoRA” 的区别，不一定非要上不同 base model。

把单模型的吞吐吃满

利用 vLLM 的连续 batching，提高并发、适当增加最大上下文、控制 QPS，让 GPU 真正跑到比较高的利用率。
我们已经有完整的 Prometheus / Grafana 看板方案，可以直接看 QPS、Token 吞吐、GPU Util、KV Cache 占用来调优。

实在必须多模型同卡，再考虑 “共享 GPU” 技术（下面会拆开说）

共享 GPU 技术

Time-Slicing

NVIDIA GPU Operator / k8s-device-plugin 提供的 Time-Slicing，本质是：

把一张物理 GPU 虚拟成多个 “replica” 资源，Pod 申请 nvidia.com / gpu: 1 时，拿到的是其中一个 replica；
底层靠时间片轮转在同一张卡上跑多个 Pod。

关键点（也是坑点）是：Time-Slicing 只切算力，不切显存，显存是共享的，没有隔离。NVIDIA Docs 这意味着：

如果多个 Pod 加起来申请 / 实际占用的显存 > 实际物理显存，就有概率 OOM；
即使不 OOM，Page Fault / 内存碎片也会让延迟非常不稳定。

而 vLLM 非常依赖稳定且持续的显存做 KV Cache，Time-Slicing 没有显存隔离，很容易被别的 Pod 挤爆显存导致 OOM，所以不适合 vLLM

MIG（Multi-Instance GPU）

MIG 的特点：

真正把 一张 GPU 切成多个硬件隔离的 “小卡”，每块有独立的显存、高带宽内存、缓存和计算核心
适合需要 延迟可预测、多租户隔离 的 LLM 推理场景

但 MIG 只在 A100 / H100 / A30 等特定卡上存在，普通云上 L4、L40、T4、V100 这类要么不支持，要么支持非常有限。对于我们来说，也不适用。

ModelMesh

KServe 其实就内置了两种 “模型平台形态”：1. Single-Model Serving（单模型平台）

每个服务只跑一个模型；
LLM / 大模型几乎都是走这一条（包括 vLLM Runtime）。2. Multi-Model Serving（基于 ModelMesh 的多模型平台）
同一个模型服务器里可以放多模型，按需加载/卸载，适合一堆小模型共享有限卡的场景（比如 SKLearn/ONNX/OpenVINO 那些）。

ModelMesh 适合「很多模型 + 访问稀疏」的场景，ModelMesh 的设计目标是：

管理大量模型（几十、几百甚至更多）
很多模型 QPS 很低，没必要长时间常驻显存 / 内存
通过「按需加载 + LRU 驱逐」来平衡：
内存 / 显存占用
冷启动延迟

另外，社区对 ModelMesh 的定位也比较明确：更偏向 “可伸缩多模型平台”，现在要把 LLM Runtime（特别是 vLLM）硬往 ModelMesh 里塞，是有一定探索和集成成本的，而且生态也还在演进中 https://github.com/kserve/kserve/issues/4299

如果我们前期的目标只是「十个以内」的小模型，希望高利用率、简单稳定，所以可以先不用 ModelMesh，真正到模型数爆炸、并且很多模型很冷时，再考虑 ModelMesh 会更合适。尤其是当前的重点是 “先把核心 LLM 跑稳定 & 可观测 & 易扩容”。

Triton + vLLM + 多模型同 Pod / 同 GPU

以上方案都不太合适，于是我把目光投向了 Triton

NVIDIA Triton 的能力是比较强的：

支持在同一台机器上多个模型 / 多个模型实例并行执行，由 Triton 负责调度；NVIDIA Docs
支持多种后端（TensorRT-LLM、PyTorch、ONNXRuntime、Python backend 等）；
现在还有 官方的 vLLM backend，可以在 Triton 里用 vLLM 做 LLM 推理。

从 GPU 视角看，Triton 做的事类似于：“一个进程负责管理很多模型，来了请求就把对应的 op 丢给 GPU，GPU 再在硬件层面做调度并发。” 但是：Triton 也不会神奇地帮我们 “切显存”—— 多个模型的权重 + KV Cache 依然是往同一个物理显存里塞。Triton 提供的是 “共享一块显存的多模型协调器”，不是 “把显存分成几块小卡” 的硬隔离器。

因此：

Triton 不能像 MIG 一样说：
“模型 A 只能用 16G，模型 B 只能用 8G，互相绝不会越界”
它顶多是：
通过配置 + 调度让你 “尽量别把自己搞到 OOM”；
但如果你把几个模型配置得都很激进，合起来 > 物理显存，照样可能 OOM，仅仅是更 “有迹可循”。

结合我们的实际情况，综合考虑，Triton 可以有以下几种组合姿势：

Triton 只负责传统模型（embedding、CV、语音等），LLM 仍由独立 vLLM 服务跑

这时候 “一卡多模型” 主要是非 LLM 模型之间的事，LLM 是单卡独占或少量共享；
对现在的 “私有化大模型平台” 来说，这是最现实、也最可控的一种搭配。

Triton + vLLM backend，把 LLM 也塞进 Triton 的统一服务里

本质上还是 “一张卡一个 vLLM 引擎”，只是对外通过 Triton 统一暴露接口而已；
多模型同卡时，显存依然一起抢；如果你试图放多个 LLM（哪怕是 7B SLM），很快就会撞上显存天花板，需要极其克制的 –gpu-memory-utilization 和并发控制。

Triton 内部多 LLM + 非 LLM 模型混合

这种组合在理论上可行，工程上可做，但对资源规划、监控、故障排查的要求会非常高；
对现在来说，属于 “下一阶段再考虑” 的东西

综上，目前我们利用 Triton 采用第一种方式：负责传统模型（embedding、CV、语音等），LLM 仍由独立 vLLM 服务跑

对所有私有化部署的模型部署整体策略如下：

“

上图是从 KServe 视角看的，如果从 k8s 视角，不同的 pod 还会有多副本扩容的情况。但每个 pod 都是独占 GPU。

Triton 多模型（非 LLM）分组方案

整体思路：1 GPU 1 Triton，多模型共用

在现有架构下，最自然的做法是：

每块 GPU 起一个 Triton Pod（由一个 InferenceService 管）
这个 Triton Pod 里面的 model repository 里放多个非 LLM 模型：embedding / rerank / CV / ASR…
KServe 只是负责：
帮我们起 kserve-tritonserver 这个 runtime
把远端（S3/MinIO/PVC）上的 Triton model repository 挂到 /models（或 /mnt/models）
暴露统一的 HTTP / gRPC 入口（/v2/models//infer）

Triton 本身就是为「一台机上多个模型、多个实例并发」设计的：多个模型、多个实例可以在同一块卡上并发执行，通过 instance_group、dynamic_batching 来调度和吃满卡资源。NVIDIA Docs

建议按业务域 + 性能特性分组：

一组：文本向量 + rerank（text-embedder / text-reranker）
一组：CV / OCR / ASR（图像 & 语音）这样：
同一组内模型的 batch 维度、输入大小比较接近，Triton 的 dynamic batching 比较好调；
资源隔离更清晰：文本这组爆了不会影响语音那组。

下面是一套完整配置样例（可以先从「所有非 LLM 都放一个组」开始，后面再拆分）

分组示例

Triton 模型仓库（model repository）结构示例，Triton 要求的模型仓库布局类似这样：

 1 s3://your-bucket/triton-nonllm-repo/
 2├── text-embedding-e5-small/
 3│ ├── config.pbtxt
 4│ └── 1/
 5│ └── model.onnx
 6├── text-rerank-msmarco/
 7│ ├── config.pbtxt
 8│ └── 1/
 9│ └── model.onnx
10├── vision-cls-resnet50/
11│ ├── config.pbtxt
12│ └── 1/
13│ └── model.onnx
14├── asr-conformer/
15│ ├── config.pbtxt
16│ └── 1/
17│ └── model.onnx
18└── search-pipeline/
19 ├── config.pbtxt # 可选：Triton ensemble，把 embedder + reranker 串起来
20 └── 1/
21 └── model.graphdef / model.py / ...

只要 storageUri 指向这个目录，Triton 就会把子目录当成多个模型一起加载。

单个模型的 config.pbtxt 示例（带分组 / 实例配置），以一个 ONNX embedding 模型为例：路径：text-embedding-e5-small/config.pbtxt

 1name: "text-embedding-e5-small"
 2platform: "onnxruntime_onnx"
 3max_batch_size: 128 # 这里根据你的 embedding 模型实际情况调
 4
 5input [
 6 {
 7 name: "input_ids"
 8 data_type: TYPE_INT64
 9 dims: [ -1 ] # 序列长度，-1 表示动态
10 },
11 {
12 name: "attention_mask"
13 data_type: TYPE_INT64
14 dims: [ -1 ]
15 }
16]
17
18output [
19 {
20 name: "embedding"
21 data_type: TYPE_FP32
22 dims: [ 768 ] # 或者你的模型真实向量维度
23 }
24]
25
26# 关键：在同一块 GPU 上开多实例，提高吞吐
27instance_group [
28 {
29 kind: KIND_GPU
30 count: 2 # 这块卡上起两个实例，看显存情况调 1/2/3
31 }
32]
33
34# 关键：Dynamic Batching，让 Triton 自动拼 batch
35dynamic_batching {
36 preferred_batch_size: [ 8, 16, 32, 64 ]
37 max_queue_delay_microseconds: 2000 # 2ms 内尽量攒一波请求
38}
39

同理，你可以为其他模型写各自的 config.pbtxt。分组思路：

对 高 QPS 的模型（比如 text embedding）可以把 max_batch_size 和 preferred_batch_size 设得大些，多起几个 instance_group；
对 低 QPS 但重模型（ASR、复杂 CV）就用 max_batch_size 小一点，甚至单实例。

如果有完整的 pipeline（比如「embedding → rerank」），可以用 Triton 的 ensemble 在 search-pipeline/config.pbtxt 里把两个模型串起来，一次请求走一条 DAG，减少网络往返。

KServe InferenceService YAML 示例（kserve-tritonserver）

KServe 自带 kserve-tritonserver 这个 ClusterServingRuntime，支持 TensorFlow / ONNX / PyTorch / TensorRT 模型。可以这样起一个「非 LLM 小模型专用」的 Triton 服务：

 1apiVersion: serving.kserve.io/v1beta1
 2kind: InferenceService
 3metadata:
 4 name: triton-nonllm-text
 5 namespace: ai-serving
 6 annotations:
 7 # Knative 自动扩缩容（按并发）
 8 autoscaling.knative.dev/metric: "concurrency"
 9 autoscaling.knative.dev/target: "10" # 每 Pod 目标并发
10 autoscaling.knative.dev/minScale: "1"
11 autoscaling.knative.dev/maxScale: "5"
12spec:
13 predictor:
14 # ✅ 新 schema：通过 model.runtime 显式指定使用 kserve-tritonserver
15 model:
16 modelFormat:
17 # 这里写实际模型格式（比如 onnx / pytorch），只要包含在 kserve-tritonserver 支持列表中即可
18 # Triton 仓库里可以混放多种 backend，KServe 不会限制这一层
19 name: onnx
20 runtime: kserve-tritonserver
21 # 指向刚才那个包含多个模型的 Triton 模型仓库
22 storageUri: s3://your-bucket/triton-nonllm-repo
23 runtimeVersion: "24.03-py3" # 按你集群里安装的 kserve-tritonserver 版本改
24 # 如需 gRPC（性能更好），参考官方示例暴露 9000 端口:contentReference[oaicite:6]{index=6}
25 ports:
26 - name: h2c
27 protocol: TCP
28 containerPort: 9000
29 resources:
30 requests:
31 cpu: "4"
32 memory: "16Gi"
33 nvidia.com/gpu: 1
34 limits:
35 cpu: "8"
36 memory: "32Gi"
37 nvidia.com/gpu: 1
38 nodeSelector:
39 gpu-pool: "true" # 按你集群里标的 label 改，确保调度到有 GPU 的节点
40

几点说明：

多模型是 Triton 内部概念

KServe 看到的只是「一个 InferenceService + 一个 Triton Pod」。
Triton 会根据 storageUri 下的目录加载多个模型。

请求路径

走 KServe / Istio / Knative 的网关时：
HTTP：POST http:///v2/models//infer
gRPC：grpc://:/InferenceServer/ModelInfer（按 Triton V2 协议）
就是每个子目录名：text-embedding-e5-small / vision-cls-resnet50 / asr-conformer…

简单 Checklist：

准备 Triton 模型仓库

在 MinIO / S3 / PVC 上建好 triton-*-repo 目录；
把 embedding、rerank、CV、ASR 模型按 Triton 要求拆目录 + 写 config.pbtxt。

确认集群里有 kserve-tritonserver 的 ClusterServingRuntime

kubectl get clusterservingruntime | grep triton

应用上面那个 InferenceService YAML

改好 storageUri、runtimeVersion、nodeSelector；

通过 /v2/models//infer 分别打 smoke test

文本 embedding / rerank / CV / ASR 各来几条请求；
对比 Triton metrics（/metrics）和 DCGM，看 GPU 利用率 & 显存占用。

请求流 & 监控流（两条主链路）

推理请求链路（从客户端到 vLLM）

KServe 把 InferenceService 抽象出来，底层仍然是 Knative Service + Istio VirtualService 这些资源；Istio ServiceMesh 文档里也有 “给 InferenceService 打 sidecar 做安全 / 流量治理” 的说明。
vLLM 服务端会在 /metrics 上暴露自身的 Prometheus 指标，例如 vllm:prompt_tokens_total、vllm:generation_tokens_total、vllm:e2e_request_latency_seconds 等，用来统计 QPS、Token 数量和端到端延迟。

监控链路（业务 + GPU）

NVIDIA 官方文档明确建议：在 Kubernetes 中监控 GPU 时，使用 DCGM Exporter → Prometheus → Grafana 这一条链路。
我们现在的设计就是把这一套和 vLLM 的业务 metrics 汇总到同一个 kube-prometheus-stack 里 —— 这也是很多实践里推荐的做法，用 Prometheus Operator 的 ServiceMonitor 去发现所有 exporter 与应用。

在 K8s 里做 GPU 监控，典型链路是：

“

GPU 节点 → GPU Operator → DCGM Exporter → Prometheus → Grafana

GPU Operator：在 GPU 节点上自动装好驱动、Container Toolkit、Device Plugin、DCGM / Exporter 等一整套 GPU 栈。
DCGM Exporter：基于 NVIDIA DCGM，把 GPU 的利用率、显存、温度、功耗等指标以 Prometheus /metrics 的形式暴露出来。
NVIDIA 官方推荐：在 K8s 集群里采集 GPU Telemetry，就用 DCGM Exporter + Prometheus + Grafana 这一套。
GPU Operator 默认就会启用 DCGM Exporter 来采集 GPU metrics（可以通过 Helm values 里的 dcgmExporter.enabled 开关）。

所以，我们只需要：

在 Kubekey 装好的 K8s 集群中安装 GPU Operator（包含 DCGM Exporter）。
在公司统一 Prometheus 上加一个 scrape job（或者在集群里用 ServiceMonitor），把这些 /metrics 抓过去即可

“

GPU Operator 是一个管理者，DCGM Exporter 是它管理的一个组件。你只和管理者（Operator）打交道，它会帮你搞定一切。

四、环境搭建步骤

需要安装的软件、版本及顺序

安装步骤 SOP

第 0 步：准备工作

1# 添加所有需要的 Helm 仓库
2helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
3helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
4helm repo add jetstack https://charts.jetstack.io
5helm repo add istio https://istio-release.storage.googleapis.com/charts
6helm repo update

第 1 步：安装 NVIDIA GPU Operator (v24.9.1)

目的：启用 GPU 驱动，并配置 CDI (Container Device Interface) 以兼容 K8s 1.30。

以下命令是在 GPU 驱动都安装好的前提下执行

1helm install gpu-operator nvidia/gpu-operator \
2 -n gpu-operator --create-namespace \
3 --version v24.9.1 \
4 --set driver.enabled=false \
5 --set toolkit.enabled=true \
6 --set cdi.enabled=true \
7 --set cdi.default=true
8

验证：等待 kubectl get pods -n gpu-operator 全绿。

如果出错，那么：

这个命令显式指定了版本，并且强制告诉 Operator 你的 Containerd 配置文件在哪里，避免出现之前的 FailedCreatePodSandBox 错误。

 1helm install gpu-operator nvidia/gpu-operator \
 2 -n gpu-operator --create-namespace \
 3 --version v24.9.1 \
 4 --set driver.enabled=false \
 5 --set toolkit.enabled=true \
 6 --set toolkit.env[0].name=CONTAINERD_CONFIG \
 7 --set toolkit.env[0].value=/etc/containerd/config.toml \
 8 --set toolkit.env[1].name=CONTAINERD_SOCKET \
 9 --set toolkit.env[1].value=/run/containerd/containerd.sock \
10 --set toolkit.env[2].name=CONTAINERD_RUNTIME_CLASS \
11 --set toolkit.env[2].value=nvidia \
12 --set cdi.enabled=true \
13 --set cdi.default=true

第 2 步：安装 Kube-Prometheus-Stack (v61.9.0)

目的：基础监控。必须修正配置，否则 KServe 的 ServiceMonitor 会被忽略。

准备 values-kube-prometheus-stack.yaml

 1# values-kube-prometheus-stack.yaml
 2
 3prometheus:
 4 prometheusSpec:
 5 # 允许抓取所有 namespace 下的 ServiceMonitor / PodMonitor
 6 serviceMonitorNamespaceSelector: {}
 7 podMonitorNamespaceSelector: {}
 8
 9 # 不再强制使用 Helm 的 release label 做筛选
10 # （默认是 true，会要求 ServiceMonitor 带 release=<helm release> 这样的 label）
11 serviceMonitorSelectorNilUsesHelmValues: false
12 podMonitorSelectorNilUsesHelmValues: false
13
14 # 空 selector = 不按 label 过滤，看到就抓
15 serviceMonitorSelector: {}
16 podMonitorSelector: {}
17
18 # 可选：Prometheus 数据保留时间
19 retention: 15d
20
21 # 暴露 Prometheus 的方式（开发环境方便直接 NodePort）
22 service:
23 type: NodePort
24 nodePort: 30090 # 访问地址：任一节点IP:30090 
25
26grafana:
27 # Grafana 用 NodePort 方便先调试；生产看你们自己安全策略
28 service:
29 type: NodePort
30 nodePort: 30080 # 可不填，让 kube 随机分配
31
32 # 管理员密码（不写一般是 prom-operator，也可以明确写死）
33 adminPassword: prom-operator

这套配置的核心就是：Prometheus 不再只认「带 release=kube-prometheus-stack 的 ServiceMonitor」，而是「所有 namespace 下的 ServiceMonitor 都抓」，这样 GPU Operator 自动创建的 ServiceMonitor 也不会漏掉。

安装 kube-prometheus-stack

1helm install monitoring prometheus-community/kube-prometheus-stack \
2 -n monitoring --create-namespace \
3 --version 61.9.0 \
4 -f values-kube-prometheus-stack.yaml

打开 GPU Operator 的监控组件（ServiceMonitor）

1#解释：
2#--reuse-values: 保留之前设置的 cdi.enabled=true 等参数。
3#--set dcgmExporter.serviceMonitor.enabled=true: 这才是核心，告诉 Operator 创建监控对象。
4
5helm upgrade gpu-operator nvidia/gpu-operator \
6 -n gpu-operator \
7 --reuse-values \
8 --set dcgmExporter.serviceMonitor.enabled=true

第 3 步：安装 Cert-Manager (v1.15.3)

目的：为 KServe 和 Knative 的 Webhook 签发自签名证书。

1helm install cert-manager jetstack/cert-manager \
2 -n cert-manager --create-namespace \
3 --version v1.15.3 \
4 --set crds.enabled=true

验证：等待 kubectl get pods -n cert-manager 全绿。

第 4 步：安装 Istio (v1.22.6)

目的：流量网关。严格按照 Base -> Istiod -> Gateway 的顺序安装。

1# 1. 安装 Base CRD
2helm install istio-base istio/base -n istio-system --create-namespace --version 1.22.6
3
4# 2. 安装 Istiod 控制平面
5helm install istiod istio/istiod -n istio-system --version 1.22.6 --wait
6
7# 3. 安装 Ingress Gateway (数据平面)
8helm install istio-ingressgateway istio/gateway -n istio-system --version 1.22.6

第 5 步：安装 Knative Serving & Net-Istio (v1.15.1)

目的：实现 Serverless 扩缩容能力。

1# 1. 安装 CRDs
2kubectl apply -f https://github.com/knative/serving/releases/download/knative-v1.15.2/serving-crds.yaml
3
4# 2. 安装 Serving Core
5kubectl apply -f https://github.com/knative/serving/releases/download/knative-v1.15.2/serving-core.yaml
6
7# 3. 安装 Net-Istio (网络适配器)
8kubectl apply -f https://github.com/knative-extensions/net-istio/releases/download/knative-v1.15.1/net-istio.yaml

验证：kubectl get pods -n knative-serving，确保 net-istio-controller 和 activator 状态为 Running。

第 6 步：安装 KServe (v0.14.1)

目的：核心推理平台。注意这里使用的是 v0.14.1。

1# 安装 KServe CRDs
2helm install kserve-crd oci://ghcr.io/kserve/charts/kserve-crd \
3 --version v0.14.1 \
4 -n kserve --create-namespace
5 
6# 安装 KServe Controller
7helm install kserve oci://ghcr.io/kserve/charts/kserve \
8 --version v0.14.1 \
9 -n kserve

执行完上述两条命令后，检查 KServe 的系统组件： kubectl get pods -n kserve

第 7 步：配置 vLLM Runtime (关键)

KServe 默认只有简单的 CPU 模型支持。为了运行公司级 LLM 服务，必须添加支持 GPU 的 Runtime。

保存以下内容为 vllm-runtime.yaml 并执行 kubectl apply -f vllm-runtime.yaml：

 1apiVersion: serving.kserve.io/v1alpha1
 2kind: ClusterServingRuntime
 3metadata:
 4 name: kserve-vllm
 5spec:
 6 annotations:
 7 prometheus.kserve.io/port: '8080'
 8 prometheus.kserve.io/path: "/metrics"
 9 supportedModelFormats:
10 - name: vllm
11 version: "1"
12 autoSelect: true
13 containers:
14 - name: kserve-container
15 image: vllm/vllm-openai:latest
16 # 建议生产环境锁定具体 image sha256
17 command: ["python3", "-m", "vllm.entrypoints.openai.api_server"]
18 args:
19 - --port=8080
20 - --model=/mnt/models
21 - --gpu-memory-utilization=0.9
22 env:
23 - name: PORT
24 value: "8080"
25 resources:
26 requests:
27 cpu: "4"
28 memory: "16Gi"
29 nvidia.com/gpu: "1"
30 limits:
31 cpu: "8"
32 memory: "32Gi"
33 nvidia.com/gpu: "1"

第 8 步：为 GPU 调度开启 Knative 的 nodeSelector / tolerations

Knative 默认禁止你在 Knative Service 的 Pod 里写 nodeSelector / tolerations，KServe 官方教程在使用 GPU 时也会做这一步 patch。

打开特性开关

1kubectl patch configmap/config-features \
2 --namespace knative-serving \
3 --type merge \
4 --patch '{"data":{"kubernetes.podspec-nodeselector":"enabled", "kubernetes.podspec-tolerations":"enabled"}}'

重启 Webhook：

1kubectl delete pod -n knative-serving -l app=webhook

第 9 步：Istio Sidecar 注入策略（避免影响 GPU Operator 和监控）

默认 Istio 只对打了 istio-injection=enabled 标签的 namespace 注入 sidecar。确保「不需要注入」的 namespace 没有 label

保护基础设施 (防止 Sidecar 导致 Job 不退出)

1# 1. 明确禁止 GPU Operator 注入 (防止 Validator/Driver 安装卡死)
2kubectl label namespace gpu-operator istio-injection=disabled --overwrite
3
4# 2. 明确禁止 监控 注入 (减少开销)
5kubectl label namespace monitoring istio-injection=disabled --overwrite
6
7# 3. 明确禁止 kube-system 注入 (安全底线)
8kubectl label namespace kube-system istio-injection=disabled --overwrite

保护控制平面 (防止 Webhook 超时)

1
2kubectl label namespace knative-serving istio-injection=disabled --overwrite 
3kubectl label namespace kserve istio-injection=disabled --overwrite

启用业务空间 (让模型享受 Service Mesh 能力)，业务命名空间 “必须” 注入 ✅

1# 1. 创建你的业务空间 (如果你还没创建)
2kubectl create namespace model-serving
3# 2. 启用注入 (关键一步)
4kubectl label namespace model-serving istio-injection=enabled --overwrite

这样做的好处：

GPU Operator、DCGM Exporter、Prometheus 不会被 sidecar 干扰
模型推理流量全部走 Istio + Knative 控制的入口

第 10 步：安装 MinIO（可选）

添加所有依赖 Helm 仓库

1# 添加MinIO、Loki官方仓库
2helm repo add minio https://helm.min.io/
3helm repo add grafana https://grafana.github.io/helm-charts
4# 更新所有仓库（确保获取最新Chart版本）
5helm repo update

MinIO 部署 —— 部署 2 节点分布式 MinIO（Loki 后端存储） MinIO 配置为 2 副本分布式，适配当前 2 节点，同时预留未来扩容参数，升级时仅需修改副本数即可。

编写 MinIO 配置文件 minio-distributed-values.yaml

关键标注：文件内 replicas 和 numberOfNodes 为扩容核心参数，未来扩容需同步修改为 3+ 等节点数。

 1# 核心：启用分布式模式（2节点适配，未来扩容改replicas/numberOfNodes）
 2mode: distributed
 3replicas: 2 
 4numberOfNodes: 2 
 5
 6# 镜像配置（你原单节点的成功版本）
 7image:
 8 repository: quay.io/minio/minio
 9 tag: RELEASE.2023-07-07T07-13-57Z
10 pullPolicy: IfNotPresent
11
12# 访问密钥（完全沿用你的配置，Loki对接需一致）
13rootUser: U4DwltABIX8p20aONyoY 
14rootPassword: 9YZInPYCqXwerS0NE6PDGrxo9g0l4akt2fs0IJNm 
15
16# 持久化存储配置（你的成功配置，保障数据持久化）
17persistence:
18 enabled: true
19 storageClass: "" # 使用集群默认存储类
20 size: 10Gi 
21 mountPath: /export
22
23# 服务配置（集群内访问，无需暴露外网）
24service:
25 type: ClusterIP
26 port: 9000 # S3兼容接口端口（Loki对接用）
27consoleService:
28 type: ClusterIP
29 port: 9001 # 管理控制台端口（可选）
30
31# 默认Bucket（Loki日志存储专用，自动创建，无需手动操作）
32defaultBucket:
33 enabled: true
34 name: loki-chunks  # Loki配置需与该Bucket名一致
35 policy: read-write
36 purge: false # 卸载MinIO时保留数据
37
38# 资源限制（适配测试环境，低资源占用）
39resources:
40 requests:
41 cpu: 100m
42 memory: 512Mi
43 limits:
44 cpu: 500m
45 memory: 1Gi
46
47# 健康检查（分布式启动稍慢，微调延迟避免探针失败）
48livenessProbe:
49 initialDelaySeconds: 90
50 periodSeconds: 10
51readinessProbe:
52 initialDelaySeconds: 60
53 periodSeconds: 5
54
55# 跨节点调度策略（强制2个副本分布在不同节点，保障高可用）
56affinity:
57 podAntiAffinity:
58 requiredDuringSchedulingIgnoredDuringExecution:
59 - labelSelector:
60 matchExpressions:
61 - key: app.kubernetes.io/name
62 operator: In
63 values:
64 - minio
65 topologyKey: kubernetes.io/hostname
66
67# 安全配置（确保权限足够）
68securityContext:
69 runAsUser: 0
70 runAsGroup: 0
71 fsGroup: 0
72
73# 监控集成（默认关闭，若需对接Prometheus可改为true）
74metrics:
75 enabled: false
76 serviceMonitor:
77 enabled: false

安装分布式 MinIO

1helm install minio minio/minio \
2 -n monitoring \
3 --version 5.4.0 \
4 -f minio-distributed-values.yaml

验证 MinIO 部署（2 节点核心检查）

1# 查看MinIO Pod状态（2个副本均为Running，分布在不同节点）
2kubectl get pods -n monitoring -o wide | grep minio
3
4# 查看MinIO Service（地址固定，扩容后不变）
5kubectl get svc -n monitoring | grep minio
6
7# 验证桶创建成功
8kubectl exec -n monitoring minio-0 -- mc ls minio
9# 预期输出：[2024-xx-xx xx:xx:xx UTC] DIR loki-data

创建存储桶

Loki 的 ConfigMap 中指定了两个桶：chunks（存储日志块）、ruler（存储规则），先在 MinIO 中手动创建这两个桶（避免 Loki 首次写入时因桶不存在报错）：

1# 进入minio-0 Pod，创建chunks和ruler桶
2kubectl exec -it minio-0 -n monitoring -- /bin/sh -c "
3 /usr/local/bin/mc alias set minio http://localhost:9000 U4DwltABIX8p20aONyoY 9YZInPYCqXwerS0NE6PDGrxo9g0l4akt2fs0IJNm --api S3v4 &&
4 /usr/local/bin/mc mb minio/chunks --ignore-existing &&
5 /usr/local/bin/mc mb minio/ruler --ignore-existing &&
6 echo '✅ Loki所需的chunks和ruler桶创建成功' &&
7 /usr/local/bin/mc ls minio # 验证桶是否存在
8"

第 11 步：安装 Loki 和 Promtail

编写 Loki 配置文件（loki-values.yaml）

 1autoscaling:
 2 enabled: true
 3 maxReplicas: 5
 4 minReplicas: 2
 5 targetCPUUtilizationPercentage: 70
 6 targetMemoryUtilizationPercentage: 80
 7backend:
 8 persistence:
 9 enabled: true
10 size: 10Gi
11 storageClass: local
12 replicas: 2
13 # 可选新增：就绪探针（解决之前Pod卡死问题，不影响原有配置）
14 readinessProbe:
15 initialDelaySeconds: 60
16 timeoutSeconds: 10
17canary:
18 enabled: false
19gateway:
20 enabled: false
21grafanaAgent:
22 enabled: false
23image:
24 tag: 2.9.2
25loki:
26 auth_enabled: false
27 limits_config:
28 retention_period: 720h
29 schemaConfig:
30 configs:
31 - index:
32 period: 24h
33 prefix: index_
34 object_store: s3
35 schema: v11
36 store: boltdb-shipper
37 storage:
38 config:
39 s3:
40 access_key_id: U4DwltABIX8p20aONyoY
41 bucketnames: chunks  # 匹配MinIO已创建的chunks桶
42 endpoint: minio:9000 # 保留你原有简写地址，不改动
43 insecure: true
44 secret_access_key: 9YZInPYCqXwerS0NE6PDGrxo9g0l4akt2fs0IJNm
45 s3forcepathstyle: true # MinIO必需的核心配置
46 type: s3
47read:
48 replicas: 2
49 # 可选新增：就绪探针（解决之前Pod卡死问题，不影响原有配置）
50 readinessProbe:
51 initialDelaySeconds: 60
52 timeoutSeconds: 10
53resources:
54 limits:
55 cpu: 1000m
56 memory: 2Gi
57 requests:
58 cpu: 300m
59 memory: 768Mi
60write:
61 persistence:
62 enabled: true
63 size: 20Gi
64 storageClass: local
65 replicas: 2
66 # 可选新增：就绪探针（解决之前Pod卡死问题，不影响原有配置）
67 readinessProbe:
68 initialDelaySeconds: 60
69 timeoutSeconds: 10

部署 Loki

1# 部署Loki
2helm install loki grafana/loki -n monitoring \
3 -f loki-values.yaml \
4 --version 5.36.0

Loki ConfigMap:

 1apiVersion: v1
 2data:
 3 config.yaml: |2
 4
 5 auth_enabled: false
 6 common:
 7 compactor_address: 'loki-backend'
 8 path_prefix: /var/loki
 9 replication_factor: 1
10 storage:
11 s3:
12 bucketnames: chunks
13 # 新增：MinIO集群内服务地址
14 endpoint: minio.monitoring.svc.cluster.local:9000
15 # 新增：MinIO的Access Key
16 access_key_id: U4DwltABIX8p20aONyoY
17 # 新增：MinIO的Secret Key
18 secret_access_key: 9YZInPYCqXwerS0NE6PDGrxo9g0l4akt2fs0IJNm
19 # 修正：MinIO未开启HTTPS，改为true
20 insecure: true
21 # 修正：MinIO必须开启路径风格，改为true
22 s3forcepathstyle: true
23 frontend:
24 scheduler_address: query-scheduler-discovery.monitoring.svc.cluster.local.:9095
25 frontend_worker:
26 scheduler_address: query-scheduler-discovery.monitoring.svc.cluster.local.:9095
27 index_gateway:
28 mode: ring
29 limits_config:
30 enforce_metric_name: false
31 max_cache_freshness_per_query: 10m
32 reject_old_samples: true
33 reject_old_samples_max_age: 168h
34 retention_period: 720h
35 split_queries_by_interval: 15m
36 memberlist:
37 join_members:
38 - loki-memberlist
39 query_range:
40 align_queries_with_step: true
41 ruler:
42 storage:
43 s3:
44 bucketnames: ruler
45 # 新增：MinIO集群内服务地址
46 endpoint: minio.monitoring.svc.cluster.local:9000
47 # 新增：MinIO的Access Key
48 access_key_id: U4DwltABIX8p20aONyoY
49 # 新增：MinIO的Secret Key
50 secret_access_key: 9YZInPYCqXwerS0NE6PDGrxo9g0l4akt2fs0IJNm
51 # 修正：MinIO未开启HTTPS，改为true
52 insecure: true
53 # 修正：MinIO必须开启路径风格，改为true
54 s3forcepathstyle: true
55 type: s3
56 runtime_config:
57 file: /etc/loki/runtime-config/runtime-config.yaml
58 schema_config:
59 configs:
60 - index:
61 period: 24h
62 prefix: index_
63 object_store: s3
64 schema: v11
65 store: boltdb-shipper
66 server:
67 grpc_listen_port: 9095
68 http_listen_port: 3100
69 storage_config:
70 hedging:
71 at: 250ms
72 max_per_second: 20
73 up_to: 3
74kind: ConfigMap
75metadata:
76 annotations:
77 meta.helm.sh/release-name: loki
78 meta.helm.sh/release-namespace: monitoring
79 creationTimestamp: "2025-11-24T08:14:03Z"
80 labels:
81 app.kubernetes.io/instance: loki
82 app.kubernetes.io/managed-by: Helm
83 app.kubernetes.io/name: loki
84 app.kubernetes.io/version: 2.9.2
85 helm.sh/chart: loki-5.36.0
86 name: loki
87 namespace: monitoring
88 resourceVersion: "8228076"
89 uid: 103b336c-fcb1-4516-85d8-76d45ca6c79d

验证 Loki 部署

1# 查看Loki核心组件（read/write/backend均需Running）
2kubectl get pods -n monitoring | grep -E "loki-read|loki-write|loki-backend"
3# 示例输出：
4# loki-backend-0 2/2 Running 0 5m
5# loki-read-546cd5b67c-dsb84 1/1 Running 0 5m
6# loki-write-0 1/1 Running 0 5m

部署 Promtail（日志采集代理）

编写 Promtail 配置文件（promtail-values.yaml）

 1config:
 2 # 对接Loki的write服务（集群内服务名解析）
 3 clients:
 4 - url: http://loki-write:3100/loki/api/v1/push
 5 
 6 # 日志采集规则（采集K8s Pod日志）
 7 scrape_configs:
 8 - job_name: kubernetes-pods
 9 kubernetes_sd_configs:
10 - role: pod  # 基于Pod自动发现
11 relabel_configs:
12 # 添加命名空间标签
13 - source_labels: [__meta_kubernetes_pod_namespace]
14 action: replace
15 target_label: namespace
16 # 添加Pod名称标签
17 - source_labels: [__meta_kubernetes_pod_name]
18 action: replace
19 target_label: pod
20 # 添加容器名称标签
21 - source_labels: [__meta_kubernetes_pod_container_name]
22 action: replace
23 target_label: container
24 # 过滤掉无需采集的系统组件（可选，按需调整）
25 - source_labels: [__meta_kubernetes_pod_namespace]
26 regex: "kube-system|istio-system"
27 action: drop
28
29# 部署模式：DaemonSet（每个节点1个副本）
30daemonset:
31 enabled: true
32 extraArgs:
33 - --max-open-files=1000000  # 增加文件打开限制
34 # 健康检查配置
35 readinessProbe:
36 initialDelaySeconds: 60
37 timeoutSeconds: 10
38
39# 权限配置（解决日志目录读取权限问题）
40securityContext:
41 runAsUser: 0 # 以root用户运行
42 runAsGroup: 0
43 fsGroup: 0
44 allowPrivilegeEscalation: true
45 capabilities:
46 add:
47 - DAC_READ_SEARCH  # 增加目录读取权限
48
49# 资源配置（低资源占用）
50resources:
51 requests:
52 cpu: 50m
53 memory: 64Mi
54 limits:
55 cpu: 200m
56 memory: 256Mi
57
58# 禁用非必需组件
59serviceMonitor:
60 enabled: false
61prometheusRule:
62 enabled: false

部署 Promtail

1# 部署Promtail
2helm install promtail grafana/promtail -n monitoring \
3 -f promtail-values.yaml \
4 --version 5.36.0

验证 Promtail 部署

1# 查看Promtail Pod（每个节点1个副本，均需Running）
2kubectl get pods -n monitoring | grep promtail
3
4# 查看Promtail日志（确认无报错，有日志推送记录）
5PROMTAIL_POD=$(kubectl get pods -n monitoring -l app=promtail -o jsonpath='{.items[0].metadata.name}')
6kubectl logs -n monitoring $PROMTAIL_POD | grep "Successfully sent batch"
7# 示例输出：level=info ts=xxx caller=client.go:347 msg="Successfully sent batch"

最终验证

验证 GPU Operator & GPU metrics 是否正常

看 GPU Operator 相关 Pod：

1kubectl -n gpu-operator get pods
2kubectl -n gpu-operator get ds

通常会看到类似：

驱动 DaemonSet
Device Plugin DaemonSet
nvidia-dcgm-exporter 或类似名字的 DaemonSet

找到 DCGM Exporter 暴露出来的 Service：

1kubectl -n gpu-operator get svc

里面一般会有一个和 dcgm-exporter 类似名字的 Service，对应端口 9400（Prometheus 默认端口）。

本地 port-forward 看看 /metrics：

1# 换成你查到的 dcgm exporter 服务名
2kubectl -n gpu-operator port-forward svc/nvidia-dcgm-exporter 9400:9400
3
4# 打开一个新终端：
5curl http://127.0.0.1:9400/metrics | head

应该能看到类似：

1# HELP DCGM_FI_DEV_SM_CLOCK SM clock frequency (in MHz).
2# TYPE DCGM_FI_DEV_SM_CLOCK gauge
3DCGM_FI_DEV_SM_CLOCK{gpu="0",UUID="GPU-xxxx"} 139
4...

说明 GPU 指标已经通过 DCGM Exporter 暴露出来了。

轻量级测试

1# 运行 GPU 测试 (显式申请 1 个 GPU)
2sudo kubectl run test-gpu-real \
3 -n model-serving \
4 --image=vllm/vllm-openai:latest \
5 --restart=Never \
6 --overrides='{"metadata": {"annotations": {"sidecar.istio.io/inject": "false"}}, "spec": {"containers": [{"name": "test-gpu-real", "image": "vllm/vllm-openai:latest", "command": ["nvidia-smi"], "resources": {"limits": {"nvidia.com/gpu": "1"}}}]}}'
7
8kubectl logs test-gpu-real -n model-serving

完整测试（triton + vllm）

有关 Namespace

注意 InferenceService 的 namespace 是：model-serving

为什么必须是 model-serving？

Istio 注入生效：我们之前只给 model-serving 命名空间打了 istio-injection=enabled 标签。只有部署在这个命名空间下的 Pod，才会自动拥有 Istio Sidecar（负责流量路由、Metrics 等）。
资源隔离：将业务模型与系统组件（如 gpu-operator, knative-serving）分开，是生产环境的最佳实践。

举例：

 1apiVersion: serving.kserve.io/v1beta1
 2kind: InferenceService
 3metadata:
 4 name: qwen-7b-chat  # 你的服务名称
 5 namespace: model-serving  # 👈 这里必须写 model-serving
 6spec:
 7 predictor:
 8 model:
 9 modelFormat:
10 name: vllm  # 对应 ClusterServingRuntime 的名字
11 runtime: kserve-vllm  # 如果你有自定义 Runtime，这里指定名字
12 storageUri: "pvc://model-pvc/qwen-7b" # 或者 "s3://..."
13 resources:
14 requests:
15 cpu: "4"
16 memory: "16Gi"
17 nvidia.com/gpu: "1" # 👈 申请 1 张显卡
18 limits:
19 cpu: "4"
20 memory: "16Gi"
21 nvidia.com/gpu: "1"

即使 YAML 里写了 namespace，习惯上在 apply 时显式指定一下也是个好习惯（双重保险）：

1kubectl apply -f isvc-llm.yaml -n model-serving

五、完整调用链路

六、基于 Argo 的 CI / CD

GitHub: https://github.com/argoproj/argo-cd 官网：https://argoproj.github.io/

“

Argo = 一套专门给 Kubernetes 用的开源工具家族，用来做 CI / CD、工作流编排、GitOps 部署、灰度发布、事件驱动等，是 CNCF 下面的毕业项目

Argo 不是一个单一软件，而是一个 “工具矩阵”，主要包括四个子项目：

Argo Workflows

Kubernetes 原生的工作流 / 任务编排引擎
用 CRD（自定义资源）定义 Workflow，每个步骤跑在 Pod 里，非常适合 CI 流水线、数据处理、ML 训练等批处理任务

Argo CD

一个 GitOps 风格的持续交付工具
通过对比 Git 仓库里的 “期望状态” 和 K8s 集群中的 “实际状态”，自动同步和回滚应用，常用来管理大规模集群配置

Argo Rollouts

替代原生 Deployment 的 CRD
支持蓝绿发布、金丝雀发布，可以接入网关、监控指标做渐进式发布和自动回滚

Argo Events

做事件驱动自动化
支持各种事件源（Webhook、Kafka、S3 等），触发 Argo Workflows 或其他 K8s 资源，实现 event-driven CI / CD 或自动化任务

一句话：Argo = “围绕 Kubernetes 打造的一整套自动化 / GitOps / 发布 / 事件工具链”。

Argo 跟 Kubernetes 是什么关系？

“

Kubernetes 提供 “集群和基础设施”，Argo 提供 “在这个集群上自动化地干活的工具”。Argo 是 Kubernetes 最主流的 GitOps / Workflow 方案之一

CNCF 官方介绍中就把 Argo 定义为 “Kubernetes-native tools to run workflows, manage clusters, and do GitOps right”

运行环境层面：完全依赖 K8s

Argo 的所有组件（Controller、UI 等）都是以 Deployment / Pod 的形式部署在 Kubernetes 集群中。
Argo 的核心对象（Workflow、Rollout、EventSource、Application 等）都是 Kubernetes CRD。

职责分工：

Kubernetes 负责：调度 Pod、管理节点、网络、存储、基础监控。
Argo 负责：
把一堆任务编排成 “工作流” 并在 K8s 上跑（Workflows）
把 Git 仓库里的 YAML 自动同步到集群（CD & GitOps）
把发布过程做成可观测、可灰度控制的 rollouts（Rollouts）
把外部事件变成触发器（Events）

部署层级

所有文件都应该放到 git 让 Argo 负责吗？

不是的，这涉及到 “部署层级” 的问题。在云原生的 GitOps 实践中，我们将部署分为了两个截然不同的层级：

层级一：平台基础设施层

包含组件：Istio, Knative Serving, KServe, Cert-Manager, Nvidia Device Plugin 等。
特点：
变动低频：装好后很少动，顶多几个月升级一次版本。
全局影响：一旦挂了，所有模型全挂。
管理者：平台运维工程师 / SRE。
部署方式：通常使用 Helm Chart 或 Operator。

层级二：应用负载层

包含组件：InferenceService (模型), gateway (网关), ConfigMap (业务配置)。
特点：
变动高频：每天可能有新模型上线，或者修改版本、调整并发参数。
局部影响：配置错了只影响这一个模型。
管理者：算法工程师 / MLOps 工程师。
部署方式：YAML 文件 (InferenceService)。

所以目前来看，层级二的内容要以放到 git 中由 argo 管理 CD。层级一的也可以放到 git 中，但手动运维。

实践

Jenkins 本身是可以做全套的 CI + CD 的，但从我们推理服务部署这件事上来讲，CD (持续部署) 并不适合用 Jenkins，而适合用 Argo。Jenkins 在我们的这个场景下可以继续做它擅长的 CI (持续集成)，但想了想，没必要那么麻烦，全部用 Argo 结合 Git 就完全能搞定，而且很方便，不适合用 jenkins 再增加运维复杂度了。

ArgoCD 是云原生时代的王者（GitOps 流）

实操 for Triton（预演）

假设：

Git 仓库地址：git@github.com:your-name/ai-ops.git
S3 Bucket：my-ai-models
EKS 命名空间：ai-serving
自定义 Docker 镜像 –> 镜像仓库

第一阶段：基础设施与权限准备 (一次性工作)

这部分工作通常不需要经常变动，主要是为了打通 K8s 和 S3 的权限，以及准备 Git 仓库。

创建 Namespace (如果还没建)

1kubectl create namespace ai-serving

配置 S3 访问凭证 (Secrets) 注意：敏感信息不要直接上传到 Git。我们先用 kubectl 手动创建 Secret（或者使用 ExternalSecrets / SealedSecrets 等高级方案，但现在先用简单直接的方式）。

准备一个 s3-secret.yaml 在你本地（不要提交到 Git）：

 1apiVersion: v1
 2kind: Secret
 3metadata:
 4 name: my-s3-secret
 5 namespace: ai-serving
 6 annotations:
 7 serving.kserve.io/s3-endpoint: "s3.amazonaws.com" # AWS S3
 8 serving.kserve.io/s3-region: "us-east-1" # 你的 Region
 9type: Opaque
10stringData:
11 AWS_ACCESS_KEY_ID: "你的AK"
12 AWS_SECRET_ACCESS_KEY: "你的SK"

执行应用：

1kubectl apply -f s3-secret.yaml

在你的 ai-ops Git 仓库中，创建一个专门存放 ASR 部署文件的目录，例如 apps/asr-service/overlays/prod (如果是 Kustomize 结构) 或者直接 manifests/asr-service。

建议结构如下

1manifests/asr-service/
2├── service-account.yaml # 关联 Secret 的账号配置
3└── inference-service.yaml # 核心模型服务配置

编写 manifests/asr-service/service-account.yaml 并提交到 Git：

1apiVersion: v1
2kind: ServiceAccount
3metadata:
4 name: sa-s3-access
5 namespace: ai-serving
6secrets:
7 - name: my-s3-secret # 引用刚才手动创建的 Secret

第二阶段：模型工件准备 (模型上线 / 更新时操作)

这个阶段是 “搬运工” 工作，把模型传上去，让 KServe 有东西可拉。

本地整理 Triton 结构

如之前所述，确保本地目录结构正确：

1simple-asr/
2├── config.pbtxt
3└── 1/
4 └── model.onnx

上传到 S3

使用 AWS CLI 或手动上传。

1# 假设上传到 bucket 的 triton-repo 目录下
2aws s3 cp --recursive simple-asr/ s3://my-ai-models/triton-repo/simple-asr/

验证：确保 s3://my-ai-models/triton-repo/simple-asr/config.pbtxt 存在。

第三阶段：Argo CD 配置与部署 (GitOps 核心)

这是让 Argo CD 接管部署的关键步骤。

编写 InferenceService 配置文件

在 Git 仓库的 manifests/asr-service/inference-service.yaml 中写入：

 1apiVersion: serving.kserve.io/v1beta1
 2kind: InferenceService
 3metadata:
 4 name: asr-service
 5 namespace: ai-serving
 6 annotations:
 7 # 稍微改动这个字段可以触发 Argo 重新同步和 Pod 重启，常用于强制重新拉取模型
 8 serving.kserve.io/model-version: "v1-20231121" 
 9spec:
10 predictor:
11 serviceAccountName: sa-s3-access
12 model:
13 modelFormat:
14 name: onnx
15 runtime: kserve-tritonserver
16 storageUri: s3://my-ai-models/triton-repo/simple-asr
17 resources:
18 limits:
19 nvidia.com/gpu: 1

提交代码到 Git：

1git add .
2git commit -m "Add ASR inference service"
3git push

创建 Argo CD Application

你需要告诉 Argo CD：“去监控我的 Git 仓库，把东西部署到 EKS 里”。

你可以通过 Argo CD 的 Web UI 点击 “New App” 创建，或者写一个 YAML 文件（推荐 YAML 方式，这叫 App-of-Apps 模式）。

创建一个文件 asr-argocd-app.yaml (手动 apply 这个文件)：

 1apiVersion: argoproj.io/v1alpha1
 2kind: Application
 3metadata:
 4 name: asr-serving-app
 5 namespace: argocd
 6spec:
 7 project: default
 8 source:
 9 repoURL: 'https://github.com/your-name/ai-ops.git' # 你的 Git 地址
10 targetRevision: HEAD
11 path: manifests/asr-service  # 你的 YAML 所在目录
12 destination:
13 server: 'https://kubernetes.default.svc'
14 namespace: ai-serving
15 # 开启自动同步和自愈
16 syncPolicy:
17 automated:
18 prune: true # Git 里删了文件，K8s 里也删掉
19 selfHeal: true # 手动改了 K8s 配置，Argo 会强制改回来
20 syncOptions:
21 - CreateNamespace=true

执行：

1kubectl apply -f asr-argocd-app.yaml

第四阶段：验证与观察

一旦应用了上面的 Application YAML，奇迹就开始了：

观察 Argo CD UI：

你会看到 asr-serving-app 变成 Processing 状态。
它会画出一棵树：Application -> InferenceService -> Knative Configuration -> Revision -> Deployment -> Pod。
确保所有图标变绿（Healthy 和 Synced）。

观察 Pod 状态 (命令行)：

1kubectl get pods -n ai-serving

你会看到类似 asr-service-predictor-00001-deployment-xxx 的 Pod。

如果是 Init:0 / 1：正在运行 storage-initializer 下载 S3 模型。
如果是 Running：模型下载完毕，Triton 启动成功

日常开发流程

这套系统搭建好后，以后的日常工作流就是：

算法同学：训练新模型 -> 导出 ONNX -> 上传覆盖 S3 上的 model.onnx。
运维 / 算法同学：

修改 Git 里的 inference-service.yaml。
比如修改 annotations 里的 version: “v2” 或者修改资源配额。
git push。

Argo CD：自动检测到 Git 变化 -> 更新 K8s 资源 -> Knative 滚动更新 -> 新 Pod 拉取新模型 -> 流量平滑切换。

这就是最标准的 GitOps 模型部署流程。

实操 for vLLM（预演）

第一阶段：基础设施准备 (一次性工作)

因为 KServe 可能不知道怎么启动 vLLM，我们需要先在集群里注册一个 “说明书”，告诉 KServe：“当我说用 vllm 时，请拉取这个镜像并运行这个命令”。

创建 vLLM 的 ClusterServingRuntime

将以下内容保存为 vllm-runtime.yaml 并 kubectl apply -f（或者放入 ArgoCD 管理的基础设施 Git 仓库中）。

 1apiVersion: serving.kserve.io/v1alpha1
 2kind: ClusterServingRuntime
 3metadata:
 4 name: kserve-vllm
 5spec:
 6 annotations:
 7 prometheus.kserve.io/path: "/metrics"
 8 prometheus.kserve.io/port: "8000"
 9 containers:
10 - name: kserve-container
11 image: vllm/vllm-openai:latest  # 使用 vLLM 官方镜像
12 command: ["python3", "-m", "vllm.entrypoints.openai.api_server"]
13 args:
14 # 这里的 args 是默认值，会被 InferenceService 里的 args 覆盖或追加
15 - --port=8080
16 - --model=/mnt/models
17 - --served-model-name=default
18 - --trust-remote-code
19 env:
20 - name: HF_HOME
21 value: /tmp/hf
22 resources:
23 requests:
24 cpu: "4"
25 memory: "16Gi"
26 limits:
27 cpu: "8"
28 memory: "32Gi"

“

注意：vLLM 默认监听 8000，但 KServe 容器通常要求监听 8080，所以我们在 args 里强制指定 –port = 8080。

第二阶段：模型上传 (S3)

vLLM 不需要 Triton 那种 1 / model.onnx 的结构。它只需要标准的 HuggingFace 模型文件夹。

假设你要部署 Qwen2-7B：

本地准备

你需要把 HuggingFace 上的文件下载下来，目录结构大概长这样：

1Qwen2-7B/
2├── config.json
3├── tokenizer.json
4├── model-00001-of-00004.safetensors
5├── ...
6└── model.safetensors.index.json

上传 S3

1aws s3 cp --recursive Qwen2-7B/ s3://my-ai-models/llm/Qwen2-7B/

第三阶段：Argo CD 部署配置 (GitOps)

在 Git 仓库中（manifests/llm-service/），编写 inference-service.yaml。

这里有几个关键点需要注意：

runtime: 指定刚才创建的 kserve-vllm。
storageUri: 指向 S3 文件夹。KServe 会把这里面的所有文件下载到 Pod 的 /mnt/models 目录下。
args: 我们需要覆盖启动参数，告诉 vLLM 模型就在 /mnt/models。

 1apiVersion: serving.kserve.io/v1beta1
 2kind: InferenceService
 3metadata:
 4 name: qwen-llm
 5 namespace: ai-serving
 6 annotations:
 7 # LLM 启动很慢（加载权重需要时间），必须调大健康检查超时时间，否则会被 K8s 杀掉
 8 serving.knative.dev/progressDeadline: "20m" 
 9 
10 # 自动扩缩容配置 (LLM通常基于并发或请求数)
11 autoscaling.knative.dev/target: "5" 
12 autoscaling.knative.dev/minScale: "1" # 建议 LLM 至少保留1个，因为冷启动太慢了
13 autoscaling.knative.dev/maxScale: "3"
14spec:
15 predictor:
16 serviceAccountName: sa-s3-access # 别忘了 S3 权限账号
17 model:
18 modelFormat:
19 name: pytorch 
20 runtime: kserve-vllm # 对应 ClusterServingRuntime 的名字
21 
22 # KServe 会把这个 S3 路径下的内容下载到容器的 /mnt/models
23 storageUri: s3://my-ai-models/llm/Qwen2-7B
24 
25 # 核心参数配置
26 args:
27 - --model=/mnt/models  # 必填：指向下载好的模型路径
28 - --served-model-name=qwen # 服务名称，API调用时用到
29 - --gpu-memory-utilization=0.9 # 显存占用率
30 - --max-model-len=4096  # 上下文长度，防止 OOM
31 - --dtype=float16  # 或 bfloat16
32 
33 resources:
34 requests:
35 cpu: "8"
36 memory: "32Gi"
37 nvidia.com/gpu: 1 # 必须有 GPU
38 limits:
39 cpu: "16"
40 memory: "64Gi"
41 nvidia.com/gpu: 1
42 nodeSelector:
43 gpu-type: "A100" # 建议指定节点类型

提交到 Git，Argo CD 检测到后会自动同步。

创建 Argo CD Application

你可以通过 Argo CD 的 Web UI 点击 “New App” 创建，或者写一个 YAML 文件（推荐 YAML 方式，这叫 App-of-Apps 模式）。

创建一个文件 llm-argocd-app.yaml (手动 apply 这个文件)：

 1apiVersion: argoproj.io/v1alpha1
 2kind: Application
 3metadata:
 4 name: llm-serving-app  # 应用名称，要在 Argo 面板上显示的
 5 namespace: argocd  # ArgoCD 安装的命名空间
 6spec:
 7 project: default
 8 source:
 9 repoURL: 'https://github.com/your-name/ai-ops.git' # 你的 Git 仓库
10 targetRevision: HEAD
11 path: manifests/llm-service  # ✅ 关键点：指向存放 vLLM InferenceService 的目录
12 destination:
13 server: 'https://kubernetes.default.svc'
14 namespace: ai-serving  # 部署的目标命名空间
15 # 启用自动同步，Git 变了 K8s 自动变
16 syncPolicy:
17 automated:
18 prune: true # Git 里删了，K8s 也删
19 selfHeal: true # K8s 里被改了，强制还原回 Git 的状态
20 syncOptions:
21 - CreateNamespace=true # 如果 ai-serving 命名空间不存在，自动创建

执行：

1kubectl apply -f llm-argocd-app.yaml

第四阶段：部署后的验证与调用

vLLM 启动成功后，它提供的是 OpenAI Compatible API。这意味着你可以直接用 OpenAI 的 SDK 或者 curl 来调用，这比 Triton 的 gRPC 接口对开发者更友好。

验证 Pod 状态

1kubectl get pods -n ai-serving
2# 等待状态变为 Running (可能需要几分钟下载模型和加载权重)
3kubectl logs -f <pod-name> -c kserve-container -n ai-serving
4# 看到日志显示 "Uvicorn running on http://0.0.0.0:8080" 即成功

调用测试 (在集群内部或通过 Ingress)

获取服务的 URL

1kubectl get isvc qwen-llm -n ai-serving
2# 假设 URL 是 http://qwen-llm.ai-serving.svc.cluster.local

发送请求（完全兼容 OpenAI 格式）：

 1curl http://qwen-llm.ai-serving.svc.cluster.local/v1/chat/completions \
 2 -H "Content-Type: application/json" \
 3 -d '{
 4 "model": "qwen",
 5 "messages": [
 6 {"role": "system", "content": "You are a helpful assistant."},
 7 {"role": "user", "content": "你好，介绍一下你自己。"}
 8 ],
 9 "max_tokens": 100
10 }'

vLLM 流程的关键 Checklist

ClusterServingRuntime: 你的集群里如果没有 kserve-vllm 定义，第一步就会报错，必须先加这个 CRD。
Timeouts: LLM 动辄 20GB+，下载 + 加载显存需要很久。一定要在 annotations 里设置 progressDeadline 为 20m 或更长，否则 Knative 会以为部署失败并回滚。
Arguments: 必须通过 args 显式指定 –model=/mnt/models，因为这是 KServe storageUri 下载的目标路径。
Resources: 显存和内存给够，否则 vLLM 会报 OOM（Out Of Memory）并 CrashLoopBackOff。

这套流程结合 ArgoCD 后，以后更新 LLM 版本（比如从 Qwen2 换到 Qwen2.5），你只需要：

上传新模型到 S3 的新目录。
修改 Git 里的 storageUri。
ArgoCD 自动同步，Knative 会等待新 Pod 里的 vLLM 完全加载好权重后，才切断旧 Pod 的流量。

七、如何衡量平台是否成功？

一个优秀的模型服务平台，其核心指标应该覆盖性能、成本、稳定性几个维度。

维度一：性能与延迟 (Performance & Latency) - “我们的服务快不快？”

端到端延迟 (End-to-End Latency) - P95 / P99

是什么？从业务应用发出 API 请求，到收到完整响应的总时间。
为什么重要？这是衡量用户体验的黄金标准。我们通常关注 P95（95% 的请求都快于此值）和 P99，因为平均值会掩盖那些最慢的、最影响用户的请求。
如何衡量？从 Istio Gateway 或 Prometheus 中间件获取。

首 Token 时间 (Time to First Token - TTFT) - (LLM 专属)

是什么？对于生成式模型，从发出请求到收到第一个有意义的 token 所需的时间。
为什么重要？这是衡量 LLM 服务 “感知响应速度” 的最关键指标。一个低 TTFT 的模型会让用户感觉 “反应很快”，即使生成全文总时间较长。
如何衡量？需要在客户端或 Transformer 中进行定制化测量

每输出 Token 时间 (Time Per Output Token - TPOT) - (LLM 专属)

是什么？生成每个后续 token 的平均时间。它是 (总时间 - TTFT) / (总 token 数 - 1)。
为什么重要？这是衡量 LLM “生成速度” 的核心指标。一个低的 TPOT 意味着模型的 “吐字” 速度很快，用户体验流畅。
如何衡量？客户端或 Transformer 中计算。

吞吐量 (Throughput)

是什么？单位时间内平台能成功处理的请求数。通常用 RPS (Requests Per Second) 或 QPS (Queries Per Second) 表示。
对于 LLM，一个更有意义的指标可能是输出 Tokens/秒 (Output Tokens/Second)，因为它综合了并发处理能力和生成速度。
为什么重要？这是衡量平台容量和处理能力的上限。

维度二：成本与效率 (Cost & Efficiency) - “我们的钱花得值不值？”

GPU 利用率 (GPU Utilization - Compute)

是什么？ GPU 计算核心在单位时间内的繁忙程度百分比。
为什么重要？这是衡量 “GPU 是否在干活” 的首要指标。一个持续低于 20% 的利用率可能意味着巨大的资源浪费。
如何衡量？通过 NVIDIA DCGM Exporter 在 Prometheus 中采集。

GPU 显存利用率 (GPU Memory Utilization)

是什么？ GPU 显存被占用的百分比。
为什么重要？很多模型（尤其是 LLM）可能计算量不大，但会占用海量显存。高显存占用会限制单卡能部署的模型数量。这是成本优化的另一个关键。
如何衡量？通过 NVIDIA DCGM Exporter 采集。

闲置实例数 / 缩容至零频率 (Scale-to-Zero Metrics)

是什么？平台上有多少模型服务实例处于 0 副本状态，以及它们进入和退出 0 副本状态的频率。
为什么重要？直接体现了 KServe + Knative Serverless 架构带来的成本节省效果。
如何衡量？从 Knative 的监控指标中获取。

冷启动延迟 (Cold Start Latency)

是什么？当一个服务从 0 副本状态接收到第一个请求时，从开始拉起 Pod 到成功响应请求的总时间。
为什么重要？这是 Serverless 模式为了节省成本而付出的性能代价。你需要监控并优化它，确保它在可接受的范围内。
如何衡量？结合 Knative 指标和应用日志进行分析。

维度三：稳定性与可用性 (Stability & Availability)- “我们的服务稳不稳？”

服务可用性 (Availability)

是什么？在规定时间内，服务能够正常响应的请求比例。通常目标是 99.9% 或 99.99%。
为什么重要？这是衡量服务可靠性的最终标准。
如何衡量？ (成功请求数 / 总请求数) * 100%。

错误率 (Error Rate)

是什么？返回 5xx（服务器错误）状态码的请求比例。
为什么重要？错误率的飙升是服务出现严重问题的最直接信号。需要设置告警。
如何衡量？从 Istio Gateway 或 Prometheus 中间件获取。

Pod 重启次数 (Pod Restart Count)

是什么？模型服务 Pod 的重启次数。
为什么重要？频繁的重启（特别是 CrashLoopBackOff 状态）表明代码存在 Bug、内存溢出（OOM Killed）或配置错误。
如何衡量？从 Kubernetes API 直接获取。

短期看，最重要的指标有这几个：

端到端延迟 (End-to-End Latency)
首 Token 时间 (Time to First Token - TTFT)
吞吐量 (Throughput)
GPU 利用率
服务可用性

长期看其实还要加上模型效果指标，量化 “准确率” 与 “生成质量”。

3 毛钱干大事？用了几天豆包编程模型，我来扒一扒字节这波操作

Mon, 17 Nov 2025 12:58:03 +0000

“

测评人：小盒子（AI 架构仔，Agentic 编程方向，常年被 API 账单搞到头大）测评时间： 2025 年 11 月 11 日发布后的一周

这波价格战，字节是真不想给同行活路了

说实话，我当时 凌晨 1:47 在公司改那个傻 X 的 Kubernetes 配置。看到新闻推送，火山引擎出了个 豆包编程模型 Doubao-Seed-Code，说性能 SOTA，但这不是重点。

重点是价格。它宣称综合成本能比业界平均水平低 62.7%，直接是 国内最低价。我当时正在用 cc 搭配 k2，心想：都说最低价，质量怎么样呢？k2 测完了其实还是不如原装的 claude，所以 doubao-seed-code 如果真是质量高价格低的话，多一个选择也是蛮不错的。

以前我们跑一次复杂的 Agentic 任务，特别是涉及多轮 Bug 修复和重构的，Claude Sonnet 4.5 那个账单，每个月看一次疼一次。

我看官方资料里明晃晃地写着，做一个交互式英语学习网站，用 Doubao-Seed-Code 只需要 0.34 元左右，用 Claude Sonnet 4.5 可是要大概 4 块多。这差距，可以的～

它这个 API 定价，输入 1.20 元/百万 Tokens，输出 8.00 元/百万 Tokens（0-32K 区间），配合那个 Cache 技术，还能再降 80% 的成本。我们现在正在做 Agent 自动化项目，以前成本受限，很多地方要做工程优化，要这样的话，感觉忽然就 经济可行 了。

我立马摸鱼时试了下，冲了它那个 9.9 块首月的 Coding Plan。一杯咖啡钱，买一个号称 SWE-Bench Verified 榜单上 SOTA 的模型（这个榜单是测 Agent 端到端解决问题的能力，很硬核的）。

兼容 Claude Code

感觉最近这都成了编程模型的标配了哈。

作为 Claude Code 用户，感觉接入不是很丝滑的。Doubao-Seed-Code 原生兼容 Anthropic API ，接入方法还是老套路，很简单：

第一种方式

如果是短期测试，可以直接在终端中配置环境变量，在启动 Claude Code 前输入环境变量

1export ANTHROPIC_BASE_URL=https://ark.cn-beijing.volces.com/api/compatible
2export ANTHROPIC_AUTH_TOKEN=<ARK-API-KEY>
3export ANTHROPIC_MODEL=doubao-seed-code-preview-latest

第二种方式

如果是长期使用，可以直接配置文件

1open -e ~/.claude/settings.json
2
3{
4 "api_key": "xxxxxxx",
5 "api_url": "https://ark.cn-beijing.volces.com/api/compatible",
6 "model": "doubao-seed-code-preview-latest"
7}

说句提外话，最近这几家搞 code 模型的，就是明着抢 Claude 的客户，但我支持，哈哈。

切换零成本 + 价格低 60%+ 性能 SOTA 确实有点儿心动。

核心能力体验

“

长上下文和那个 VLM 才是真杀手锏

光便宜和兼容没用，代码写得烂，那也是浪费我时间。

看了一下上下文，256K，还成，跟 K2 一样，感觉现在没个 256K 都不好拿出手。

虽然 Claude 4.5 Sonnet 的上下文声称是 1M，但实际上只有 200K，而且还死贵。 256 好，还多 56K，哈哈

别小看多出来的这点儿。我手头有个遗留项目，Python 写的，几百个文件，那叫一个乱。模型处理 Bug，有时候上下文 Token 一爆，它就变瞎子了，你得手动 RAG 喂它代码，有时候就差那么一两个文件，逼得我重开个 thread，前面都白费劲了。

Doubao-Seed-Code 多出来的这 56K，意味着它能把整个中等规模的项目结构和依赖都装进 “脑子” 里

刚才我让它解决一个跨越十几个文件的逻辑 Bug，以前的模型得来回拉扯五六轮，这次它 一步到位 定位到了问题。而且它不只是修复 Bug，它还会 优化结构，提升代码的可读性和维护性。这才是 Agent 编程，不过客观地讲跟最贵的那位比还是有一定的差距。

VLM：前端仔的末日… 还是福音？

这个视觉理解（VLM）能力， 国内首发。

这个功能并不新鲜，但国内首发，算是跟上了。我现在可以直接把 UI 稿截图，或者手绘草稿扔给它。然后它能给你生成对应的代码。

我一开始以为它就是搞了个图转文字，再让 LLM 去生成代码，这种方法信息折损很大。结果它这个是原生的 VLM 能力，不是靠工具调用。最牛逼的是，它能 自己完成样式修复和 Bug 修复。它生成一个页面，然后拿截图跟你原始的设计稿对比，发现哪里边距不对，哪里颜色溢出了，自己动手改

我当时试了一个复杂的 Dashboard 界面，只给了一张截图，它生成的 React + Tailwind 代码还原度还是非常高的。前端兄弟估计已经麻木了，据我所知，他们自己也在用 vibe coding 干活，哈哈。

聊聊技术底裤

Doubao-Seed-Code 的核心是 Seed-Coder 家族，能 SOTA，说明字节在训练上砸了不少黑科技

官方资料里提了一堆很唬人的词儿, 小盒子来翻译翻译：

“大规模 Agent 强化学习训练系统” ：他们好像是搞了一套巨大的 打怪升级系统，专门用来训练代码 Agent。模型不是靠背书（预训练数据）学编程的，它是直接在 沙盒里 跑代码
构建了覆盖 10 万容器镜像的训练数据集”：为了让模型见过各种稀奇古怪的运行环境（比如 Python 3.7 + PyTorch 1.9 + CUDA 10.2），他们准备了 10 万个容器
“万级并发沙盒 session”：几万个容器同时跑。让模型在里面不断试错，错了就 罚站（接收执行反馈）。这样练出来的 Agent，解决问题的鲁棒性才强

这套机制直接解释了为什么它能在 SWE-Bench Verified 这种需要端到端解决问题的测试里登顶。它不是一个静态的知识库，它是个会 思考、会动手、会自我修正 的开发伙伴

顺便提一句，这个 Seed-Coder 还有开源版本。开源的 Seed-Coder-8B-Reasoning 有 64K 上下文，虽然不如商业 API 的 256K 那么猛，但对于个人研究也够用了。

测试

这里我做了一个测试，目的是看它能不能真的理解 “Vibe Coding”（用户描述一个抽象的、高层的需求，让 Agent 去实现），特别是设计稿的还原和自我纠错能力

找一个 UI 稿截图，越复杂越好。

最终生成的效果如下：

总结

无论最后你是否使用 doubao-seed-code 模型作为你的生产工具，我都推荐你试试，包括 k2 等其他模型，无它，AI 进化的速度很快，先上车！

单纯就 doubao-seed-code 来说，我觉得也还可以：

价格摆在那儿，跑 100 次 Agentic 任务的成本，以前可能只能跑 30 次。
VLM 是未来：前端开发效率的飞跃。
256K 上下文：真正能处理企业级复杂重构任务的基础。

Doubao-Seed-Code 这波操作，是想把 AI 编程从 “昂贵的工具” 变成 “水、电、煤” 一样基础设施。对于追求极致效率和成本控制的团队，值得一试。

今日 AI 情报（2025-11-10）

Mon, 10 Nov 2025 09:25:33 +0000

1. Kimi K2-Thinking这样用，才是真爽｜附我的一手实测

文章全面介绍并实测了Moonshot AI开源的K2-Thinking模型，展示了其搜索、推理、编程的综合能力及各种应用案例Kimi K2-Thinking这样用，才是真爽｜附我的一手实测

2.卫星上天、模型入轨，太空成为AI算力的新战场，中国领跑

介绍太空算力成为AI基础设施新战场，中国国星宇航已实现全球首个太空计算星座的部署和商业化应用卫星上天、模型入轨，太空成为AI算力的新战场，中国领跑

3.当谈论FP8训练的时候，我们到底在聊什么?

文章详细介绍了FP8训练的三种主要实现方案及其在计算加速、存储优化和通信加速方面的技术细节当谈论FP8训练的时候，我们到底在聊什么?

4.Python只是前戏，JVM才是正餐！Eclipse开源新方案，在K8s上不换栈搞定Agent

介绍Eclipse基金会推出的代理定义语言ADL和LMOS平台，旨在让企业利用熟悉的JVM技术栈而非Python构建AI代理，实现云原生环境下的智能体开发和部署Python只是前戏，JVM才是正餐！Eclipse开源新方案，在K8s上不换栈搞定Agent

5.宇树王兴兴回应硕士论文爆火；Nano Banana 2、GPT-5.1系列齐泄露？字节豆包PC端负责人齐俊元离职 | AI周报

整理了近期AI行业热点包括模型泄露事件、杭州AI企业对话、人形机器人进展、大厂人事变动等各类新闻宇树王兴兴回应硕士论文爆火；Nano Banana 2、GPT-5.1系列齐泄露？字节豆包PC端负责人齐俊元离职 | AI周报

6.英伟达、DeepSeek集体跟进！18个月前被忽视，如今统治AI推理

文章详细介绍了由加州大学圣地亚哥分校提出的解耦推理架构如何从实验室概念成长为行业标准，以及该技术在大模型推理领域的应用与发展趋势

英伟达、DeepSeek集体跟进！18个月前被忽视，如今统治AI推理

2025北京 IT技术岗位市场趋势分析

Thu, 17 Apr 2025 02:20:56 +0000

过去一年，北京数字经济对 GDP 的贡献继续攀升、AI + 传统产业融合提速，拉动技术岗位需求在 2025 年保持“量稳、质升”——总招聘量与 2024 年大体持平，但 高端与 AI‑相关职能增幅 15% 以上；与此同时，普通开发与测试岗位竞争加剧、薪酬增速放缓。整体呈现“尖端紧缺‑常规内卷”的双轨格局。

下面按岗位类型分述趋势、薪酬区间与热门技能。

宏观驱动与整体需求

北京仍是全国数字经济第一城，数字产业增加值年均增速 9%，5G、人工智能、信创（国产软硬件）成为新增岗位主引擎
2025 Hays 人才趋势显示，生成式 AI 项目扩张、混合办公、用工灵活化 是企业技术团队的三大关键词。
拉勾《一线城市数字科技人才迁徙洞察》指出，北京对高端技术人才的 净流入率 17.8% ，居四大一线城市之首，但应届生流入比例下降 4 pct，反映供给结构趋紧。
信息技术业 2024Q2‑2025Q1 招聘量同比下滑 27.8%，但算法、运维支持、产品管理等职能逆势增长。

细分岗位趋势

前端开发

重点趋势	说明
框架	React18、Vue3 + TypeScript 成主流；大厂面试开始考察 RSC、微前端落地经验。
多端融合	ByteDance、京东等推行 Modular/Universal mode，将 H5 + 小程序 + 桌面统一到一套代码。
AI‑Assist	高频使用 GitHub Copilot、ByteDance CodeGeeX 等 AI 辅助，企业更看重 Prompt‑Engineering 基础。

平均月薪区间 2 – 3.5 万元；头部公司核心前端 > 4.5 万元。

后端／全栈开发

Go + Rust 在高并发与可信场景快速渗透，Java 依旧占 48% 招聘量。
Cloud‑Native：K8s、Service Mesh、Sidecar 架构写入 JD；Serverless FaaS 试点项目增多。
薪酬与前端近似，但 3–6 年经验段的涨幅（+6.8% YoY）高于前端。

运维 / SRE

自动化 & AIOps：日志可观测、LLM‑based Root Cause Analysis 成新卖点。
大厂 DevOps‑SRE 岗位给出 15k–50k/月，中位值 34k，高于全国均值 21k
需求集中在云平台运维、容器治理、CI /CD 流水线二次开发。

测试 / QA

Shift‑Left：招聘 JD 要求能写 E2E、契合 DevSecOps；懂 API/性能/安全一体的 Full‑Stack QA 稀缺。
普通功能测试招聘量降 12%，月薪中位值 14k；自动化 / 安全测试可达 2 – 2.5 万元。

架构 / AI 大模型

大模型平台化：企业亟需能打通推理服务、RAG、知识治理的“业务 + 算法 + 云”复合型架构师。
北京人社局薪酬季报：AI 大模型架构师、深度学习研究员一季度月薪中位值 > 4 万元，位列所有 IT 职位之首。
供应缺口：相关岗位投递比仅 1 : 7，而常规开发已超过 1 : 40。

薪酬对比（中位值，税前 / 月）

职能	初级 (0‑3 年)	中级 (3‑6 年)	高级 / 专家	YoY 涨幅
前端	14 k	23 k	32 k+	+3.5 %
后端	15 k	25 k	35 k+	+6.8 %
运维 / SRE	16 k	28 k	40 k+	+5.9 %
测试	12 k	18 k	25 k	+2.1 %
架构 / AI	25 k	38 k	45‑60 k	+11.4 %

（数据综合北京 HR 局薪酬季报、Indeed、Jobui 与 iHR360 行业库）

🔥 技能热点与企业偏好

AI 嵌入：Prompt‑based 代码补全、Auto‑Test、知识库问答等场景让 Python / LLM SDK 成为附加加分项。
安全合规：等保 2.0、个人信息保护法落地，带动安全测试、DevSecOps、零信任架构招聘量增 19% YoY
信创：国资系招募国产 CPU / OS 适配工程师，优惠补贴年包 +20%。

供需与竞争

北京技术岗位投递量继续领跑一线城市；但 AI、大模型方向平均 每 1 份 JD 仅 7 份简历，反之普通 Web 开发超过 40 份简历/岗，显现结构性紧缺。
北京 2025Q1 IT 岗位平均薪资 2.9 万元，中位值 2.46 万元；同比涨幅 1.1%，明显低于 2021‑22 年两位数增速。

给企业与求职者的建议

企业

拆分 JD：将“平台研发”与“AI 应用落地”拆分，便于精准匹配候选人。
用薪酬+Tech Brand 双重激励：高端人才更看重技术氛围与成长空间，可开放技术博客、OSS 贡献等展示窗口。
培养内部转岗：参考 LinkedIn 数据，内部流动可将员工留存提升 40%

求职者

普通开发/测试应持续补齐 云原生 + 自动化测试 + 基础 AI；
关注国央企“信创”“数据要素”等长期项目，以稳就业与培训机会为优势；
AI & 架构方向建议组合 算法实践 + 高并发系统设计 + 行业领域知识，扩大竞争壁垒。

“

北京 2025 年 IT 技术岗位的主旋律是 “AI 驱动的高端岗位紧缺，传统岗位理性回调”。掌握新技能、拥抱跨领域融合将是穿越周期的关键。

云原生，你真的懂了吗？

Sat, 22 Feb 2025 04:00:00 +0000

啥是云？

说起云原生（cloud native），就不得不说明一下 “云” 是啥。

简单理解，云就是 “云计算”，如果给它下个定义的话是这样的：

云" 特指以云计算模型构建的现代化动态环境

为什么叫云呢？它怎么不叫其他的什么呢？

这个吧，就像你问马云为什么叫马云一样，那是因为给他起名的家长就是这么定的。对，云计算也是如此，计算机领域的专家就是这么定的。后来成了专业术语，大家都这么说。那你说叫 “云” 有没有道理呢？有道理。

我们类比地看，如果你将 “资源” 看成水的话，那么在天空上自由自在、飘来飘去的云就是资源的载体，在你有需要的时候，“呼风唤雨🌧️” ，一朵带着雨水（资源）的积雨云就能为你带来一场甘霖（你需要的资源）。

云在天上，不在地下，不像以前（过去的架构），你想吃水了得自己挖井，现在你可以 “呼风唤雨” 叫云给你水。而且很好管理和维护。所以你看，用 “云” 这个字还是有道理的。

“云” 可以有多种形态

云还有多种形态，一般来说有以下三种：

公有云（Public Cloud）：由第三方云计算提供商（如 AWS、Azure、Google Cloud、阿里云、腾讯云等）拥有和运营，面向公众提供服务。
私有云（Private Cloud）：由企业或组织自己拥有和运营，仅供内部使用。私有云可以部署在企业自己的数据中心，也可以托管给第三方提供商。
混合云（Hybrid Cloud）：结合了公有云和私有云的优势，允许应用程序和数据在两者之间迁移和共享。

还是用吃水比喻，公有云就像 “自来水”，打开水管就能喝。私有云就像自己找水源，自己挖井，自己舀水喝。混合云自然就是这两种的混合。

资源有啥？

说完了云，我们该说水了，云是提供资源的，那么具体有哪些资源呢？什么东西是云可以提供给我们的呢？你可能想到了：“嗨，不就是服务器嘛”。

其实 “资源” 是一个多维度的概念，远不止硬件设备。我们展开说说。

首先是：基础资源，它包括：

计算资源（CPU/GPU/FPGA）
存储资源（磁盘 / SSD / 对象存储）
网络资源（带宽 / IP / 负载均衡）
内存资源（RAM）

然后是抽象服务，比如：

容器编排（Kubernetes（EKS/GKE/ACK）、Nomad）
数据库服务（AWS RDS、阿里云 RDS）
消息队列（Kafka 云托管、AWS SQS、RabbitMQ）

接着是管理与安全，比如：

身份权限（AWS IAM、阿里云 RAM、Azure AD）
监控告警（Prometheus 云托管、Datadog、阿里云 ARMS）
日志分析（ELK Stack 云服务、Splunk）
安全防御（阿里云 WAF）

最后是高阶能力，比如：

Serverless（AWS Lambda、阿里云 FC）
服务网格（Istio、Linkerd）
边缘计算（AWS Wavelength、阿里云 ENS）
量子计算（AWS Braket、Azure Quantum）

我上面举的只是一些常见的例子，其实每一个分类下的资源条目是非常多的。所以你看，“资源” 可不止服务器那么简单，它是多维度的。现在几乎你能用的到的东西都上云了，都是资源。就算没有，经不住人家云厂商包装啊，只要你有需求，人家就有产品卖你，哈哈。

云原生

云其实还是比较好理解的，但是云原生（cloud native）就比较抽象了，在我刚接触这个概念的时候是一头雾水，无论别人给我讲，还是我给别人讲总是说不清楚，或者人家听不懂。

我们还是先来说说定义吧，我找到 CNCF （https://github.com/cncf/toc/blob/main/DEFINITION.md）的一个定义，算比较权威了。

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。

这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

Cloud native practices empower organizations to develop, build, and deploy workloads in computing environments (public, private, hybrid cloud) to meet their organizational needs at scale in a programmatic and repeatable manner. It is characterized by loosely coupled systems that interoperate in a manner that is secure, resilient, manageable, sustainable, and observable.

说实话，如果你没有在这个领域干过，光看定义是不容易理解的。甚至就算在云原生环境下从事开发的工程师，如果不认真思考、理解，也不能把什么是“云原生” 讲的很明白。

原因是这个概念本来就比较抽象。所以我不用 CNCF 的定义，换一种说法来描述一下什么是 “云原生”

云原生是一种以云计算基础设施为基石，通过容器化封装、微服务拆分、声明式 API 和自动化运维，将应用的非功能需求（如弹性扩缩、故障自愈、安全策略）交由云平台管理的架构范式。其本质是通过技术手段让业务代码与底层资源解耦，使开发者只需关注业务逻辑，而由云平台自动处理部署、监控、容灾等复杂性。

你看，我这样说是不是清晰一些了？更好理解一些了？还没有？接着往下看。

本质

透过现象看本质，概念怎么说都行，重要的是要理解这个东西的本质。

那我们就来看一看 “云原生” 的本质：

云原生并非单纯的技术集合，而是一种 “以应用为中心” 的思维模式。它通过标准化技术栈（容器 / K8s / 微服务），将云计算从 “资源层” 提升到 “应用层”，让企业能像使用水电一样按需使用计算能力。它的目标是让技术复杂性对业务透明化。

说到这里，我们就不得不说一下为什么要使用或推崇“云原生”了。

云原生的出现源于传统应用架构在云计算时代的局限性。

传统架构有许多痛点，做的传统开发的同学一定都知道，比如：

部署效率低：传统应用依赖物理服务器或虚拟机，部署流程复杂（如手动配置环境、依赖冲突）。
扩展性差：单体架构难以应对流量突增，扩容需要数小时甚至数天。
运维成本高：故障恢复、监控、日志收集等运维工作需人工干预。
环境不一致：开发、测试、生产环境差异导致 “在我机器上能跑” 的问题。

采用 “云原生” 技术栈及应用架构可以有效的解决上面的所有问题。

什么是不可替代的？

不得不说，Docker 和 Kubernetes 技术的出现给了 “云原生” 极大的助力。那如果没有 Docker 和 Kubernetes 呢？云原生这个概念还立得住吗？

其实，云原生概念的出现（2010 年 Netflix 提出）比 Docker（2013）和 Kubernetes（2014）更早。核心思想在容器技术普及前就已萌芽。所以：云原生本质是一种架构哲学，而非特定技术捆绑

那么我们紧接着下一个问题就是：什么是云原生的核心内容，有什么是缺一不可的呢？或者说缺了什么就不能算是云原生了呢？

总结来说，有四大支柱：

弹性伸缩（Elasticity）

必须能力：根据负载自动扩缩资源
替代方案：AWS Lambda（Serverless）、Nomad（非 K8s 编排器）

故障自愈（Resilience）

必须能力：服务熔断、重试、健康检查
替代方案：Hystrix（微服务容错库）+ Consul（服务发现）

声明式管理（Declarative）

必须能力：通过 YAML/JSON 描述目标状态，而非手动操作
替代方案：Terraform（基础设施即代码）+ Ansible（配置管理）

自动化交付（Automation）

必须能力：CI/CD 流水线、蓝绿部署
替代方案：GitLab CI + Spinnaker（持续交付平台）

云原生的 “复杂性悖论”

云原生看起来真好呀，但事实是这样吗？对于软件开发，我们都知道一句著名的话：“没有银弹”，是的。云原生也不是哪儿哪儿都好，它也有它的问题。

云原生存在一个看似矛盾的现象：它承诺降低业务复杂性，却引入了新的技术复杂性。

这种矛盾的核心在于技术栈的 “分层复杂性转移”：

传统架构的复杂性集中在应用层（如单体重构困难、环境配置混乱）
云原生的复杂性下沉到基础设施层（如 K8s 集群运维、Istio 配置）

对企业而言，这相当于用 “可控的工程复杂度” 替代 “不可控的业务阻塞风险”。但关键在于，这种转移是否真正带来净收益。

说白了，你要会“算账”，在成本一定的情况下，要有所取舍，到底要不要上“云原生”，不是技术本身决定的。

云原生有它的显性与隐性成本：

技术债务：K8s 版本升级兼容性问题、Helm Chart 维护
人力成本：需要 DevOps 工程师（平均薪资比开发高 30%+）
认知负担：团队需掌握容器、服务网格、声明式 API 等新范式
工具链成本：监控（Prometheus+AlertManager）、日志（EFK）、追踪（Jaeger）的集成和维护

有成本当然也有收益：

部署效率：从手动部署 1 小时 → 全自动 CI/CD 5 分钟（效率提升 12 倍）
资源利用率：虚拟机静态分配 → 容器动态调度（CPU 利用率从 15% 提升至 60%+）
故障恢复速度：人工排查 1 小时 → 自动熔断 + 滚动更新（MTTR 从 60 分钟降至 5 分钟）
业务敏捷性：新功能上线周期从 1 个月 → 1 周（迭代速度提升 4 倍）

所以，关键是要根据你的实际情况 “算账”，一般来说，当企业规模超过临界点（通常≥50 个微服务 / 日部署次数≥10 次），云原生的收益将显著超越成本。

结论

所以说了半天云原生到底是什么？我不知道你明白了没有，我们上面林林总总写了那么多技术点，如果初次接触确实很头大。但这不重要。

因为：云原生不是工具集，而是「工业化软件生产」的方法论升级

用制造业的思维来理解：

传统软件交付 ≈ 手工作坊（每个陶器需手工塑形、烧制）
云原生交付 ≈ 汽车生产线（标准化零件 + 自动化流水线 + 质量检测体系）

如果你面试的时候，面试官让你谈谈对云原生的理解，我希望你能够把这篇文章的精华吸收了，从一个比较高的层次来谈，我不希望给你一个中规中矩的回答模板，虽然它是正确的，比如以下这样：

“云原生是云计算时代的一种架构范式，旨在通过标准化技术栈（如容器、K8s）和自动化运维体系，将非业务功能（如弹性扩缩、故障自愈）从应用代码中剥离，由云平台接管。其核心驱动力是解决传统单体应用部署慢、环境不一致、扩展难的问题。

从技术分层看，云原生包含：

基础设施层：Docker 实现环境一致性，K8s 完成资源调度，比如我们通过 Deployment 的滚动更新实现零停机发布；

应用架构层：微服务拆分业务能力，Istio 服务网格处理服务间通信的熔断、监控，例如在订单服务中配置超时自动重试；

交付运维层：GitOps 工具链（如 Argo CD）确保声明式配置的版本可控，配合 Prometheus+Grafana 实现实时监控。

关键设计原则包括不可变基础设施（容器镜像一次构建多次运行）、声明式 API（通过 YAML 描述目标状态而非手动操作）。但引入云原生也带来挑战，比如团队需要掌握复杂的 K8s 生态，我们通过建设内部开发者平台（IDP）封装底层细节，让开发者只需关注业务代码。”

云原生应用

什么样的应用是云原生的？

一个应用是否云原生，而要看是否具备以下特征：

容器化部署：

应用打包为 Docker 镜像，在 Kubernetes 集群中运行。
示例：电商大促时，通过 HPA（水平扩缩）自动增加订单处理服务的 Pod 数量。

微服务架构：

业务拆分为独立服务（如用户服务、支付服务），通过 API 通信。
示例：视频网站将视频转码服务独立部署，利用 GPU 节点加速，不影响主站稳定性。

DevOps 流水线：

代码提交后自动触发 CI/CD，完成测试、镜像构建、灰度发布。
示例：金融 App 通过蓝绿部署实现零停机更新，降低发布风险。

依赖云原生中间件：

使用云托管的数据库（如 AWS RDS）、消息队列（如 Kafka on K8s）、缓存（如 Redis Cluster）。
示例：社交平台用云原生数据库 TiDB 处理海量关系数据，自动分片扩容。

跨云与混合云兼容：

应用设计不绑定特定云厂商，可在 AWS、Azure、私有云间迁移。
示例：跨国企业采用 Anthos 实现跨公有云和本地数据中心的统一管理。

最后

云原生不是终点，而是通往智能软件时代的必由之路。当我们将视角从工具本身移开，看到的是一场关于效率、可靠性与创新速度的认知革命。正如 Linux 之父 Linus Torvalds 所说：“技术终将老去，但优秀的架构思想永存。” 在这场变革中，比掌握某个工具更重要的，是建立持续进化的云原生思维体系。

容器编排工具的演进：从 Docker 到 Kubernetes

Sat, 10 Aug 2024 05:18:45 +0000

在现代应用部署中，Docker 和其他容器引擎为服务器端应用程序的部署提供了极大的便利。然而，随着应用和服务数量的增加，管理这些容器变得越来越困难。这催生了一类被称为容器编排器的工具，其中最为知名的莫过于 Kubernetes。容器编排的历史可以分为 Kubernetes 出现之前和之后两个阶段。

容器的便利与妥协

容器的使用虽然便利，但也带来了一些妥协。严格遵循 Docker 的理念，每个服务都应有其独立的容器，这将导致运行大量的容器。即使是一个简单的数据库网页界面，也可能需要分别运行数据库服务器、应用程序，以及可能包括用于处理静态文件的 Web 服务器、用于终止 SSL/TLS 连接的代理服务器、用作缓存的键值存储，甚至用于处理后台作业和计划任务的第二个应用程序容器。

负责多个此类应用程序的管理员很快就会意识到，需要一个工具来简化管理任务，这时容器编排工具应运而生。容器编排器可以将多个容器作为一个单元来管理，并将多个服务器结合成一个集群，自动分配容器工作负载到集群节点中。

Docker Compose 与 Swarm

Docker Compose 虽然不完全是一个编排器，但它是 Docker 首次尝试创建的工具，用于更轻松地管理由多个容器组成的应用程序。它使用 YAML 格式的文件，通常命名为docker-compose.yml。Compose 读取该文件，并使用 Docker API 创建所需的资源，同时为所有资源添加标签，以便在创建后作为一组进行管理。

Compose 文件中可以定义三种资源：

服务（services）： 包含要启动的容器声明。每个条目相当于一个docker run命令。
网络（networks）： 声明可以附加到容器的网络。每个条目相当于一个docker network create命令。
卷（volumes）： 定义可以附加到容器的命名卷。每个条目相当于一个docker volume create命令。

Compose 提供了一种更方便的方式来管理由多个容器组成的应用程序，但在其最初版本中，它仅支持单个主机；所有创建的容器都在同一台机器上运行。为了扩展到多个主机，Docker 在 2016 年引入了 Swarm 模式。这是 Docker 的第二个名为“Swarm”的产品，前一个产品于 2014 年推出，采用了完全不同的方法在多个主机上运行容器，但现在已不再维护。

Swarm 模式包含在 Docker 中，无需额外的软件即可使用。创建集群只需在初始节点上运行docker swarm init，然后在每个其他节点上运行docker swarm join。Swarm 集群包含两种类型的节点：管理节点和工作节点。管理节点提供 API 以在集群上启动容器，并使用基于 Raft 一致性算法的协议进行通信，以在所有管理节点之间同步集群状态。工作节点则负责运行容器。

通过 Compose 文件在 Swarm 上部署服务。Swarm 通过为每个服务添加一个deploy键扩展了 Compose 格式，该键指定服务应该运行的实例数量及其运行的节点。然而，这导致 Compose 和 Swarm 之间出现了一些分歧，某些选项如 CPU 和内存配额需要根据使用的工具以不同的方式指定。在此分歧期间，为 Swarm 准备的文件被称为“堆栈文件”而非 Compose 文件，幸好这些差异在当前版本的 Swarm 和 Compose 中已被平滑处理，Compose 格式现在有一个开放规范及其 GitHub 组织提供的参考实现。

关于 Swarm 的未来存在一些不确定性。它曾经是名为 Docker Cloud 的服务的骨干，但该服务在 2018 年突然关闭。它还被宣传为 Docker 企业版的关键特性，但该产品已售予另一家公司，现以 Mirantis Kubernetes Engine 的名义进行市场推广。同时，最新版本的 Compose 已经获得了将容器部署到 Amazon 和 Microsoft 托管服务的能力。虽然没有宣布弃用，但最近也没有任何其他类型的公告；在 Docker 网站上搜索“Swarm”一词，仅能找到一些提及。

Kubernetes

Kubernetes（有时称为 k8s）是受 Google 内部工具 Borg 启发的项目。Kubernetes 管理资源并协调在多达数千个节点的集群上运行工作负载；它在容器编排领域的统治地位如同 Google 在搜索领域的统治地位。Google 曾在 2014 年希望与 Docker 在 Kubernetes 开发上合作，但 Docker 决定走自己的路，发展 Swarm。相反，Kubernetes 在云原生计算基金会（CNCF）的支持下成长。到 2017 年，Kubernetes 的流行度已高到 Docker 宣布将其集成到 Docker 产品中。

Kubernetes 以其复杂性而闻名。手动设置一个新集群是一项繁杂的任务，除了 Kubernetes 本身外，管理员还需选择和配置若干第三方组件。就像 Linux 内核需要结合其他软件以构成完整的操作系统一样，Kubernetes 仅是一个编排器，需结合其他软件以构成完整的集群。它需要容器引擎来运行其容器，还需要网络和持久化卷的插件。

Kubernetes 发行版存在以填补这一空白。像 Linux 发行版一样，Kubernetes 发行版将 Kubernetes 与安装程序和精选的第三方组件捆绑在一起。不同的发行版存在以满足不同的需求；几乎每家规模一定的科技公司都有其自己的发行版和/或托管产品，以迎合企业需求。minikube 项目为开发者提供了一个更简便的本地实验环境。

Kubernetes 的组成结构

一个 Kubernetes 集群包含多个软件组件。集群中的每个节点都会运行一个称为 kubelet 的代理，以保持集群成员资格并接受来自集群的工作，容器引擎，以及用于启用与其他节点上运行的容器进行网络通信的 kube-proxy。

保持集群状态并对资源分配做出决策的组件被统称为控制平面，这包括一个分布式键值存储（etcd），一个将工作分配给集群节点的调度器，以及一个或多个控制器进程，这些进程对集群状态的变化做出反应，并触发任何必要的操作以使实际状态与所需状态相匹配。用户和集群节点通过 Kubernetes API 服务器与控制平面进行交互。为了实现变更，用户通过 API 服务器设置集群的期望状态，而 kubelet 将每个集群节点的实际状态报告给控制器进程。

Kubernetes 在一个称为 Pod 的抽象中运行容器，Pod 可以包含一个或多个容器，尽管不建议在一个 Pod 中运行多个服务的容器。相反，通常一个 Pod 会有一个提供服务的主容器，可能还有一个或多个“sidecar”容器，用于从主容器中运行的服务收集指标或日志。Pod 中的所有容器都会一起调度在同一台机器上，并共享一个网络命名空间——在同一个 Pod 中运行的容器可以通过回环接口互相通信。每个 Pod 在集群内都会收到一个唯一的 IP 地址。在不同 Pod 中运行的容器可以使用它们的集群 IP 地址相互通信。

一个 Pod 指定了一组要运行的容器，但 Pod 的定义并没有说明要在哪些地方运行这些容器，或运行多久——在没有这些信息的情况下，Kubernetes 会在集群中某处启动容器，但不会在它们退出时重新启动它们，并可能在控制平面决定其他工作负载需要它们使用的资源时突然终止它们。因此，Pod 很少单独使用；相反，Pod 的定义通常被封装在一个 Deployment 对象中，用于定义一个持久化服务。像 Compose 和 Swarm 一样，Kubernetes 管理的对象是在 YAML 中声明的；对于 Kubernetes，这些 YAML 声明通过 kubectl 工具提交到集群。

除了 Pod 和 Deployment，Kubernetes 还可以管理许多其他类型的对象，例如负载均衡器和授权策略。支持的 API 列表在不断演变，且会因运行的 Kubernetes 版本和集群运行的发行版而有所不同。自定义资源可以用来向集群添加 API 以管理其他类型的对象。例如，KubeVirt 增加了 API 以使 Kubernetes 能够运行虚拟机。可以使用 kubectl api-versions 命令发现特定集群支持的 API 的完整列表。

与 Compose 不同的是，每个对象是在一个单独的 YAML 文档中声明的，尽管可以通过在同一文件中用“—”分隔它们内联多个 YAML 文档，如 Kubernetes 文档中所示。一个复杂的应用程序可能由多个对象组成，其定义分布在多个文件中；在维护此类应用程序时保持所有这些定义同步可能相当繁琐。为了使这项工作更容易，一些 Kubernetes 管理员转向了模板工具如 Jsonnet。

Helm 与应用部署

Helm 进一步推进了模板化的方法。与 Kubernetes 一样，Helm 的开发在 CNCF 的支持下进行；它被誉为“Kubernetes 的包管理器”。Helm 从一组称为 chart 的模板和变量声明集合中生成 Kubernetes 的 YAML 配置。其模板语言与 Ansible 的 Jinja 模板不同，但看起来非常相似；熟悉 Ansible 角色的人可能会对 Helm 图表感到得心应手。

Helm 图表的集合可以在 Helm 存储库中发布；Artifact Hub 提供了一个公共 Helm 存储库的大型目录。管理员可以将这些存储库添加到他们的 Helm 配置中，并使用现成的 Helm 图表将预打包的流行应用程序版本部署到他们的集群。最近版本的 Helm 还支持将图表推送和拉取到容器注册表中，从而为管理员提供了将图表存储在与容器镜像相同位置的选项。

Kubernetes 在短期内没有失去势头的迹象。它被设计为可以管理任何类型的资源；这种灵活性，如通过 KubeVirt 虚拟机控制器所示，即使容器化工作负载最终失宠，它也有可能保持相关性。开发进展迅速，定期发布新版本。版本支持为期一年；似乎没有长期支持版本。支持集群升级，但一些人更愿意建立一个新集群并迁移他们的服务。

Nomad 的简单替代方案

Nomad 是 HashiCorp 推出的编排器，作为 Kubernetes 的简单替代方案进行营销。Nomad 是一个开源项目，像 Docker 和 Kubernetes 一样。它由一个名为 nomad 的二进制文件组成，可用于启动一个称为代理的守护程序，并作为 CLI 与代理进行通信。根据其配置方式，代理进程可以以两种模式之一运行。在服务器模式下运行的代理接受作业并为它们分配集群资源。在客户端模式下运行的代理与服务器联系以接收作业、运行它们，并向服务器报告其状态。代理还可以在开发模式下运行，在这种模式下，它同时承担客户端和服务器的角色，形成一个可用于测试目的的单节点集群。

创建一个 Nomad 集群可能相当简单。在 Nomad 的最基本操作模式下，必须启动初始服务器代理，然后可以使用 nomad server join 命令将其他节点添加到集群中。HashiCorp 还提供了 Consul，这是一种通用服务网格和发现工具。虽然可以单独使用，但 Nomad 与 Consul 结合使用时可能表现最佳。Nomad 代理可以使用 Consul 自动发现和加入集群，并且可以执行健康检查、提供 DNS 记录以及为集群上运行的服务提供 HTTPS 代理。

Nomad 支持复杂的集群拓扑。每个集群分为一个或多个“数据中心”。与 Swarm 类似，单个数据中心内的服务器代理使用一种基于 Raft 的协议进行通信；该协议具有严格的延迟要求，但多个数据中心可以使用一种允许信息在集群中传播的流言协议链接在一起，而无需每个服务器都与每个其他服务器保持直接连接。从用户的角度来看，以这种方式链接在一起的数据中心可以作为一个集群运作。这种架构在扩展到巨大的集群时为 Nomad 带来优势。Kubernetes 官方支持最多 5000 个节点和 300000 个容器，而 Nomad 的文档引用了包含超过 10000 个节点和 200 万个容器的集群示例。

与 Kubernetes 类似，Nomad 不包括容器引擎或运行时。它使用任务驱动程序来运行作业。使用 Docker 和 Podman 运行容器的任务驱动程序已包含在内；社区支持的驱动程序可用于其他容器引擎。同样与 Kubernetes 类似，Nomad 的野心不限于容器；还有其他类型工作负载的任务驱动程序，包括一个简单地在主机上运行命令的 fork/exec 驱动程序、用于运行虚拟机的 QEMU 驱动程序和用于启动 Java 应用程序的 Java 驱动程序。社区支持的任务驱动程序将 Nomad 连接到其他类型的工作负载。

与 Docker 或 Kubernetes 不同，Nomad 避开了 YAML，而是采用 HashiCorp 配置语言（HCL），该语言最初是为另一个 HashiCorp 项目 Terraform 创建的，用于云资源的配置。HCL 在 HashiCorp 产品线中使用广泛，尽管在其他地方采用有限。用 HCL 编写的文档可以轻松转换为 JSON，但其目标是提供比 JSON 更便于手指输入且比 YAML 更不易出错的语法。

HashiCorp 的 Helm 等效工具称为 Nomad Pack。像 Helm 一样，Nomad Pack 处理包含模板和变量声明的目录以生成作业配置。Nomad 还具有一个社区注册表，用于预打包应用程序，但可用选择远少于 Artifact Hub 的 Helm。

Nomad 没有 Kubernetes 那样的受欢迎程度。像 Swarm 一样，其开发似乎主要由其创建者推动；虽然它已被许多大公司部署，但 HashiCorp 仍然是 Nomad 社区的中心。此时，项目似乎不太可能获得足够的动力以独立于其企业母公司存在。用户或许可以从 HashiCorp 更明确地致力于 Nomad 的开发和推广中找到一些保证，这与 Docker 对 Swarm 的承诺形成鲜明对比。

结论

Swarm、Kubernetes 和 Nomad 并不是唯一的容器编排器，但它们是三个最具生命力的工具。Apache Mesos 也可以用于运行容器，但在 2021 年几乎被搁置；基于 Mesos 的 DC/OS 也面临类似的情况，支持其发展的社区和商业实体正在寻找新的方向。尽管如此，Swarm、Kubernetes 和 Nomad 仍然是当前市场上最受欢迎和最活跃的容器编排解决方案，它们各自提供了不同的功能和优势，以满足不同规模和需求的企业。随着技术的不断进步和市场的变化，这些工具将继续演化，以适应未来的挑战和机遇。

一文弄懂 Spring WebFlux 的来龙去脉

Mon, 29 Aug 2022 10:31:50 +0000

概述

本文将通过对 Reactive 以及相关概念的解释引出 Spring-WebFlux，并通过一些示例向读者解释基于 Spring-WebFlux 如何进行反应式编程实践，同时会讨论相关技术的优缺点及技术原理。

什么是 Reactive

在计算机编程领域，Reactive 一般指的是 Reactive programming。指的是一种面向数据流并传播事件的异步编程范式（asynchronous programming paradigm）

响应式编程最初是为了简化交互式用户界面的创建和实时系统动画的绘制而提出来的一种方法，但它本质上是一种通用的编程范式。

举个例子

“

在 Excel 里，C 单元格上设置函数 Sum(A+B)，当你改变单元格 A 或者单元格 B 的数值时，单元格 C 的值同时也会发生变化。这种行为就是 Reactive

”

下面的例子我们用了 https://projectreactor.io/ 的 reactor 库，通过这个例子找找感觉：

1 FluxProcessor<Integer, Integer> publisher = UnicastProcessor.create();
2 publisher.doOnNext(event -> System.out.println("receive event: " + event)).subscribe();
3 publisher.onNext(1);
4 publisher.onNext(2);
5 
6 // 输出
7 // receive event: 1
8 // receive event: 2

追根溯源，说到 Reactive ，就不得不提到大名鼎鼎的响应式宣言/The Reactive Manifesto（https://www.reactivemanifesto.org），它于 2014 年发表，响应式宣言是一份构建现代云扩展架构的处方。

“

We believe that a coherent approach to systems architecture is needed, and we believe that all necessary aspects are already recognised individually: we want systems that are Responsive, Resilient, Elastic and Message Driven. We call these Reactive Systems.

”

这个框架主要使用消息驱动的方法来构建系统，在形式上可以达到弹性和韧性，最后可以产生响应性的价值。

所谓弹性和韧性，通俗来说就像是橡皮筋，弹性是指橡皮筋可以拉长，而韧性指在拉长后可以缩回原样。

解释下上面的关键词：

响应性 快速/一致的响应时间。假设在有 500 个并发操作时，响应时间为 1s，那么并发操作增长至 5 万时，响应时间也应控制在 1s 左右。快速一致的响应时间才能给予用户信心，是系统设计的追求。
韧性复制/遏制/隔绝/委托。当某个模块出现问题时，需要将这个问题控制在一定范围内，这便需要使用隔绝的技术，避免连锁性问题的发生。或是将出现故障部分的任务委托给其他模块。韧性主要是系统对错误的容忍。
弹性无竞争点或中心瓶颈/分片/扩展。如果没有状态的话，就进行水平扩展，如果存在状态，就使用分片技术，将数据分至不同的机器上。
消息驱动 异步/松耦合/隔绝/地址透明/错误作为消息/背压/无阻塞。消息驱动是实现上述三项的技术支撑。
地址透明有很多方法。例如 DNS 提供的一串人类能读懂的地址，而不是 IP，这是一种不依赖于实现，而依赖于声明的设计。再例如 k8s 每个 service 后会有多个 Pod，依赖一个虚拟的服务而不是某一个真实的实例，从何实现调用 1 个或调用 n 个服务实例对于对调用方无感知，这是为分片或扩展做了准备。
错误作为消息，这在 Java 中是不太常见的，Java 中通常将错误直接作为异常抛出，而在响应式中，错误也是一种消息，和普通消息地位一致，这和 JavaScript 中的 Promise 类似。
背压是指当上游向下游推送数据时，可能下游承受能力不足导致问题，一个经典的比喻是就像用消防水龙头解渴。因此下游需要向上游声明每次只能接受大约多少量的数据，当接受完毕再次向上游申请数据传输。这便转换成是下游向上游申请数据，而不是上游向下游推送数据。
无阻塞是通过 no-blocking IO 提供更高的多线程切换效率。

Reactive Programming

响应式编程是一种声明式编程范型

 1 int a, b, sum;
 2
 3 a = 3;
 4 b = 4;
 5 sum = a + b;
 6
 7 a = 6;
 8 b = 7;
 9
10 System.out.println(sum);

上面是一个命令式编程的例子，先声明两个变量，然后进行赋值，让两个变量相加，得到相加的结果。但接着当修改了最早声明的两个变量的值后，sum 的值不会因此产生变化。

在 Java 9 Flow 中，按相同的思路实现上述处理流程，当初始变量的值变化，最后结果的值也同步发生变化，这就是响应式编程。这相当于声明了一个公式，输出值会随着输入值而同步变化。

 1 SubmissionPublisher<Integer> publisher = new SubmissionPublisher<>();
 2 publisher.subscribe(new Flow.Subscriber<Integer>() {
 3 private Integer sum = 0;
 4 Flow.Subscription subscription = null;
 5
 6 @Override
 7 public void onSubscribe(Flow.Subscription subscription) {
 8
 9 this.subscription = subscription;
10 subscription.request(1);
11 }
12
13 @Override
14 public void onNext(Integer item) {
15 subscription.request(1);
16 sum += item;
17
18 }
19
20 @Override
21 public void onError(Throwable throwable) {
22
23 }
24
25 @Override
26 public void onComplete() {
27 System.out.println(sum);
28 }
29
30 });
31
32 Arrays.asList(3, 4).stream().forEach(publisher::submit);
33 publisher.close();

之前有提及消息驱动，消息驱动（Message-driven）和事件驱动（Event-driven）有什么区别呢。

1）消息驱动有确定的目标，一定会有消息的接受者，而事件驱动是一件事情希望被观察到，观察者是谁无关紧要。消息驱动系统关注消息的接受者，事件驱动系统关注事件源。

2）在一个使用响应式编程实现的响应式系统中，消息擅长于通讯，事件擅长于反应事实。

Reactive Streams

Reactive Streams(https://www.reactive-streams.org) 提供了一套非阻塞背压的异步流处理标准，主要应用在 JVM、JavaScript 和网络协议工作中。通俗来说，它定义了一套响应式编程的标准。

有了标准，各 Reactor 库的厂商就有了规范，不再各自为战，并且对于上层应用开发者来说可以根据自己的需要选择同一个规范下的各种不同实现库。

“

The purpose of Reactive Streams is to provide a standard for asynchronous stream processing with non-blocking backpressure.

”

在 Java 中，有 4 个 Reactive Streams API，在 JUC 的 Flow 类中可以看到：

Publisher 即事件的发生源，它只有一个 subscribe 方法。其中的 Subscriber 就是订阅消息的对象。
Subscriber 作为订阅者，有四个方法。onSubscribe 会在每次接收消息时调用，得到的数据都会经过 onNext 方法。onError 方法会在出现问题时调用，Throwable 即是出现的错误消息。在结束时调用 onComplete 方法。
Subscription 接口用来描述每个订阅的消息。request 方法用来向上游索要指定个数的消息，cancel 方法用于取消上游的数据推送，不再接受消息。
Processor 接口继承了 Subscriber 和 Publisher，它既是消息的发生者也是消息的订阅者。这是发生者和订阅者间的过渡桥梁，负责一些中间转换的处理。

Thinking in Streams

反应式流所带来的编程思维模式的改变是转为以流为中心。这是从以逻辑为中心到以数据为中心的转换，也是命令式到声明式的转换。

传统的命令式编程范式以控制流为核心，通过顺序、分支和循环三种控制结构来完成不同的行为。开发人员在程序中编写的是执行的步骤
以数据为中心侧重的是数据在不同组件的流动。开发人员在程序中编写的是对数据变化的声明式反应。

Reactor 库

Reactor Library 从开始到现在已经历经多代。早期如 java.util.Observable 、 rx.NET 、 Reactive4Java ，后来的 Rxjava 、Akka-Streams以及 Project Reactor。

RxJava 对于开发 Android 应用的同学应该不陌生，比较常用，这种比较著名的库发展了好几个大版本，比如 RxJava1 RxJava2 和 RxJava3
Project Reactor（Spring 母公司 Pivotal 的项目），实现了完全非阻塞，并且基于网络 HTTP/TCP/UDP 等的背压，即数据传输上游为网络层协议时，通过远程调用也可以实现背压。同时，它还实现了 Reactive Streams API 和 Reactive Extensions，以及支持 Java 8 functional API/Completable Future/Stream /Duration 等各新特性。它也是 Spring 官方反应式编程的默认实现。

从 Reactive 宣言、到 Reactive Streams 规范，再到各种 Reactive 库是很自然的一个脉络，但现实的顺序是：

先有了宣言（思想）
然后有了根据思想开发的各种库（实现）
为了各个库之间的统一性、可操作性，大家一起协商出了 Reactive Streams 规范。继而这些已经存在的 Reactive 库便改进自己的 API 设计，向 Reactive Streams 规范靠拢并提供各种转化 API 让用户在原生 API 和 Reactive Streams 接口直接转换。

来看个例子：

 1 List<String> words = Arrays.asList(
 2 "the", "quick", "brown", "fox",
 3 "jumped", "over", "the", "lazy", "dog");
 4 Flux.fromIterable(words)
 5 .flatMap(word -> Flux.fromArray(word.split("")))
 6 .concatWith(Mono.just("s")).distinct().sort()
 7 .zipWith(Flux.range(1, Integer.MAX_VALUE),
 8 (string, count) ->
 9 String.format("%2d. %s", count, string)
10 )
11 .subscribe(System.out::println);

首先定义了一个 words 的数组，然后使用 flatMap 做映射，再将每个词和 s 做连接，得出的结果和另一个等长的序列进行一个 zipWith 操作，最后打印结果。这和 Java 8 Stream 非常类似，但仍存在一些区别：

1） Stream 是 pull-based，下游从上游拉数据的过程，它会有中间操作例如 map 和 reduce，和终止操作例如 collect 等，只有在终止操作时才会真正的拉取数据。Reactive 是 push-based，可以先将整个处理数据量构造完成，然后向其中填充数据，在出口处可以取出转换结果。

2） Stream 只能使用一次，因为它是 pull-based 操作，拉取一次之后源头不能更改。但 Reactive 可以使用多次，因为 push-based 操作像是一个数据加工厂，只要填充数据就可以一直产出。

3） Stream#parallel() 使用 fork-join 并发，就是将每一个大任务一直拆分至指定大小颗粒的小任务，每个小任务可以在不同的线程中执行，这种多线程模型符合了它的多核特性。Reactive 使用 Event loop，用一个单线程不停的做循环，每个循环处理有限的数据直至处理完成。

这里有个网站，一共 12 节，每一节都有讲解和代码示例，是基于 Reactor 3 的，可以用来练习 Reactive Programing :https://tech.io/playgrounds/929/reactive-programming-with-reactor-3/Intro

Backpressure

上面我们提到了 BackPressure，即背压或回压。Backpressure 是一种现象：当数据流从上游生产者向下游消费者传输的过程中，上游生产速度大于下游消费速度，导致下游的 Buffer 溢出，这种现象就叫做 Backpressure。

上游生产数据，生产完成后通过管道将数据传到下游，下游消费数据，当下游消费速度小于上游数据生产速度时，数据在管道中积压会对上游形成一个压力，这就是 BackpressureBackpressure 会出现在有 Buffer 上限的系统中，当出现 Buffer 溢出的时候，就会有 Backpressure，对于 Backpressure，它的应对措施只有一个：丢弃新事件。那么什么是 Buffer 溢出呢？例如我的服务器可以同时处理 2000 个用户请求，那么我就把请求上限设置为 2000，这个 2000 就是我的 Buffer，当超出 2000 的时候，就产生了 Backpressure。

Backpressure 问题在 Flow API 中得到了很好的解决。

Subscriber 会将 Publisher 发布的数据缓存在 Subscription 中，其长度默认为 256，一旦超出这个数据量，publisher 就会降低数据发送速度。通过一个例子了解一下：

 1 public static void backPressureTest() {
 2
 3 SubmissionPublisher<String> publisher = new SubmissionPublisher<>();
 4
 5 Flow.Subscriber<String> subscriber = new Flow.Subscriber<String>() {
 6 private Flow.Subscription subscription;
 7
 8 @Override
 9 public void onSubscribe(Flow.Subscription subscription) {
10 this.subscription = subscription;
11 //向数据发布者请求一个数据
12 this.subscription.request(1);
13 }
14
15 @Override
16 public void onNext(String item) {
17 System.out.println("接收到 publisher 发来的消息了：" + item);
18 try {
19 Thread.sleep(2000);
20 } catch (InterruptedException e) {
21 e.printStackTrace();
22 }
23 this.subscription.request(1);
24 }
25
26 @Override
27 public void onError(Throwable throwable) {
28 //出现异常，就会来到这个方法，此时直接取消订阅即可
29 this.subscription.cancel();
30 }
31
32 @Override
33 public void onComplete() {
34 //发布者的所有数据都被接收，并且发布者已经关闭
35 System.out.println("数据接收完毕");
36 }
37 };
38 publisher.subscribe(subscriber);
39 for (int i = 0; i < 500; i++) {
40 System.out.println("i--------->" + i);
41 publisher.submit("hello:" + i);
42 }
43 //关闭发布者
44 publisher.close();
45 }

这里我们发布 500 条数据，由于 Flow 的缓存大小是 256 ，所以前 256 条数据很快就生产出来进入缓存队列了：

1static final int DEFAULT_BUFFER_SIZE = 256;

由于消费的比较慢（我们手动 Sleep 了 2 秒） this.subscription.request(1) 只能一条一条消费，所以效果就是一条一条消费，消费一条，生产一条。

最好自己在本地跑一下代码，感受一下 backpressure

R2DBC

Reactive 本来不支持 JDBC。最根本的原因是，JDBC 不是 non-blocking 设计。不过这个事情也正在推进和发展过程中，比如 r2dbc ( https://r2dbc.io/) 项目。

R2DBC 是 Reactive Relational Database Connectivity 的首字母缩写词。 R2DBC 是一个 API 规范倡议，它声明了一个响应式 API，由驱动程序供应商实现，并以响应式编程的方式访问他们的关系数据库。

R2DBC基于Reactive Streams反应流规范，它是一个开放的规范，为驱动程序供应商和使用方提供接口（r2dbc-spi），与JDBC的阻塞特性不同，它提供了完全反应式的非阻塞API与 [关系型数据库] 交互。

目前 R2DBC 支持的数据库如下：

cloud-spanner-r2dbc - driver for Google Cloud Spanner.
jasync-sql - R2DBC wrapper for Java & Kotlin Async Database Driver for MySQL and PostgreSQL (written in Kotlin).
oracle-r2dbc - native driver implemented for Oracle.
r2dbc-h2 - native driver implemented for H2 as a test database.
r2dbc-mariadb - native driver implemented for MariaDB.
r2dbc-mssql - native driver implemented for Microsoft SQL Server.
r2dbc-mysql - native driver implemented for MySQL.
r2dbc-postgresql - native driver implemented for PostgreSQL.

很多同学可能会关心事务的事儿，R2DBC 也是支持事务的

什么是 Spring-WebFlux

相信有了前文对 Reactive 的铺垫，了解 Spring-WebFlux 会比较容易了。

Spring 5.0 添加了 Spring-WebFlux 模块将默认的 web 服务器改为 Netty，支持 Reactive 应用，它的特点是：

完全非阻塞式的（non-blocking）
支持 Reactive Stream 背压（Reactive Streams back pressure）
运行在 Netty, Undertow, and Servlet 3.1+ 容器

对比 Spring MVC

Spring MVC 构建于 Servlet API 之上，使用的是同步阻塞式 I/O 模型，什么是同步阻塞式 I/O 模型呢？就是说，每一个请求对应一个线程去处理。

Spring WebFlux 是一个异步非阻塞式 IO 模型，通过少量的容器线程就可以支撑大量的并发访问，所以 Spring WebFlux 可以有效提升系统的吞吐量和伸缩性，特别是在一些 IO 密集型应用中，Spring WebFlux 的优势明显。例如微服务网关 Spring Cloud Gateway 就使用了 WebFlux，这样可以有效提升网管对下游服务的吞吐量。

Spring WebFlux 与 Spring MVC 的关系如下图

可见，Spring WebFlux 并不是为了替代 Spring MVC 的，它与 Spring MVC 一起形成了两套 WEB 框架。两套框架有交集比如对 @Controller 注解的使用，以及均可使用 Tomcat、Jetty、Undertow 作为 Web 容器。

Spring MVC 还是 WebFlux？

针对这个问题，官方认为两者并不是二元对立的，他们可以并排使用，两者一起工作以扩大可用选项的范围。

我们来看看官方给的具体建议：

如果已经有了一个运行良好的 SpringMVC 应用程序，则无需更改。命令式编程是编写、理解和调试代码的最简单方法，我们可以选择最多的库，因为从历史上看，大多数都是阻塞的。
如果是个新应用且决定使用非阻塞 Web 技术栈，那么 WebFlux 是个不错的选择。
对于使用 Java8 Lambda 或者 Kotlin 且要求不那么复杂的小型应用程序或微服务来说，WebFlux 也是一个不错的选择
在微服务架构中，可以混合使用 SpringMVC 和 Spring WebFlux，两个都支持基于注解的编程模型
评估应用程序的一种简单方法是检查其依赖关系。如果要使用阻塞持久性 API（JPA、JDBC）或网络 API，那么 Spring MVC 至少是常见架构的最佳选择
如果有一个调用远程服务的 Spring MVC 应用程序，请尝试响应式WebClient
对于一个大型团队，向非阻塞、函数式和声明式编程转变的学习曲线是陡峭的。在没有全局开关的情况下，想启动 WebFlux，可以先使用 reactive WebClient。此外，从小处着手并衡量收益。我们预计，对于广泛的应用，这种转变是不必要的。

这里最后一点的意思是要仔细通过技术原理（非阻塞 IO、并发性能、吞吐量..）来评估 WebFlux 究竟能为我们带来多少益处，同时评估为了获得这些好处所要付出的学习和改造成本，然后衡量收益，如果收益大值得一试，否则不建议动。

个人认为对于日常用 SpringMVC 开发的业务应用不用换 Spring-WebFlux，因为 SpringMVC 是同步阻塞式模型，对于应用的开发、调试、测试都比较友好，反过来这些点在非阻塞模型的 WebFlux 中就变成了缺点。

为什么要用 WebFlux

为什么要用 WebFlux ？或者换句话说 WebFlux 有什么优点？

首先是吞吐量

随着每个请求的被处理时间越长、并发请求的量级越大，WebFlux 相比 SpringMVC 的整体吞吐量高的越多，平均的请求响应时间越短。如下图所示

吞吐量大了，意味着单位时间内可以处理的请求数变多了，比如原来 1w 个请求 10 秒处理完，现在 10w 个请求也是 10 秒处理完，就代表吞吐上去了。注意，是吞吐上去了，不代表单次请求快了，单次请求的速度和原来一样。

非阻塞

传统阻塞 IO 模型的不足包括

每个连接都需要独立线程处理，当并发数大时，创建线程数多，占用资源
采用阻塞 IO 模型，连接建立后，若当前线程没有数据可读，线程会阻塞在读操作上，造成资源浪费

针对传统阻塞 IO 模型的两个问题，可以采用如下的方案

基于池化思想，避免为每个连接创建线程，连接完成后将业务处理交给线程池处理
基于 IO 复用模型，多个连接共用同一个阻塞对象，不用等待所有的连接。遍历到有新数据可以处理时，操作系统会通知程序，线程跳出阻塞状态，进行业务逻辑处理

Netty 所用的 Reactor 线程模型，就解决了阻塞 IO 的问题，具体来讲，它使用的是主从 Reactor 多线程模型

同时 Netty 自身也很好地利用了 IO 多路复用、epoll 优化、零拷贝等技术，极大程度上优化了 IO 的性能。我们知道 SpringWebFlux 底层也依赖了 Netty ，所以也获得了 Netty 带来的优势。这一点可以概括为应用的弹性或伸缩性。根据实际请求量的大小进行资源的伸缩。

Mono Flux

前提：这里的例子使用的框架是 SpringBoot ，版本为 2.3.12.RELEASE 相应的 Spring 的大版本是 5，JDK 11

我们用两个最简单的例子，演示下用 Spring WebFlux 怎么写 Web 的 controller

当然首先要添加相关依赖

 1<dependency>
 2 <groupId>org.springframework.boot</groupId>
 3 <artifactId>spring-boot-starter-webflux</artifactId>
 4</dependency>
 5
 6@RestController
 7@RequestMapping("/webflux")
 8public class HelloController {
 9
10 @GetMapping("/hello")
11 public Mono<String> hello() {
12 return Mono.just("Hello Spring Webflux");
13 }
14 
15}
16
17> curl http://localhost:8080/webflux/hello
18Hello Spring Webflux

我们再来一个返回对象列表的例子：

 1 @GetMapping("/posts")
 2 public Flux<Post> posts() {
 3
 4 WebClient webClient = WebClient.create();
 5 Flux<Post> postFlux = webClient.get().uri("http://jsonplaceholder.typicode.com/posts").retrieve().bodyToFlux(Post.class);
 6
 7 return postFlux;
 8 }
 9
10@NoArgsConstructor
11@Data
12public class Post {
13
14 private Integer userId;
15 private Integer id;
16 private String title;
17 private String body;
18
19}

浏览器请求 http://localhost:8080/webflux/posts ，得到

解释一下这个例子，WebClient 是 Spring5 以后提供的，可以替代 RestTemplate，我们利用 WebClient 请求 jsonplaceholder 提供的 json 对象数组，将返回的结果映射成为 Post 对象，然后直接将 Post 对象列表返回给客户端。

有关 WebClient 的具体 API 这里先不做过多解释，我们看一下 Mono 和 Flux 这两个陌生的类。在 WebFlux 中他们均能充当响应式编程中发布者的角色，不同的是：

Mono：返回 0 或 1 个元素，即单个对象。
Flux：返回 N 个元素，即 List 列表对象。

此外，在应用启动后，通过 IDEA 的控制台可以明显看到 Server 已经不是 Tomcat 了，而是 Netty

如果你没有看到 Netty 还是 Tomcat 的话，可能是你的pom.xml 中同时包含了以下两个依赖：

1 <dependency>
2 <groupId>org.springframework.boot</groupId>
3 <artifactId>spring-boot-starter-web</artifactId>
4 </dependency>
5
6 <dependency>
7 <groupId>org.springframework.boot</groupId>
8 <artifactId>spring-boot-starter-webflux</artifactId>
9 </dependency>

解决的方案是去掉 spring-boot-starter-web 依赖，这样 Server 就切换到了 Netty。

Stream

既然叫 Reactive Stream 我们就用下面一个例子找一找流的感觉：

 1@GetMapping(value = "/flux", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
 2public Flux<String> flux() {
 3 Flux<String> flux = Flux.fromArray(new String[]{"a", "b", "c", "d"}).map(s -> {
 4 try {
 5 Thread.sleep(1000);
 6 } catch (InterruptedException e) {
 7 e.printStackTrace();
 8 }
 9 return "<letter:" + s + ">";
10 });
11 return flux;
12}

看下效果：

浏览器每隔一秒显示下一条数据，这正是流的效果，是不是有点儿像 WebSocket ？其实并不完全一样。奥妙在这里 text/event-stream，这其实也是服务器向浏览器推送消息的一种方案。感兴趣的同学可以搜索一下 WebSocket 和 SSE 的区别。

请求分发

Spring MVC 的前端控制器是 DispatcherServlet, 而 WebFlux 是 DispatcherHandler，它实现了 WebHandler 接口，主要看 handle 方法

DB

有文章说，WebFlux 还不支持 MySQL ，可能是文章发布的较早，当时 R2DBC 没来得及支持那么多的数据库，只支持了 MongoDB 和 PostgreSQL 等几个。现在这个时间点 R2DBC 支持的数据库就比较多了，也包含了 MySQL（参数上文）

Spring Data R2DBC 可以与 Spring Data JPA 结合使用，其实 R2DBC 与原来的 JPA 使用方式差别不大，使用非常简单。只是 Spring Data JPA 中方法返回的是真实的值，而 R2DBC 中，返回的是数据流Mono，Flux。

更多 R2DBC 的介绍，可以参考 Spring 的官方文档：https://docs.spring.io/spring-data/r2dbc/docs/1.3.2/reference/html/#r2dbc.core

有兴趣的同学可以用 Spring WebFlux + R2DBC+MySQL ，实现一下 CRUD 操作。就是一个从头到尾彻彻底底的响应式非阻塞应用。

WebClient

Spring 5 引入了新的 WebClientAPI，取代了现有的 RestTemplate 客户端。使用 WebClient 您可以使用功能流畅的 API 发出同步或异步 HTTP 请求，该 API 可以直接集成到您现有的 Spring 配置和 WebFlux 反应式框架中。

一个例子：

 1 private static void testWebClient() {
 2
 3 WebClient webClient = WebClient.create();
 4 monoTest(webClient, "http://jsonplaceholder.typicode.com/posts/1");
 5
 6 }
 7 /**
 8 * 从 API 获取单个帖子
 9 */
10 private static void monoTest(WebClient webClient, String uri) {
11 //要注意此时实际上还没有发送任何请求！作为一个反应式 API，在某些尝试读取或等待响应之前，不会实际发送请求。
12 Mono<Post> postMono = webClient.get().uri(uri).retrieve().bodyToMono(Post.class);
13 Post post1 = postMono.blockOptional().get();
14 log.info(post1.getTitle());
15
16 }

上面的是 Mono 的，再来一个 Flux 的（获得 post list 并将 id 求和）：

 1/**
 2 * 获取 post 列表 ，使用 Flux 因为是多值 , 要是获取一个对象比如 `posts/1` 就可以用 Mono
 3 *
 4 * @param webClient
 5 * @param uri
 6 */
 7private static void fluxTest(WebClient webClient, String uri) {
 8 
 9 // retrieve() 方法是获取响应主体并对其进行解码
10 Flux<Post> postFlux = webClient.get().uri(uri).retrieve().bodyToFlux(Post.class);
11 List<Post> posts = postFlux.collectList().block();
12 Integer idSum = posts.stream().mapToInt(post -> post.getId()).reduce(0, (a, b) -> a + b);
13 log.info(idSum);
14}

总结

Reactive Programming 作为观察者模式（Observer）的延伸，不同于传统的命令编程方式（ Imperative programming）同步拉取数据的方式，如迭代器模式（Iterator）。而是采用数据发布者同步或异步地推送到数据流（Data Streams）的方案。

当该数据流（Data Steams）订阅者监听到传播变化时，立即作出响应动作。在实现层面上，Reactive Programming 可结合函数式编程简化面向对象语言语法的臃肿性，屏蔽并发实现的复杂细节，提供数据流的有序操作，从而达到提升代码的可读性，以及减少 Bugs 出现的目的。同时，Reactive Programming 结合背压（Backpressure）的技术解决发布端生成数据的速率高于订阅端消费的问题。

如果说 Spring Cloud 是从【宏观系统层面的开发】角度在实践健壮的高可用系统+系统运维，K8S 在【DEV OPS】层面实践更好的系统运维，Service Mesh 在【基础设施层（infra）】实践健壮的高可用系统+系统运维，那么 WebFlux（包括整个 Reactive Stack 体系的其他成员）就是从【微观项目层面的开发】角度在实践健壮的高可用系统+系统运维。或多或少，它们都从各个维度在朝着“更少的人治”角度去努力。

GitHub 地址

代码示例我放到了 github 上：https://github.com/xiaobox/Spring-WebFlux-Demo

参考

Make Jar, Not War.

Tue, 05 Jul 2022 09:51:29 +0000

大约在 4 年前，关于 java 应用最终打成 jar 包还是 war 包的选择令我比较疑惑。

那时候更多的应用是打成 war 包的，即使我们知道可以打成 jar 包，但之前都是打成 war 包，并且好像打成 jar 包并没有什么特别明显的好处。

但当时令我困惑的是越来越多的实践正在不怎么说明理由的情况下转而打 jar 包，于是我开始思考……

war 包的理由

在某大型 OTA 企业内部，应用仍然打成 war 包, PaaS 平台会自动安装并配置好 tomcat，我知道这对于 web server 的统一配置和运维来说是有好处的。基于 war 背后的一系列 CI/CD 、DevOps 流程都一定有相应的适配，且就算 jar 包有我不知道的某些优势也不可能一夜之间在大型企业内部使用，需要平台和系统做出调整。

SpringBoot 在当时并未像现在这样流行，这并不意味着大家不用它，我的意思是相对新的项目来说，企业内部会有非常多 “老系统” 需要维护，我们不能指望一下子把这些老系统都用新的技术栈替换掉，就像你知道现在 web application 一般是前后端分离开发，但如果接手一个使用 jsp 的老家伙，你还得维护不是？

jar 的时代

时代不同了，说得好像过了几十年的样子，但其实也就几年光阴而已。不过仅仅是这几年的光阴却足以改变一些事情的面貌。

如今，云原生、微服务大行其道，大家好像已经非常适应这种开发模式，没有人纠结要不要用 SpringBoot，只会讨论使用的版本高还是低。更不用说打包的事情，很自然的会使用 jar,虽然这种看起来的 “最佳实践”，在长期开发的过程中会形成 “肌肉记忆”，但我们还是要讨论一下为什么。

方便

可运行 Jar 是打包自包含可运行应用程序的便捷方法。这样，我们可以最大限度地减少依赖关系。可以通过 Spring boot Maven 和 Gradle plugin 来管理依赖。

云原生友好

在自备容器的情况下（docker,k8s), jar 包可以直接作为一个 single application 来管理。

在过去我们使用 war 是为了让多应用共享 web server，现在是容器的天下，在容器内，一般情况只跑一个应用进程。由于只有一个进程，我们就可以轻松地管理它，比如重启（不会影响其他的应用，因为没有其他应用）。

版本控制

利用 git 等版本控制软件，可以控制程序运行所需要的一切（比如配置文件）

易于扩展

例如，将其复制到另一台服务器，然后“ just run it!” 无需安装和/或配置容器

参考

https://medium.com/@satyajit.nalavade/make-jar-not-war-josh-long-d6ce5fbb8a23

动态清零？这不就是GC吗

Mon, 09 May 2022 10:56:47 +0000

GC(垃圾回收)的原因是：总会有垃圾出现需要回收，释放内存。

动态清零的原因是：总有感染者出现，需要控制。

目前看来，动态清零用的方法是 Mark-Sweep，即标记（核酸）-清理（方舱）

类比垃圾回收器有点儿像 CMS，但由于内部网格化管理实际上更像G1 这种分区回收的垃圾回收器，比如上海。

我们都知道无论是CMS还是G1都会有STW（stop the world），垃圾回收器们一般都是在高吞吐和低延迟之间做权衡。没有最好，只有最合适。

然而动态清零看起来却不是，这是个区别，它有着明显的停顿（STW），又有着比较低的吞吐。希望能够在算法上进行优化，我们的特点是内存大（人口基数大），是不是可以借鉴ZGC，ZGC 和 G1 一样是基于 reigon 的，几乎所有阶段都是并发的，整堆扫描，部分收集。它的停顿时间也明显优于G1和CMS。

目前来看北京的模式有点儿像ZGC 的特点，整堆扫描（核酸），部分收集（封控）。

另外从隔离性上讲，上海类似 docker，把自己整体容器化，资源隔离了，北京类似K8S的 Pod，对外还能保证可用性，只不过部分Pod 可能会出现问题，那就解决Pod的问题就好了。只要不全挂，因为没有冗余设备（也不可能有）。

看来动态清零是一个长期的事儿了，就像GC虽然程序员不需要时刻注意垃圾回收的问题，但它一直在后台默默运行着，帮我们解决着内存回收的问题。希望动态清零也能够优化到“静默”运行，在高吞吐和低延迟间做好 trade off。

我们能够接受和它长期并存，现实世界不是程序，希望它能够少些 STW，祝所有“容器化”的朋友们好运，宿主机会好的，等待你们重启的那一天。祝所有人平安、健康。

Kubernetes on 小盒子的技术分享

拒绝内卷！为什么我们应该抵制用 LeetCode 考查真实的工程师？

拒绝内卷！为什么我们应该抵制用 LeetCode 考查真实的工程师？

一、 真实的工程世界，从来不是一道“闭卷考试”

二、 刷题面试，正在惩罚真正有经验的“老兵”

三、 算法题面试的本质：一场低效的“智商服从性测试”

四、 如何打破僵局：回归工程本质的面试方法

五、 结语：放过工程师，也放过企业自己

AI 模型推理平台架构设计与实践

一、背景

为什么要搞推理平台

为什么要自己部署、运行、维护模型呢？ 全部用 API 不行吗？

一定要有 GPU （显卡资源）吗？

二、资源规划与集群架构

不止 k8s

KServe

KServe 架构

vLLM 和 Triton

三、部署思路

架构

1. 整体链路是谁在做自动扩缩容？

2. enable-scale-to-zero: “true” 的含义是什么？

3. 单模型 多 Pod ，如何占多机多卡？

面临的问题

解决办法

共享 GPU 技术

请求流 & 监控流（两条主链路）

推理请求链路（从客户端到 vLLM）

监控链路（业务 + GPU）

四、环境搭建步骤

需要安装的软件、版本及顺序

安装步骤 SOP

第 0 步：准备工作

第 1 步：安装 NVIDIA GPU Operator (v24.9.1)

第 2 步：安装 Kube-Prometheus-Stack (v61.9.0)

第 3 步：安装 Cert-Manager (v1.15.3)

第 4 步：安装 Istio (v1.22.6)

第 5 步：安装 Knative Serving & Net-Istio (v1.15.1)

第 6 步：安装 KServe (v0.14.1)

第 7 步：配置 vLLM Runtime (关键)

第 8 步：为 GPU 调度开启 Knative 的 nodeSelector / tolerations

第 9 步：Istio Sidecar 注入策略（避免影响 GPU Operator 和监控）

第 10 步：安装 MinIO（可选）

第 11 步：安装 Loki 和 Promtail

最终验证

验证 GPU Operator & GPU metrics 是否正常

轻量级测试

完整测试（triton + vllm）

六、基于 Argo 的 CI / CD

Argo 跟 Kubernetes 是什么关系？

部署层级

实践

实操 for Triton（预演）

实操 for vLLM（预演）

七、如何衡量平台是否成功？

维度一：性能与延迟 (Performance & Latency) - “我们的服务快不快？”

维度二：成本与效率 (Cost & Efficiency) - “我们的钱花得值不值？”

维度三：稳定性与可用性 (Stability & Availability)- “我们的服务稳不稳？”

3 毛钱干大事？ 用了几天豆包编程模型，我来扒一扒字节这波操作

兼容 Claude Code

第一种方式

第二种方式

核心能力体验

VLM：前端仔的末日… 还是福音？

聊聊技术底裤

测试

总结

今日 AI 情报（2025-11-10）

2025北京 IT技术岗位市场趋势分析

宏观驱动与整体需求

细分岗位趋势

前端开发

后端／全栈开发

运维 / SRE

测试 / QA

架构 / AI 大模型

薪酬对比（中位值，税前 / 月）

🔥 技能热点与企业偏好

供需与竞争

给企业与求职者的建议

一、真实的工程世界，从来不是一道“闭卷考试”

二、刷题面试，正在惩罚真正有经验的“老兵”

三、算法题面试的本质：一场低效的“智商服从性测试”

四、如何打破僵局：回归工程本质的面试方法

五、结语：放过工程师，也放过企业自己

为什么要自己部署、运行、维护模型呢？全部用 API 不行吗？

3. 单模型多 Pod ，如何占多机多卡？

3 毛钱干大事？用了几天豆包编程模型，我来扒一扒字节这波操作

动态清零？这不就是GC吗