通信可靠性保障的五阶段演进从业务代码耦合到服务网格

容器编排系统管理的最细粒度只到容器层，容器之下的通信可靠性（路由、 容错、限流、加密、认证、跟踪、度量）长期只能靠程序员自己想办法，这条 自救之路走了五个阶段。第一阶段：通信逻辑直接写进业务代码，由业务开发 者保障可靠性——早期系统集成OkHTTP/gRPC，遇到问题就补重试降级逻辑， 控制逻辑和业务逻辑耦合在同一进程，普通开发者不擅长这类专业工作，代码 越改越乱。第二阶段：把通信功能抽成公共组件库（Twitter Finagle、Spring Cloud），由专业平台开发者维护——效率质量都更好，但组件与编程语言绑定， Python写的组件对Java系统没用，同一问题往往要学多套不同组件。第三阶段： 把通信组件独立到进程外，通过网络代理交互（Netflix Prana）——代理和 业务逻辑不共享进程但仍在同一容器/虚拟机，靠回环设备或UDS交互，代理 拉远给多个进程共用就演化成微服务网关，代理靠近进程、共享网络名称空间 就演化成边车代理。第四阶段：网络代理以边车形式注入应用容器、自动劫持 流量——相比独立代理有两个跃升：劫持是强制的（不再是”程序愿不愿意去 访问代理”），对应用完全透明（不用改代码不用引库）。第五阶段：把边车 代理统一管控起来，分离数据平面和控制平面，这就是服务网格——因为边车 代理本身也需要被告知服务列表、IP地址等信息，管理代理本身产生的通信 需求，只能靠专门的控制平面来解决。

结构图：

flowchart LR
    A[阶段1: 通信代码写进业务逻辑] -->|抽离重构| B[阶段2: 公共组件库<br/>与语言绑定]
    B -->|独立到进程外| C[阶段3: 独立网络代理<br/>需程序主动访问]
    C -->|拉远给多进程共用| C1[微服务网关]
    C -->|靠近进程/共享网络名称空间| D[阶段4: 边车代理<br/>强制劫持+对应用透明]
    D -->|统一管控代理本身| E[阶段5: 服务网格<br/>数据平面+控制平面分离]