面向云原生与高并发服务的编程语言
查看所有标签
外部使用 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 传播。
并发设计的第一步不是
go func()，而是知道工作在等待什么、占用什么，以及允许多少工作同时存在。
本期建立全系列的成本模型：CPU 密集、网络 I/O、同步阻塞和排队分别如何影响 Go runtime，并把目标 RPS 转成 goroutine、连接和内存预算。
创建 goroutine 的代码，也必须能说明谁等待它、谁取消它、它什么时候退出。
本期把 goroutine 从语法糖升级为受管理的生命周期。我们实现两种核心结构：请求内 fan-out/fan-in，以及跨请求的有界 worker pool。
Handler 只是入口；生产并发的真正边界位于连接池、下游 deadline、响应体和停机协议。
本期把前两期的容量与生命周期原则落到 net/http 服务，完成一个有界高扇出聚合 API。
零拒绝不是稳定性目标。系统超过容量时，及时拒绝一部分请求，才能保护已接纳请求和故障恢复能力。
本期专门处理“流量大于处理能力”。我们把限速、限并发、队列、重试和熔断放进同一个反馈系统，而不是堆叠互不理解的中间件。
并发安全不是“没有 concurrent map panic”，而是所有共享状态的不变量在任意合法交错下都成立。
本期建立同步原语的选择方法，并用 race detector、压力测试和业务不变量验证正确性。
排障不是随机抓火焰图，而是从用户影响和资源饱和提出假设，再选择能证伪它的证据。
本期完成系列闭环：建立压测方法、诊断端口和线上 Runbook，并复现 goroutine 泄漏、锁竞争、连接池耗尽与内存增长。
目标不是背 API，而是建立一套能设计容量、约束资源、证明正确性并处理线上事故的并发工程方法。
这个系列围绕同一个“高扇出聚合服务”逐期演进：入口接收请求，并发访问数据库、缓存和 RPC，最后聚合结果。每一期都会保留可复现实验、错误版本、修复版本和验收指标。
这张由 ImageGen 生成的系列概念图把高并发抽象成一条受控数据流：左侧大量青色任务先进入有界队列，中间由少量执行核心调度，右侧连接多个下游节点；少量橙色信号表示被监控和限制的过载，而不是任其扩散成雪崩。