东予薏米1. 理解 Pod 中的 srpcsrv 进程
第一次在 Kubernetes Pod 里发现 srpcsrv 进程时，我也感到困惑。这个看似陌生的进程其实在云原生架构中扮演着重要角色。让我们先搞清楚它的本质。
srpcsrv 是 Service RPC Server 的缩写，属于微服务架构中的基础设施组件。它主要负责服务治理相关的功能，包括但不限于：
- 服务注册与发现
- 健康检查与心跳维持
- 请求路由与负载均衡
- 服务间通信的监控与统计
在典型的云原生部署中，srpcsrv 会以两种方式出现在业务 Pod 中：
1.1 Sidecar 模式部署
这是目前主流的部署方式，也是 Kubernetes 官方推荐的做法。在这种模式下：
- 一个 Pod 包含两个容器
- 主容器运行业务逻辑（如 users 服务）
- Sidecar 容器专门运行 srpcsrv 进程
这种架构的优势很明显：
- 资源隔离：业务进程和治理进程互不影响
- 独立升级：可以单独更新 srpcsrv 版本而不影响业务
- 故障隔离：srpcsrv 崩溃不会导致业务容器重启
查看方法很简单：
bash复制kubectl get pod <pod-name> -o yaml
在输出的 YAML 中查找 containers 字段，如果有两个容器定义，其中一个名字包含 srpcsrv，那就是 Sidecar 模式。
1.2 同容器多进程模式
这是一种相对传统的部署方式，现在较少使用但仍有场景：
- 单个容器内运行多个进程
- 通常使用 supervisor 或类似工具管理进程生命周期
- users 业务进程和 srpcsrv 进程共存
这种方式的缺点包括：
- 资源竞争：多个进程共享容器资源
- 耦合度高：升级或调试一个进程可能影响另一个
- 监控困难：需要额外工具区分不同进程的资源使用
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 为什么 Pod 里通常没有 srpcgw
理解了 srpcsrv 后，很多工程师会自然联想到 srpcgw（Service RPC Gateway）。但实际情况是，业务 Pod 里很少会出现 srpcgw 进程，这是由架构设计决定的。
2.1 网关的架构定位
srpcgw 作为 API 网关，承担着以下核心职责