gRPC C++ CSM Hello World 示例：xDS 控制平面、SSA 会话亲和与 CSM 可观测性实战指南

gRPC C CSM Hello World 示例xDS 控制平面、SSA 会话亲和与 CSM 可观测性实战指南【免费下载链接】mongoThe MongoDB Database项目地址: https://gitcode.com/GitHub_Trending/mo/mongo导读本文以 MongoDB 仓库中内置的 gRPC 第三方代码库src/third_party/grpc/dist内的 CSM Hello World 示例为对象系统讲解如何在 C gRPC 应用中接入 xDS 控制平面、验证服务网格会话亲和SSASession Stickiness Affinity以及启用 CSMCloud Service Mesh可观测性。读完本文你将掌握该示例客户端与服务端的全部命令行参数、基于 Docker 的多阶段构建与镜像推送流程并能结合源码理解 xDS 目标解析、Cookie 亲和会话以及 OpenTelemetry Prometheus 指标导出的底层实现。示例概览从 Hello World 到 xDS 与 CSM该示例位于 src/third_party/grpc/dist/examples/cpp/csm/README.md它构建在经典的 Hello World 示例 基础之上核心变化是客户端与服务端改为接受来自 xDS 控制平面的配置即通过 xDS 协议动态发现服务端点而不是在代码中硬编码服务器地址用于测试 SSA会话亲和即同一客户端在会话期间被粘附到同一后端实例用于测试 CSM 可观测性即将 gRPC 调用层面的指标通过 OpenTelemetry 导出到 Prometheus。从部署形态看这是一个面向 Kubernetes/GKE 等服务网格环境的示例客户端默认通过xds:///helloworld:50051这类 xDS URI 解析服务服务端则通过XdsServerBuilder构建可被 xDS 控制平面纳管的 gRPC 服务。客户端命令行参数客户端二进制csm_greeter_client通过 Abseil Flags 解析命令行参数具体定义位于 csm_greeter_client.cc参数默认值说明--targetxds:///helloworld:50051目标地址字符串。默认情况下客户端通过 xDS 解析xds:///helloworld:50051并连接到服务器后端可通过该参数覆盖--cookie_nameGSSA会话亲和 Cookie 名称--delay_s5两次 RPC 之间的间隔秒对应源码中的 Flag 声明如下ABSL_FLAG(std::string, target, xds:///helloworld:50051, Target string); ABSL_FLAG(std::string, cookie_name, GSSA, Cookie name); ABSL_FLAG(uint, delay_s, 5, Delay between requests);其中delay_s的类型是uint运行时可传--delay_s 1将 RPC 频率提高到每秒一次。在main()中absl::ParseCommandLine(argc, argv)负责解析全部 Flag随后循环调用SayHello()并按delay_s秒休眠形成持续的压力流。客户端的 Cookie 会话亲和实现SSA 的落地依赖 HTTP Cookie 机制客户端的实现细节如下首次 RPC 不携带 Cookie服务端通过set-cookie响应头下发会话 Cookie客户端在SayHello()中若本地已缓存了来自服务端的 Cookie则在请求上下文中通过context.AddMetadata(cookie, ...)携带回去见 csm_greeter_client.ccRPC 成功后客户端从context.GetServerInitialMetadata()中提取所有set-cookie头交给GetCookies()过滤出与cookie_name匹配的 Cookie 并缓存见 csm_greeter_client.ccParseCookie()负责把set-cookie头解析成「名称 / 值 / 属性」三元组属性集合用于记录Path、Max-Age等附加字段见 csm_greeter_client.cc。这套 Cookie 回带逻辑保证了在会话亲和场景下后续 RPC 始终能命中同一个后端实例从而验证服务网格的 SSA 行为。服务端命令行参数服务端二进制csm_greeter_server只接收一个命令行参数见 csm_greeter_server.cc参数默认值说明--port50051Hello World 服务监听的端口ABSL_FLAG(int32_t, port, 50051, Server port for service.);服务端的关键构建细节在RunServer()中见 csm_greeter_server.cc服务端做了几件面向服务网格部署的关键配置健康检查服务调用grpc::EnableDefaultHealthCheckService(true)启用默认 gRPC 健康检查服务便于网格与 K8s 探针探测存活状态Proto 反射调用grpc::reflection::InitProtoReflectionServerBuilderPlugin()注册 gRPC 服务反射插件xDS 服务构建器使用grpc::XdsServerBuilder而非普通的ServerBuilder构建服务并以InsecureServerCredentials监听0.0.0.0:port从而允许 xDS 控制平面发现并下发路由配置实例标识回复消息前缀为Hello from hostname hostname取自grpc_gethostname()见 csm_greeter_server.cc因此通过观察回复中携带的主机名就能直观验证同一客户端是否始终被路由到同一个后端 Pod这是验证 SSA 生效的便捷手段。构建从 gRPC 工作区构建 Docker 镜像README 要求在 gRPC 工作区目录即本仓库中的src/third_party/grpc/dist目录下执行 Docker 构建。客户端与服务端分别对应两个 Dockerfile构建客户端镜像docker build -f examples/cpp/csm/Dockerfile.client .构建服务端镜像docker build -f examples/cpp/csm/Dockerfile.server .镜像构建过程的源码级解析两个 Dockerfile 均采用多阶段构建见 Dockerfile.client 与 Dockerfile.server构建阶段基于python:3.9-slim-bookworm安装build-essential clang curl将整个 gRPC 工作区COPY . .进容器然后用tools/bazel执行 Bazel 构建客户端tools/bazel build //examples/cpp/csm:csm_greeter_client服务端tools/bazel build //examples/cpp/csm:csm_greeter_server构建服务端时显式指定OVERRIDE_BAZEL_VERSION5.4.0运行阶段仅包含精简运行环境curl用于存活探测等从构建阶段复制产物到镜像根目录关键环境变量运行阶段设置了ENV GRPC_EXPERIMENTAL_XDS_ENABLE_OVERRIDE_HOSTtrue用于启用 xDS 的 host override 实验特性在服务网格场景下这通常用于允许以端到端安全/路由方式覆盖请求的 Host 头入口ENTRYPOINT [/csm_greeter_client]或[/csm_greeter_server]。Bazel 构建目标定义在 BUILD 中csm_greeter_client依赖//:grpc、//:grpcpp_csm_observability、//examples/protos:helloworld_cc_grpc以及 Abseil Flags 与 OpenTelemetry C 的 Prometheus 导出器csm_greeter_server额外依赖//:grpc_reflection与//:grpcpp_admin分别对应服务反射插件与管理服务支持。推送镜像到镜像仓库如需将镜像推送到镜像仓库有两种方式在docker build命令中直接添加-t参数为镜像打标签docker build -t your-registry/your-image:tag -f examples/cpp/csm/Dockerfile.client .构建完成后用构建输出中的镜像 SHA 打标签docker image tag ${sha from build command above} ${tag}随后用docker push ${tag}将镜像推送到远端仓库即可供 Kubernetes/GKE 集群拉取部署。更精细的指标视图observability 子目录变体在同一目录下还存在一个 observability 子示例它专注测试 CSM 可观测性与主示例的差异点在于客户端新增--prometheus_endpoint参数默认localhost:9464服务端同样新增该参数用于指定 Prometheus 导出端点客户端针对grpc.client.attempt.duration指标、服务端针对grpc.server.call.duration指标调用AddLatencyView()覆盖默认直方图边界——这是因为默认直方图分桶对 RPC 时延粒度不够需按 gRPC A66OpenTelemetry 指标提案建议做视图覆盖见 observability/csm_greeter_client.cc 与 observability/csm_greeter_server.cc服务端额外通过absl::SetStderrThreshold与absl::SetGlobalVLogLevel(2)提升日志输出级别便于排查对应构建命令为docker build -f examples/cpp/csm/observability/Dockerfile.client .与docker build -f examples/cpp/csm/observability/Dockerfile.server .。CSM 可观测性初始化原理无论主示例还是 observability 变体客户端与服务端都通过同一套模式初始化可观测性入口位于头文件 include/grpcpp/ext/csm_observability.h构造opentelemetry::exporter::metrics::PrometheusExporterOptions并将导出 URL 设为0.0.0.0:9464。源码注释明确指出默认值localhost:9464会导致跨 GKE Pod 的连接问题因此改为监听所有网卡见 csm_greeter_client.cc创建 OpenTelemetry 的MeterProvider挂载 Prometheus 指标读取器AddMetricReader通过链式调用grpc::CsmObservabilityBuilder().SetMeterProvider(...).BuildAndRegister()构建并注册 CSM 可观测性组件CsmObservabilityBuilder类定义于 csm_observability.h其用法注释即示例CsmObservabilityBuilder().SetMeterProvider(provider).BuildAndRegister()若初始化失败返回非 OK 的StatusOr程序打印错误并以其状态码退出。完成上述初始化后gRPC 的 RPC 统计会被自动采集并经 Prometheus 导出器暴露在 9464 端口可供 Prometheus 抓取进而支撑 CSM 控制面的服务指标如成功率、时延分布展示。小结与实战建议快速上手在 gRPC 工作区src/third_party/grpc/dist内执行 README 提供的两条docker build命令即可得到客户端与服务端镜像镜像中已内置GRPC_EXPERIMENTAL_XDS_ENABLE_OVERRIDE_HOSTtrue环境变量适合直接部署到启用 xDS 控制平面的集群验证 SSA观察服务端回复中的Hello from hostname前缀若同一客户端连续多次 RPC 返回相同主机名则说明会话亲和已生效验证可观测性访问 Pod 的9464端口的 Prometheus 指标端点可查看到grpc.client.attempt.duration等指标需要更细粒度时延分桶时可参考 observability 变体的AddLatencyView()用法参数化部署通过--target、--cookie_name、--delay_s与--port可在不改代码的前提下适配不同环境与压测频率。【免费下载链接】mongoThe MongoDB Database项目地址: https://gitcode.com/GitHub_Trending/mo/mongo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考