49 篇博文 含有标签「深度解析」

真正可靠的任务看板，不是“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 能解析？

过去的浏览器 Agent 想在网站上完成任务，通常需要截图、识别按钮、滚动页面、填写输入框，再猜测下一步该点哪里。它能工作，却像让一个只拿到监控画面的机器人操作控制台：页面布局一改、按钮被遮挡、文案稍有歧义，整条任务链就可能失败。

WebMCP 提出了另一种思路：网站主动把自身能力声明为结构化工具，由浏览器在页面和 Agent 之间完成发现、权限检查、调用与结果传递。

Agent 不再只看到“一个蓝色按钮”，而是能看到一份接近函数契约的描述：

{
  "name": "book_appointment",
  "description": "预约一个仍有空位的咨询时段。",
  "inputSchema": {
    "type": "object",
    "properties": {
      "date": { "type": "string", "format": "date" },
      "slot": { "type": "string" }
    },
    "required": ["date", "slot"]
  }
}

这不是要消灭图形界面，而是让同一个 Web 应用同时拥有两种可用界面：

• 人类使用视觉 UI；
• Agent 使用工具名、自然语言描述和 JSON Schema；
• 两者共享同一标签页、登录状态、应用状态和可见结果。

这也是 OpenAI 发起 WebMCP Challenge 的核心命题：构建一个在人与 Agent 共同使用时会变得明显更好的 Web 应用。

并发设计的第一步不是 go func()，而是知道工作在等待什么、占用什么，以及允许多少工作同时存在。

本期建立全系列的成本模型：CPU 密集、网络 I/O、同步阻塞和排队分别如何影响 Go runtime，并把目标 RPS 转成 goroutine、连接和内存预算。

并发安全不是“没有 concurrent map panic”，而是所有共享状态的不变量在任意合法交错下都成立。

本期建立同步原语的选择方法，并用 race detector、压力测试和业务不变量验证正确性。

Rust 的类型系统可以阻止不安全共享，但不会替你决定该共享多少、排队多久和何时拒绝。

本期先区分线程并行和 async I/O，并理解所有权、Send、Sync 与 Arc 真正保证什么。

async fn 返回的是一台惰性状态机；只有 executor 持续 poll，它才会向前执行。

本期理解 Tokio task 的调度与取消语义，并实现不泄漏子任务的 fan-out/fan-in。

编译通过证明内存访问安全，不证明业务事务完整、锁不会死锁或 Future 可以在任意 await 点被取消。

2026 年 8 月 19 日，OpenAI 将 Codex 更清晰地定义为一个可供开发者构建产品的 开放 Agent Harness。这句话容易被误读成“Codex 模型开源了”，实际开放的是模型周围的运行时与集成面：会话、Agent Loop、工具执行、沙箱、审批、事件流、CLI、SDK 与 App Server。

用一句话概括：

模型决定下一步做什么，Harness 决定它能看到什么、可以怎样做、需要谁批准，以及整个过程如何被恢复和观察。

这篇文章会回答三个问题：

1. openai/codex 到底开放了什么，没开放什么；
2. 面对庞大的 Rust 工作区，应当怎样学习 Agent Harness 的原理；
3. 如何选择 codex exec、Codex SDK 或 App Server，构建自己的应用。