/tags/platform-engineering/ Recent content in platform-engineering on Hugo -- gohugo.io en Fri, 22 May 2026 12:00:00 +0800 /reading/github/ebpf-deployment-safety/ Fri, 22 May 2026 12:00:00 +0800 /reading/github/ebpf-deployment-safety/ 原文链接 GitHub Uses eBPF to Eliminate Deployment Risks and Prevent Circular Failures How GitHub uses eBPF to improve deployment safety InfoQ 这篇新闻总结的是 GitHub Engineering 在 2026 年 4 月发布的一篇文章。它讨论的不是常见的 eBPF 网络加速或可观测性案例，而是一个更偏平台工程的问题：部署系统本身会不会依赖它正在修复的系统。 这个角度挺有意思。我们平时谈 Cloud Native 的可靠性，经常会讲多副本、自动扩缩容、健康检查、Service Mesh、GitOps、回滚策略。但当系统真的进入故障态时，一个很实际的问题往往更朴素：修复系统的工具链还能不能工作。 GitHub 这次解决的是什么问题 GitHub 的基本矛盾是一个典型的循环依赖：GitHub 的源码托管在 github.com 上，但 github.com 如果出现故障，修复它的部署动作又可能需要访问 github.com。 这个显性的循环依赖可以通过代码镜像和构建产物镜像缓解。真正麻烦的是部署脚本里的隐性依赖，比如： 直接依赖：部署脚本临时从 GitHub 下载某个 open source 工具。 隐藏依赖：机器上已有的工具启动时自动检查更新，背后访问了 GitHub。 传递依赖：部署脚本调用内部服务，内部服务再去 GitHub 拉取 release 或 binary。 这些依赖平时可能不容易看出来，因为所有服务都健康时它们只是一次普通的网络访问。等到事故发生，才发现部署链路需要依赖一个已经不可用的服务，于是修复动作被卡住，MTTR 被拉长。 GitHub 的做法不是要求每个团队手工审查脚本，而是把部署脚本放进单独的 cGroup，再用 eBPF 挂到这个 cGroup 的网络出口上。这样可以只观察和限制部署进程的 outbound network access，而不影响同一台 stateful host 上继续承载生产流量的其他进程。 /posts/microservices-boundary-governance-2019-2026/ Mon, 04 May 2026 10:00:00 +0800 /posts/microservices-boundary-governance-2019-2026/ 2023 年，Amazon Prime Video 公开了一个架构优化案例：他们把一个音视频质量监控 pipeline 从分布式 serverless 组件合并成单进程应用，运营成本降了 90%。很多转述把它概括成「Amazon 放弃微服务」，但这恰恰是最没有价值的读法。 更有价值的问题是：为什么这些大公司在不同阶段做出了完全不同的架构选择？为什么有的继续扩展几千个微服务，有的把某条链路合并回进程内，有的坚持模块化单体，有的把治理重点从服务迁移到 cell、supergraph、data contract？ 下面这七个案例不是为了证明「微服务好」或「单体好」。它们更像七个坐标点，帮助我们判断：在什么规模、约束和组织形态下，服务边界的收益还能不能覆盖它带来的成本。 七个案例 Amazon Prime Video — 把一条高吞吐 pipeline 合并回单进程（2023） 做了什么： Prime Video 的 Video Quality Analysis 团队原本用 Step Functions、Lambda、S3 等 serverless 组件串起音视频质量检测流程。后来他们把媒体转换、检测器和编排逻辑合并到一个进程内运行，部署在 ECS/EC2 上，减少了中间数据搬运和编排状态跳转。 为什么： 主要瓶颈不是业务计算，而是编排和数据移动成本。每秒视频流会触发多次 Step Functions state transition，容易撞到账户限制；视频帧通过 S3 在组件之间传递，读写量和费用都很高。合并后，帧数据在内存里传递，编排逻辑也从外部状态机变成进程内控制流。 容易被误读的地方： 这不是 Prime Video 放弃微服务，而是一个特定工作负载上的边界重画。这个案例的价值在于提醒我们：当一条链路里的数据移动和编排开销超过业务计算本身时，服务拆分就不再是免费的抽象，而是可以被量化的成本。 Monzo — 接近 3,000 个微服务后的中央治理（2022–2026） 做了什么： Monzo 长期运行大规模 Go 微服务。2022 年他们公开提到 2,000+ 服务；2024 年迁移文章里数字已经到 2,800+；同年另一篇限流文章把规模描述为接近 3,000 个微服务。 关键在哪： Monzo 的重点不是「服务数量多很厉害」，而是他们选择了高度一致的技术栈、monorepo、统一平台和中央驱动迁移。比如把 tracing 从 OpenTracing/Jaeger SDK 迁到 OpenTelemetry SDK 时，Monzo 不是让每个服务 owner 自己慢慢改，而是由一个团队设计 wrapper、自动化修改 call site、批量部署，再用配置系统灰度打开。