- 博客(111)
- 收藏
- 关注
RSS订阅原创 FastAPI 响应格式类型全解析：从 JSON 到流式文件
所有内置响应类都继承自，你可以轻松扩展它们来实现统一响应结构或修改序列化行为。如果你需要全局更改datetime的格式，或让 JSON 支持更多自定义类型，可以重写render方法：pythoncontent,indent=2,default=str # 所有不可序列化对象转为 str然后通过或在应用层面设置。场景响应类返回 JSON 数据（API 主体）（默认）返回 HTML 页面返回纯文本文件下载（支持断点续传）流式传输大数据或实时数据URL 重定向返回二进制或非标准格式。
2026-08-07 15:21:30
355
原创 FastAPI 路由参数详解：三种参数类型与真实场景全掌握
路径参数是直接嵌入在 URL 路径中的动态变量，属于 URL 结构不可分割的一部分。例如/users/123中的123就是路径参数。在 FastAPI 中，路径参数通过在路径字符串中用{}包裹参数名来声明：pythonreturn {"用户ID": user_id, "message": f"查询用户 {user_id}"}访问/user/1001时，user_id会自动获取值1001。查询参数出现在 URL 的?之后，以key=value的形式书写，多个用分隔。例如/search?。
2026-08-06 15:23:28
268
原创 记一次在Windows下部署FastAPI+LangGraph项目的踩坑实录
最近在GitHub上找到一个非常赞的项目 ——，这是一个基于FastAPI和LangGraph的Agent生产级模板，集成了PostgreSQL、Redis、监控等全套基础设施。项目文档很全，但当我克隆下来准备在本地Windows环境运行调试时，却遭遇了一连串的“水土不服”。本文完整记录了我从零开始成功跑起该项目的全过程，希望给同样在Windows下折腾开源项目的你一些帮助。Unix命令不等于Windows命令sourcemake等在Windows下需寻找替代或手动执行等价操作。虚拟环境激活脚本因终端而异。
2026-08-06 00:47:20
167
原创 《Docker Compose + Dockerfile 完全解析：手把手教你部署 FastAPI + LangGraph 项目》
定义了6 个服务：应用、数据库、缓存、Prometheus、Grafana、cAdvisor，构成了一个完整的可观测性闭环。Dockerfile通过分层构建非 root 用户依赖缓存等最佳实践，打造了安全高效的镜像。两者结合，实现了“一次构建（镜像），多处运行（不同配置）”的容器化黄金法则。
2026-08-06 00:44:20
258
原创 《Makefile + Shell 脚本 + .env 配置：打造一键化开发的 DevOps 利器》
直接输入make时，自动显示帮助菜单。ENV?：默认环境为开发，可通过覆盖。VALID_ENVS：合法环境列表，配合check_env宏做防呆校验。bash打印当前环境、数据库地址、LLM 模型等关键信息，让你一眼看清当前终端连接的是哪个环境，避免“改错数据库”的低级失误。文件角色比喻核心价值Makefile遥控器将繁琐命令简化为make devset_env.sh电源适配器自动加载环境变量，防呆防错空白登记表统一配置 Schema，保障团队协作。
2026-08-06 00:43:33
161
原创 《Python 项目配置的终极方案：config.py + pyproject.toml 深度解读》
config.py是应用层的“终点站”，无论配置来自.env文件、Docker 注入还是 Shell 导出，都在这里被统一为 Python 对象。是项目的“物料清单”，定义了所有依赖库和代码规范，被Dockerfile和Makefile共同引用。整个配置体系遵循配置与代码严格分离，改变配置无需重新构建镜像。至此，我们从容器部署（第一篇）→开发自动化（第二篇）→应用配置（第三篇），完整覆盖了一个生产级 FastAPI + LangGraph 项目的所有配置维度。
2026-08-06 00:42:32
335
原创 Docker 部署核心法则：一次构建，多处运行
Dockerfile 负责“做菜”——固定菜谱和食材，做出唯一的一道菜；Docker Compose 负责“上菜”——决定这道菜加不加辣、用大盘还是小碗端给客人。菜（镜像）只做一次，就能满足不同客人的口味（环境）。这便是容器化部署中最优雅、最高效的实践模式。希望你在读完这篇文章后，能把这个法则刻进自己的部署思维中，让环境一致性的噩梦彻底成为历史。
2026-08-06 00:33:48
368
原创 生产级AI智能体的可观测性实战：从指标监控到LLM评估
目录/组件解决的问题核心工具服务健康与性能Langfuse 集成LLM 调用追踪Langfusestructlog结构化日志structlogevals/智能体质量评估自定义评估框架scripts/运维自动化Shell 脚本typings/类型安全Pyright这套体系的核心价值在于：它将 AI 智能体从一个“魔法黑盒”变成了“可观测、可度量、可优化”的工程系统。
2026-08-05 15:41:36
192
原创 从零到生产：FastAPI + LangGraph 智能体生产级模板深度解析
不仅仅是一个代码模板，更是一套经过实战检验的AI 智能体生产化最佳实践。它将 FastAPI 的高性能异步能力与 LangGraph 的工作流编排能力有机结合，辅以完善的记忆系统、高可用的 LLM 服务层和全面的可观测性体系，为开发者提供了一个可以直接上线的坚实基础。对于希望快速构建企业级 AI 智能体服务的团队而言，这个模板无疑是节省数月基础设施搭建时间的利器。正如项目所倡导的——处理那些“硬骨头”，让你专注于智能体逻辑。
2026-08-05 15:36:47
299
原创 用 LangChain 开发的智能体从“本地能跑“到“生产可用“
本地开发→ 用内存状态，快速迭代测试部署→ Docker + 单服务器 + Postgres 持久化生产上线→ K8s + 多副本 + Redis/Postgres + LangSmith 监控 + 限流降级大规模生产→ 考虑 LangGraph Platform 或自建更精细的调度系统Agent 不是确定性程序，而是"有行为的系统"——你需要的是可观测性、状态持久化和边界控制，而不是传统软件的那套监控思维。
2026-08-05 02:51:10
677
原创 [特殊字符] 不懂代码也能看懂：Transformer 到底是什么？
Transformer 的本质就是：让句子里的每个词都能同时"看到"其他所有词，并根据相关性重新理解自己。它用"注意力"模拟了人类阅读时的语境理解，用"并行"突破了传统方法的效率瓶颈。
2026-08-05 02:28:23
300
原创 从零开始：用 vLLM 搭建你的第一个 AI 推理服务——给 AI、微服务和 SRE 小白的实战指南
vLLM 是一个绝佳的"交叉学科"项目对AI 学习者，它是理解 LLM 推理优化的最佳入口对后端/微服务开发者，它是把 AI 能力产品化的标准工具对SRE/DevOps，它是挑战 GPU 集群运维的真实战场你不需要一开始就把所有东西都搞懂。先跑起来，再慢慢深入。"先让服务工作，再让它工作得好，最后让它工作得可靠。有任何问题，欢迎在 vLLM 的 GitHub Discussions 或社区论坛提问。祝你部署顺利！
2026-08-05 00:53:29
399
原创 从定位、核心功能、部署方式、生态与定价等多个维度，帮你理清GitLab 和 GitHub真正差异
它以开源协作起家，迅速成为全球最大的代码托管平台。2018 年被微软收购后，GitHub 在保持社区活力的同时，快速补齐了 CI/CD (Actions)、项目管理、安全扫描等能力，但它的核心基因依然是。
2026-08-03 16:48:09
452
原创 [特殊字符] 空间数据挖掘中频繁并置模式挖掘的并行与分布式加速：从传统方法到异构协同新架构
本文针对频繁并置模式挖掘的并行与分布式加速，提出了一套融合智能预筛选异构协同与增量更新的创新架构。其核心贡献可归纳为"三化"表格维度创新点解决的问题分区智能化空间-语义联合共分区 + 边界缓冲区负载倾斜、跨区邻居一致性枚举先知化GNN预筛选 + 反馈控制无效候选模式爆炸计算异构化CPU决策 + GPU批量验证流水线显存墙、分支发散。
2026-08-03 16:37:28
252
原创 Jenkins 遇见 Argo CD：构建可靠 GitOps 流水线的实战指南
Jenkins 与 Argo CD 的组合，不是对旧工具的抛弃，而是一次优雅的能力重新划分。Jenkins 继续擅长它最拿手的持续集成和自动化管道，而部署的“最后一公里”则交给 Argo CD，让它以声明式的方式守护集群的终态。这样一来，你的交付流水线既保留了 Jenkins 生态的灵活性，又获得了 GitOps 带来的可审计性、一致性和极速回滚能力。现在，不妨检查一下你现有的 Jenkins 流水线，把那些复杂的部署脚本，迁移到 Git 仓库里，让 Argo CD 开始倾听 Git 的声音吧。
2026-08-03 16:32:37
374
原创 十个高频“坑点”，帮你更顺畅地驾驭 Argo CD
Argo CD 是一个强大的 GitOps 引擎，但它遵循“你提供声明，我保证状态”的契约。它的灵活也意味着很多设计决策要留给使用者自行定义。避开上述十个误区，从一开始就构建有序、安全、可观测的 GitOps 流程，你会发现，Argo CD 确实能让集群管理变得优雅而从容。如果在实践中你还遇到了其他反直觉的“坑”，欢迎在评论区分享，一起让 GitOps 之路少些绊脚石。
2026-08-03 16:27:06
342
原创 AI 浪潮下的基础设施新需求
AI 时代并没有抛弃 Kubernetes，反而让它从“微服务平台”进化为“一切工作负载的平台”。AI 带来的异构计算、混合任务、苛刻调度需求，恰好是 K8s 可扩展架构的试金石。如今，K8s 已成为 AI 基础设施的默认控制平面，掌握好这套体系，就等于拿到了智能时代的基础设施钥匙。如果你正在搭建或优化 AI 平台，不妨以 K8s 为骨架，按需引入 Volcano、Kueue、KServe 等组件，逐步构建起一套高效、弹性、低成本的智能算力调度系统。这趟列车，才刚驶出站台。
2026-08-03 16:23:59
346
原创 Argo CD 多集群管理终极指南：一个控制平面，掌控所有 Kubernetes 集群
Argo CD 的多集群支持让统一的 GitOps 工作流贯穿所有环境，不再是梦。你只需要学会添加集群、配置权限、指定目标，并结合 ApplicationSet 的 Cluster 生成器实现动态编排，就能构建起一个强大而灵活的多集群交付平台。从单集群到多集群，不是简单的数量增加，而是管理范式的升级。借助 Argo CD，你可以从容应对任何规模的基础设施，让应用在任何集群上都能以一致、可靠的方式运行。你在管理多集群时遇到了哪些挑战？有没有用过更复杂的多集群部署策略？欢迎评论区分享你的故事。
2026-07-30 01:06:37
328
原创 Argo CD Webhook 完全指南：从原理到实战，实现 Git 变更即时同步
Argo CD Webhook 是 GitOps 工作流中提升效率的关键一环。它让 Git 仓库的变更能够秒级传递给 Argo CD，将持续部署推向“实时交付”。通过简单的配置，你就可以让 GitHub、GitLab 等平台在代码推送后立即通知 Argo CD，实现完全自动化的部署流水线。到现在为止，我们已经掌握了 Argo CD 的安装、Application 管理、App of Apps、ApplicationSet 以及 Webhook。这些组件共同构成了一个完整的 GitOps 生态系统。
2026-07-30 01:03:02
279
原创 Argo CD 从零到一：手把手教你搭建 GitOps 工作流
yamlmetadata:spec:source:path: .automated:注意：根应用的path指向仓库根目录（），它会递归发现目录下的所有 Application 资源。通过以上步骤，你已经成功搭建了 Argo CD，实现了从 Git 仓库自动同步应用到 Kubernetes 集群的完整 GitOps 工作流。回顾核心流程：安装 Argo CD 到集群配置 Git 仓库访问凭据创建 Application 指向目标配置开启自动同步、自愈和清理。
2026-07-30 01:00:44
379
原创 Argo CD App of Apps 模式深度解析：像管理应用一样管理应用
App of Apps 不是一个特定的 API 对象，而是一种架构模式。其核心思想是：用一个“根 Application”来管理一组“子 Application”，这些子 Application 的定义文件本身也存放在 Git 仓库中，根 Application 通过指向该目录将它们 apply 到集群。简单说，就是把 Application 的 YAML 文件当成普通 Kubernetes 资源来部署，而 Argo CD 认出了这些 Application 资源，就会自动去接管它们所描述的应用。
2026-07-30 00:59:46
435
原创 告别手工管理 Argo CD Application：ApplicationSet 批量编排实战指南
ApplicationSet 是 Argo CD 的一个CRD（自定义资源），它利用模板（Template）和生成器（Generator）自动创建多个 Application 资源。模板：定义了一个 Application 的“骨架”，其中部分参数用变量表示。生成器：负责产生多组变量值，每组值渲染出一个完整的 Application。一个 ApplicationSet 可以生成几十、几百个 Application，你只需维护这个 ApplicationSet 资源即可。
2026-07-30 00:55:53
440
原创 将 LLM 作为微服务部署：基于 vLLM 生产栈掌握 GPU 调度与 KEDA 弹性伸缩
通过 vLLM + Kubernetes + KEDA 的组合，我们将 LLM 从“脆弱的怪兽”变成“健壮的微服务”。你学到了：如何在 K8s 上为推理服务配置GPU 调度（设备插件、亲和性、共享技术）如何用KEDA基于推理请求队列自动扩缩容一套可复制的 vLLM 生产部署方案这套技术栈正是 2026 年 “AI-Integrated 微服务” 理念的实践：让 AI 能力像数据库一样，以服务的形式安静地支撑业务，而不是推翻一切重来。
2026-07-29 22:09:30
412
原创 当 AI 遇到 Kubernetes：在生产环境部署与管理 AI 服务的终极指南
Kubernetes 为 AI 服务提供了统一的运行平台，使其能够融入现有的云原生生态。GPU 调度、弹性伸缩、服务网格、GitOps 这些曾经只属于业务微服务的能力，如今同样适用于推理、RAG、Agent 和记忆服务。2026 年，我们不再把 AI 当作特殊的“魔法”组件，而是以一种工程化的方式将其落地——这就是 AI-Integrated 微服务的真谛。Kubernetes，正是承载这场融合的最佳基座。如果你在 K8s 上部署 AI 服务时遇到过哪些坑？或者有独家的优化经验？
2026-07-29 22:05:49
361
原创 2026 微服务新范式：AI-Integrated，而非 AI-First
AI-Integrated 微服务不是一场革命，而是一次务实的架构进化。它将 AI 从神秘的黑盒拉回到熟悉的工程领域：定义接口、约定协议、关注可用性、控制成本。当推理服务像 MySQL 一样稳定，当 RAG 服务像 Redis 一样快捷，当 Agent 服务像工作流引擎一样可靠，AI 才真正融入企业软件的血液。这，才是 2026 年最值得投入的方向。如果你正在实践 AI 与微服务的融合，欢迎在评论区分享你的架构与困惑，我们一起探索智能软件的下一个十年。
2026-07-29 22:01:40
505
原创 云原生 GitOps 终极武器：Argo CD 从原理到实战全解析
传统 CI/CD 通常采用推送模式：CI 系统构建镜像后，通过脚本执行或调用 API 将新版本部署到集群。这种方式存在几个痛点：操作不可追溯：谁在什么时候改变了什么？环境不一致：手动操作容易导致集群状态与定义文件出现漂移。权限暴露：CI 系统通常持有集群写入凭证，存在安全风险。GitOps声明式配置：系统的期望状态完全由 Git 仓库中的声明式文件描述（YAML、Helm Chart、Kustomize 等）。单一事实来源：Git 仓库即真理之源，任何对集群的变更都必须先落到 Git 上。拉取式交付。
2026-07-29 21:51:36
462
原创 一文读懂Docker与Kubernetes：从容器引擎到编排平台，底层原理全解析
Docker 和 Kubernetes 的成功，源于它们巧妙地将 Linux 内核的强大能力抽象成开发者友好的工具。掌握底层原理，不仅能从容应对故障排查，还能更好地设计云原生应用。进阶建议手动用unsharecgroup创建容器，加深理解。阅读runc源码中 namespace 设置部分。研究一个 CNI 插件的工作原理。部署一个多节点 K8s 集群并观察控制循环日志。
2026-07-29 13:59:29
165
原创 ArgoCD和Kubernetes到底是什么关系？一张图彻底讲清楚
ArgoCD和Kubernetes的关系，一句话就能说清：Kubernetes是ArgoCD的“宿主环境”和“执行力来源”，ArgoCD是Kubernetes的“智能自动化大脑”。底层：基础设施（服务器、网络、存储）中间层：Kubernetes（容器编排，提供API）上层：ArgoCD（应用层，调用K8s API实现GitOps）每层都依赖它的下一层，层层递进，缺一不可。这就是云原生技术栈的优雅之处——每一个工具都专注做一件事，并通过标准API进行组合，最终形成强大的自动化系统。🚀。
2026-07-28 15:35:05
292
原创 ArgoCD到底是如何“死磕”YAML文件的？深入理解GitOps的调谐循环机制
application-controller在内存中维护了一个无限循环。这个循环默认每3分钟执行一次（可以通过timeout参数调整），同时也会被以下事件即时触发：你push代码了，马上触发同步集群资源变化事件：有人在集群里手动改了东西，立即触发检测Application定义变化：你修改了Application的spec环节核心组件做了什么读取YAML克隆Git → 渲染（Helm/Kustomize）→ 生成纯K8s清单长期维护无限循环对比 Git定义 vs 集群实时发现差异。
2026-07-28 15:30:09
275
原创 ArgoCD进阶指南：多集群、ApplicationSet、自动更新与生产级最佳实践
当你管理的应用从几个变成几十个时，ApplicationSet可能还不够——你需要一个更高层次的组织方式。App of Apps（应用之应用）模式一个父Application负责管理和部署多个子Application。
2026-07-28 15:19:32
298
原创 别再手动kubectl了！花10分钟搞懂ArgoCD，让Kubernetes部署彻底自动化
GitOps。GitOps不是某个具体的软件，而是一种运维理念。原则大白话解释Git是唯一数据源集群里所有配置（Deployment、Service、ConfigMap等）都放在Git仓库里，Git的提交记录就是配置的“版本历史”声明式定义目标状态你在Git里写“集群应该长什么样”（比如副本数=3），而不是写“我要执行什么操作”（比如kubectl scale）自动同步有个工具（比如ArgoCD）持续监控Git和集群的差异，一旦Git变了，就自动把集群同步成Git里定义的样子。
2026-07-28 15:16:06
324
原创 花了3小时排坑，我终于搞懂了ArgoCD到底运行在哪里
yamlmetadata:spec:source:helm:- values.yaml # 基础变量- ../../environments/values-prod.yaml # 生产覆盖automated:prune: true # 自动删除Git中没有的资源selfHeal: true # 自动纠正集群与Git的差异基础覆盖（优先级更高）所以你要改生产环境配置，就去改。序号一句话总结1。
2026-07-28 15:13:02
530
原创 生产环境实战：使用 GitHub Actions 打造安全的自动化部署流水线
在之前的文章中，我们详细记录了如何在 GitHub Actions 中模拟运行一个 Kubernetes 微服务项目的 CI/CD 流水线。从 YAML 语法错误到 Helm 模板问题，从secrets不能在if中使用到需要集群连接，一步步将红色报错变成了绿色成功。然而，"跑通"和"生产可用"之间，还有一段路要走。当我们真正把代码部署到生产服务器时，核心问题不再是"流水线能不能跑起来"，而是：如何安全地让 GitHub Actions 连接到我的生产服务器？
2026-07-27 22:27:08
512
原创 GitHub Actions 从入门到实践：打造你的第一条自动化 CI/CD 流水线
如果你曾经手动执行过“代码提交 → 运行测试 → 构建打包 → 部署上线”这一系列重复操作，那你一定知道这有多繁琐。就是为了解决这个问题而生的。GitHub Actions 是 GitHub 官方提供的持续集成和持续交付（CI/CD）平台。简单来说，它让你能够在 GitHub 仓库中发生特定事件时（比如代码推送、拉取请求创建），自动执行你预先定义好的一系列任务。CI/CD 流水线：每次推送或拉取请求时自动构建、测试代码，并将应用部署到预发布或生产环境。代码质量保障。
2026-07-27 22:14:45
133
原创 从“跑通”到“生产级”：我的 CI/CD模拟实战与生产环境差距复盘
在上一篇文章中，我详细记录了如何将一个 Kubernetes 微服务项目的 GitHub Actions 流水线从各种报错（secrets语法错误、模板解析失败、kubectl集群连接拒绝）中一步步修复，最终在界面上看到绿色的“Success”标志。我刚刚在 GitHub 公共 Runner 上跑通的这套东西，能直接拿去生产环境用吗？答案显然是不能。“跑通”和“生产可用”之间隔着一道巨大的鸿沟。
2026-07-27 16:23:03
481
原创 从零实践：在 GitHub Actions 中模拟 Kubernetes 微服务项目的 CI/CD 流水线
作业耗时状态5s✅ 成功0s⏭️ 跳过（build=false）19s✅ 成功知识点说明if条件限制不能直接使用secrets上下文，应使用env中转或简化条件手动触发工作流，支持自定义输入参数needs依赖控制作业执行顺序，被依赖的作业失败会影响后续作业控制 GITHUB_TOKEN 的权限，如用于推送镜像学会了调试 GitHub Actions 工作流：从 YAML 语法到逻辑条件，每个环节都有了更深入的理解。掌握了 Helm 在 CI 中的最佳实践：dry-run 不等于，使用。
2026-07-27 16:17:46
125
原创 文件解读(build-and-deploy.yml完整 CI/CD 流水线）
，支持多平台（linux/amd64, linux/arm64），并使用 GitHub Actions 缓存加速。（必选）：目标集群（local-dev / aks-dev / aks-staging / aks-prod）。（必选）：目标环境（dev / staging / prod）。），并提供了灵活的部署参数（如目标集群、环境、镜像标签等）。（布尔）：构建完成后是否执行部署（默认 false）。它支持自动化触发（推送、PR、标签）和手动触发（（布尔）：是否构建并推送镜像（默认 false）。
2026-07-27 14:59:23
321
原创 从原生 K8s 到 Helm：彻底搞懂 templates/、values 与 Chart.yaml
从k8s/到helm/，本质是从静态配置走向动态管理。Chart.yaml（我是谁）+templates/（模板骨架）+（默认值）+（环境补丁）= 生产级 Kubernetes 部署templates/让你"写一次，到处用"给你"统一的基准"和让你"只改差异，环境隔离"Chart.yaml让 Helm 知道"这个包叫什么、什么版本、依赖谁"掌握这套机制，你就从"会写 Kubernetes YAML"进阶到了"会用 Helm 管理生产级多环境部署"。下一步，就是去挑战多集群部署和 GitOps 了。
2026-07-24 15:32:59
398
原创 从原生 K8s 到 Helm：理解 templates/ 与多环境 values 配置
从k8s/到helm/，本质是从静态配置走向动态管理。templates/让你"写一次，到处用"给你"统一的基准"和让你"只改差异，环境隔离"掌握这套机制，你就从"会写 Kubernetes YAML"进阶到了"会用 Helm 管理生产级多环境部署"。下一步，就是去挑战多集群部署和 GitOps 了。记住这个公式模板 + 默认值 + 环境覆盖 = 生产级 Kubernetes 部署。
2026-07-24 15:20:20
345
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人