19 篇博文 含有标签「生产环境」

真正可靠的任务看板，不是“WebSocket 一直在线”，而是：状态先成为可恢复的事实，通知只负责让事实更快到达，任何一层短暂故障后都能重新收敛到正确状态。

文件解析、AI 生成、视频转码、报表导出这类异步任务，通常会经过多个服务和步骤。用户真正关心的往往不是复杂的工作流编排，而是几个朴素问题：

• 我的新任务是否已经创建？
• 当前是等待、运行、成功，还是失败？
• 当前由哪个服务执行什么功能，不同功能的数据该如何展示？
• 哪个步骤正在执行，已经用了多久？
• 步骤失败、自动重试或执行器失联时，用户如何收到明确告知？
• 页面断线、刷新或切到后台后，会不会永远停在旧状态？
• 服务多副本、节点重启、网络闪断时，状态通知是否仍能恢复？

本文设计一套专注于任务状态、步骤状态和耗时展示的生产链路。它不负责启动下一步、不替代工作流引擎，也不把实时消息系统当数据库。

最终方案可以概括为：

Business API 创建 workflowId 与独立 taskId
  → Worker 按 taskId 上报状态
  → Task Status Service 事务校验与落库
  → 同事务写 MySQL Outbox
  → Outbox Relay 领取并调用 Centrifugo 发布
  → 用户摘要频道 + 任务详情频道
  → 前端按 version 合并
  → 恢复失败时重新读取数据库快照

外部使用 REST，不代表内部也必须使用 REST；内部使用 gRPC，也不代表每个语言都要各自维护证书、重试、负载均衡和访问控制。Istio 的价值，是把跨语言的网络治理收敛到统一的数据平面和策略层。

本文不从 Bookinfo 示例开始，而是搭建一条更接近真实生产系统的链路：

外部客户端
  → HTTPS / REST
  → Istio Ingress Gateway
  → Java Web API
  → gRPC
  → Go Order Service
  → gRPC
  → Rust Inventory Service
  → PostgreSQL

三个服务只实现业务协议，Istio 负责入口、东西向 mTLS、工作负载身份、流量分配、超时、异常实例摘除和基础遥测；应用仍负责业务权限、幂等、事务、数据加密和 Trace Context 传播。

gRPC 在 Kubernetes 中“能调用成功”并不等于“已经具备生产级负载均衡”。当客户端只解析到一个 ClusterIP，再通过一条长期存在的 HTTP/2 连接发送请求时，多个 Pod 很可能长期冷热不均。

本文以 service-a 这一通用 Java 服务为例，复盘一条典型的生产治理路径：保留现有 ClusterIP Service 兼容原有调用，再增加只供内部 gRPC 发现的 Headless Service，让 Java gRPC 客户端和 Envoy 看见每一个 Pod，并把服务发现、健康检查、摘流、连接排空、超时重试、可观测性和发布验收串成闭环。

如果需要先补齐协议和 Java 基础，可以依次阅读 HTTP/2 协议层、Java 与 Netty 实现 和 gRPC 生产治理；本文专注 Kubernetes 与 Envoy 的端点级落地。

这不是一份只解决“DNS 返回几个 IP”的配置说明。生产落地需要同时回答六个问题：

1. 客户端究竟发现了 VIP，还是每个 Pod？
2. 负载均衡发生在 TCP 连接、HTTP/2 Stream，还是 RPC 级别？
3. 不可用 Pod 会不会继续出现在发现结果里？
4. Pod 下线时，存量长连接和在途 RPC 如何处理？
5. Java 客户端与 Envoy 谁负责重试、健康检查和摘除？
6. 如何证明流量真的分散，而不是只证明 DNS 能解析？

如果只看一份最小配置，Envoy 很像“另一个 Nginx”：监听一个端口，把请求转发给后端。但真正让 Envoy 成为云原生基础设施核心组件的，不是反向代理本身，而是它把路由、服务发现、负载均衡、故障隔离、安全和可观测性做成了一个可动态控制的数据平面。

这也是为什么 Envoy 会出现在 API Gateway、Kubernetes Gateway、Service Mesh、gRPC 基础设施、边缘代理和多集群流量治理中。

本文沿着一条生产链路展开：

1. Envoy 到底解决什么问题，什么时候值得使用；
2. 一个请求如何穿过 Listener、Filter、Route、Cluster 和 Endpoint；
3. 怎样在本地跑起一个具有灰度路由、健康检查和异常摘除能力的代理；
4. 怎样正确设计超时、重试、熔断、限流、鉴权和动态配置；
5. 怎样在 Kubernetes 上用 Envoy Gateway 部署一个跨节点、可扩缩、可优雅升级的高可用入口；
6. 上线前应该监控什么、演练什么，以及故障时如何定位。

本文基于 2026 年 9 月 4 日可用的官方资料与稳定版本：Envoy 1.39.1、Envoy Gateway 1.9.1。示例固定具体版本，避免生产环境无意间拉取变化中的 latest 镜像。

创建 goroutine 的代码，也必须能说明谁等待它、谁取消它、它什么时候退出。

本期把 goroutine 从语法糖升级为受管理的生命周期。我们实现两种核心结构：请求内 fan-out/fan-in，以及跨请求的有界 worker pool。

Handler 只是入口；生产并发的真正边界位于连接池、下游 deadline、响应体和停机协议。

本期把前两期的容量与生命周期原则落到 net/http 服务，完成一个有界高扇出聚合 API。

零拒绝不是稳定性目标。系统超过容量时，及时拒绝一部分请求，才能保护已接纳请求和故障恢复能力。

本期专门处理“流量大于处理能力”。我们把限速、限并发、队列、重试和熔断放进同一个反馈系统，而不是堆叠互不理解的中间件。

排障不是随机抓火焰图，而是从用户影响和资源饱和提出假设，再选择能证伪它的证据。

本期完成系列闭环：建立压测方法、诊断端口和线上 Runbook，并复现 goroutine 泄漏、锁竞争、连接池耗尽与内存增长。

目标不是背 API，而是建立一套能设计容量、约束资源、证明正确性并处理线上事故的并发工程方法。

这个系列围绕同一个“高扇出聚合服务”逐期演进：入口接收请求，并发访问数据库、缓存和 RPC，最后聚合结果。每一期都会保留可复现实验、错误版本、修复版本和验收指标。

这张由 ImageGen 生成的系列概念图把高并发抽象成一条受控数据流：左侧大量青色任务先进入有界队列，中间由少量执行核心调度，右侧连接多个下游节点；少量橙色信号表示被监控和限制的过载，而不是任其扩散成雪崩。

async 让等待更便宜，Semaphore 决定允许多少等待同时存在。

本期实现 /aggregate：每个请求并发访问多个下游，但入口和依赖都有独立硬上限。