C#怎么使用Grpc构建微服务_C#如何实现跨语言调用【前沿】

Grpc.Core 还是 Grpc.Net.Client？选错直接卡在 TLS 握手

新项目别碰 Grpc.Core（基于 C++ gRPC）——它在 .NET 6+ 上已标记为“legacy”，Windows/macOS/Linux 行为不一致，尤其在容器里常报 StatusCode=Unavailable, Detail="failed to connect to all addresses"。必须用 Grpc.Net.Client（纯托管、基于 HTTP/2 + System.Net.Http），但它默认要求 TLS：本地开发不配证书就直接失败。

开发阶段快速绕过：服务端启动时加 options.ListenAnyIP(5001, o => o.UseHttps()) 改成 UseHttp()；客户端创建 Channel 时传入 new Channel("http://localhost:5001", ChannelCredentials.Insecure)生产环境必须上 HTTPS：Kestrel 不支持 HTTP/2 明文，UseHttp() 在正式部署会静默降级成 HTTP/1.1，导致调用失败Grpc.Net.Client 不支持 Windows Server 2012 R2 及更早系统（缺 ALPN 支持），得换回 Grpc.Core ——但这时要手动装 grpc_csharp_ext.x64.dll，且 Linux 容器需额外加 libc6-dev 依赖

Protobuf 文件怎么写才让 C# 和 Python/Go 消费不出错

跨语言核心不是语法，是序列化契约。C# 的 Google.Protobuf 对字段编号、保留字、嵌套规则比其他语言更敏感，一个 repeated 写成 list 或漏掉 syntax = "proto3"; 就会导致 Go 解析出空对象、Python 报 AttributeError。

所有 message 必须显式声明 syntax = "proto3";，proto2 生成的 C# 类默认带 HasXXX 属性，其他语言没这概念枚举值第一个必须是 0（如 UNKNOWN = 0;），否则 C# 反序列化时默认值为 0，但 Go/Python 可能映射失败避免在 proto 里用 map<string, string>：C# 生成的是 Dictionary<string, string>，但 Python grpcio 默认转成 dict，而 Go 是 map[string]string —— 看似一样，实际 JSON 序列化顺序不同，diff 工具会误报差异

.NET 客户端调用时为什么总是 “Status(StatusCode=Internal, Detail=”Error starting gRPC call”)”

这个错误根本不是业务逻辑问题，90% 是 HTTP/2 层被中间件拦了。IIS、Nginx、甚至某些公司内部网关默认不转发 HTTP/2 帧，或者把 te: trailers 头给删了 —— 而 gRPC 必须靠这个头标识流结束。

本地测试先绕过代理：用 curl -v –http2 https://localhost:5001/greet.Greeter/SayHello 看是否返回 HTTP/2 200，不是就说明 Kestrel 配置或 TLS 证书有问题IIS 部署必须开 HTTP/2：Windows Server 2016+ + IIS 10.0+ + SNI 证书 + 在站点绑定里勾选 “HTTP/2”（不是“启用 HTTP/2”复选框，是绑定设置里的独立选项）Nginx 转发需显式透传头：proxy_http_version 1.1; 改成 2.0，并加 proxy_set_header TE "trailers";，否则 C# 客户端收不到响应末尾的 status trailer

从 ASP.NET Core Web API 切到 gRPC，HttpContext.Items 为什么丢了

gRPC 请求不走 MVC 管道，HttpContext 是空壳 —— 即使你用 AddGrpc() 和 AddControllers() 混合注册，gRPC endpoint 的 HttpContext 也不会触发 AuthorizationMiddleware 或 ResponseCompressionMiddleware 的完整生命周期。

认证必须用 ServerCallContext：在 service 实现里通过 context.RequestHeaders.Get("authorization") 手动取 token，别依赖 [Authorize]日志上下文要用 Activity：gRPC 自动注入 Activity.Current?.Id，比 HttpContext.TraceIdentifier 更可靠，且跨语言一致全局异常不能靠 UseExceptionHandler：要实现 IGrpcServiceActivator 或在每个 service 方法里 try/catch，再用 status: StatusCode.PermissionDenied + detail 返回结构化错误

真正麻烦的从来不是写几个 async Task<HelloReply>，而是搞清哪一层在吃你的 header、谁在提前关闭 stream、以及 protobuf 字段编号改一个会不会让 Java 客户端开始返回 null —— 这些细节不会报红，但会让联调花掉三天。