一套生产级 Prometheus 监控体系，绝不只是"跑起来一个 Prometheus 进程 + 配个 Grafana 面板"那么简单。从 2017 年 Prometheus 2.0 GA 至今，它的存储引擎、查询语言、生态工具链经历了数代演进。一个新项目如果按"开箱即用 demo"的认知去部署，三个月内几乎必然会在指标基数、告警风暴、长存储三件事上踩坑。
本文按"架构 → 数据采集 → 存储与查询 → 告警 → 高可用 → 落地清单"六个层次展开。
服务网格不是"装上就完事"的中间件，它会侵入每一个 Pod 的网络栈。一旦选型失误，团队会被 Sidecar 的资源开销、可观测性盲区、运维复杂度反复折磨。本文从数据平面、控制平面、性能、运维四个维度，给出工程取舍。
DDD（领域驱动设计）架构中，Infrastructure 层可以依赖 Domain 层吗？
答案是：可以，而且在现代 DDD 架构实践中，Infrastructure 依赖 Domain 是推荐的做法。
但这需要区分两种不同的分层架构模型来理解。
2017 年 Pinterest 工程团队在 SREcon 上分享其监控平台 Bender 时展示过一组数字：单业务域的时序指标规模动辄上万，传统告警体系面对每天数百条告警已经疲于奔命，但工程师真正关心的"这个请求为什么慢"却往往无解。那个时刻暴露了一个被广泛忽视的事实——传统监控（Monitoring）解决的是"系统是否在运行"，而真正想回答"系统为什么这样运行"，需要的是可观测性（Observability）。
监控与可观测性不是同义词。监控是一组预定义的仪表盘和告警规则，依赖"已知未知"——你必须先想象故障形态。可观测性是一套能从系统外部行为反推内部状态的能力，依赖"未知未知"——即使面对从未发生过的故障，也能从足够丰富的遥测数据中推断根因。
最近团队内部一次跨环境联调，因为有人忘了切流量染色 cookie，把预发请求打到了生产 —— 事故不大，但引发了一波复盘。这篇文章想把那段承担了"染色分发"职责的 APISIX 路由配置从结构上拆清楚。
graph LR
A[请求] --> B{host 匹配?}
B -->|*.example.com| C{uri 匹配?}
C -->|/sapi/*| D{filter_func 染色?}
D -->|匹配| E[proxy-rewrite 改路径]
D -->|不匹配| F[走其他路由]
E --> G[service_id 指向的 Service]
G --> H[上游节点]Redis 事务是一组命令的集合，通过 MULTI 和 EXEC 命令来执行。事务中的所有命令都会序列化，按顺序串行执行，不会被其他命令插入。本文深入解析 Redis 事务的特性和原子性问题。
2014 年 Google 开源 Kubernetes 时，Docker 已经独霸容器市场，但"容器编排"领域还是群雄割据：Mesos、Swarm、Nomad 各占山头。六年后，Kubernetes 几乎统一了整个云原生版图，成为容器时代的事实标准。
理解 Kubernetes 的关键，是把它的架构切成两个平面来看：控制平面（Control Plane）做决策，数据平面（Data Plane）执行决策。这两个平面通过声明式 API 和 list-watch 机制协作，构成一个典型的"分布式控制系统"——本质上和 Borg 的设计哲学一脉相承。
《肖申克的救赎》是被反复观看次数最多的电影之一。
有意思的是，它在 1994 年上映的时候票房并不算特别成功，最终被《阿甘正传》抢走了那一年的奥斯卡最佳影片奖。但这部片后来通过录像带、电视重播、DVD 一路流传，口碑越积越厚，最终被 IMDb 用户票选为有史以来最伟大的电影1。一部电影在二十多年里被一代又一代观众捧上神坛——这本身就是一个关于"希望"的故事。
在调用第三方 API 时，经常会遇到 QPS 限制。如果请求频率超过限制，API 会返回错误。此时我们需要限流 + 重试机制来保护下游服务。
本文详细介绍 Laravel 中 Redis::throttle 的实现原理。需要注意的是：Laravel 的实现实际上是固定窗口计数器，而非标准的令牌桶算法。
2013 年 Solomon Hykes 在 PyCon 做了一个 5 分钟的闪电演讲，把 dotCloud 内部用的容器工具开源出来，命名为 Docker。七年过去，Docker 已经从"开发玩具"变成"生产标配"，但很多工程师对它的理解仍停留在"换个命令行打包"的层面。
容器化的真正价值不是"省资源"，而是可移植性：开发机写的代码、CI 构建的产物、生产环境运行的服务，三者使用完全一致的运行时。把"在我电脑上能跑"这句话彻底从团队里抹掉。
但 Docker 的水面之下有大量概念需要搞明白：镜像分层、UnionFS、网络命名空间、卷管理、安全加固……这篇文章把 2020 年 Docker 最实用的知识点串起来。
新团队第一次接入消息队列，几乎都会问同一个问题：Redis Stream、RabbitMQ、Kafka 选哪个？三种方案在 benchmark 文章里都能跑到几十万 QPS，单看吞吐根本分不出胜负。但真正上线之后踩到的坑——消息被消费了两次、消费者卡住之后整个队列堆积、镜像队列脑裂后丢消息——都跟性能数字毫无关系。
分歧的根源不是性能，而是三者对"一条消息属于谁、什么时候算处理完"这个问题的回答完全不同。性能只是表面，语义模型才是选型的核心。
Uber 的 Go 指导规范
https://github.com/uber-go/guide/blob/master/style.md
使用 JWT 保证服务间通信的安全
https://abekthink.github.io/backend/json-web-token/
MySQL 查询对大小写不敏感
https://www.jianshu.com/p/408daf82ac71
服务流量限制（漏桶、令牌桶）
https://chai2010.cn/advanced-go-programming-book/ch5-web/ch5-06-ratelimit.html
为什么推荐 InnoDB 引擎使用自增主键？
https://blog.csdn.net/zheng0518/article/details/76302167
MySQL 唯一性索引与 NULL 字段
https://yemengying.com/2017/05/18/mysql-unique-key-null/
凌晨三点，监控系统告警：下单服务的 P99 延迟从 80ms 跳到 4s，CPU 跑满，数据库连接池打满，线程全部阻塞在等锁。重启服务、扩容数据库、加机器,十分钟后雪崩回来。问题根源不是代码 bug，是上游推荐服务在做一次全量重算，把下单接口的 QPS 从 2k 顶到 12k——所有资源都被拖垮，正常的请求也跟着排队超时。
这就是典型的"过载崩":服务不是慢慢变慢,而是像多米诺骨牌一样整体失能。排队论早就告诉我们，当系统利用率接近 100% 时，等待时间会呈指数级上升，客户端等不到响应就会重试，重试又叠加到已经过载的系统上，正反馈循环,雪崩。限流是在过载边缘切一刀,把多余的请求挡在外面,保护自己,也保护共享资源的所有调用方。
这篇文章想回答几个问题:主流的限流算法有哪几种、各自的取舍是什么?从单机限流到分布式限流,真正难的是哪一步?线上落地时应该选 Nginx、OpenResty 还是应用层自己实现?
2015 年 Google 开源 gRPC 时，REST/HTTP 几乎是分布式系统通信的唯一选项。四年过去，Kubernetes、etcd、istio 等 CNCF 核心项目都选择了 gRPC 作为内部通信协议；2018 年 gRPC-Web GA 之后，它开始向浏览器端延伸。
但有趣的是：外部 API 仍然首选 REST/HTTP。为什么同样是通信协议，在系统"内"和"外"的选择如此分裂？
这篇文章想回答几个问题：gRPC 到底是什么？它和 REST 相比到底快在哪？什么时候该用 gRPC，什么时候不该用？