当一个 golang gRPC 服务器调用一个处理函数时，传递的 ctx 值是从这里创建的私有顶层上下文派生的，在 grpc 传输层：
/go/pkg/mod/google.golang.org/grpc@v1.27.0/internal/transport/http2_server.go:219

为什么该上下文不是从服务器构建时提供的根上下文派生的，有什么原因吗？

也许grpc.NewServer(opt ...ServerOption)可以有一个 ctx 变体grpc.NewServerCtx(ctx, ...ServerOption)？

这将为您提供传输您希望所有上下文包含的值的选项。

我正在实现一个 gRPC API，并希望添加 JSON 正文数据作为响应。

所以我试过：

原型3

接口代码：

添加此获取 gRPC API 响应后：

问题是正文 JSON 键值是动态的。有什么方法可以让我们得到类似的回应

我正在尝试在 Kubernetes 中运行用 Golang 编写的 gRPC 服务。我正在部署服务（没有任何 SSL）。Kubernetes 也有nginx运行标志--enable-ssl-passthrough。我有一个 Go 客户端，它尝试调用 gRPC 服务（没有 TLS），我收到以下错误：

当我kubectl exec进入 gRPC 服务 pod 并在 pod 内运行客户端代码（带有地址：）localhost:<port>时，我得到了正确的输出。但是我无法从外部与 gRPC 服务进行通信。

我正在考虑将我的一个应用程序从 gRPC 服务迁移到一组 Google Cloud Functions 中。这感觉真的很诱人，从我的发现来看——gRPC 通过云函数直接支持的 HTTP/2 工作。

据我所知，函数的名称实际上是 URL（路径）的一部分。但是我只能找到 REST-gRPC反向代理和各种解决方法。

我发现这篇文章与 AWS Lambda / API Gateway 相关，从那里看起来 GCF 不应该像 AWS 那样受到限制。

是否有在 Google Cloud Functions 中部署的 gRPC 示例？

我在 Golang 中有一个gRPC 服务器，它使用以下 ServerOptions 启用了 mTLS：

服务器对于 Golang 中的gRPC 客户端工作正常，但在证书交换握手后对于以下 gRPC c# 客户端失败。

这是跟踪日志：

有人可以帮我理解失败的原因吗？使用 SslCredentials 也会失败。xxxx 是出于隐私原因的 IP 替代品。

我正在尝试创建一个框架，在该框架中我将通过 REST API 接收请求并等待另一个服务（通过 gRPC 工作）来轮询并执行请求。这是必需的，因为“其他”服务非常深入地嵌入到网络中，我不能直接调用它。同时，我想将其他服务的输出缓冲回请求源。

有什么想法可以在 2 个不同的异步 API 请求之间共享这些数据吗？使用文件系统是一种方式......但我在想我可以通过渠道或其他方式做得更好......？

Let's say I am working in ServiceA which calls ServiceB. Now if ServiceB returns NotFound, AlreadyExists or InvalidArgument error codes, what should we return to the caller of ServiceA?

1. Based on documentation to gRPC error code, it looks like Internal is what we should return if

   invariants expected by the underlying system have been broken

   I am not very sure what this bold text means, does it mean any downstream error should be returned as Internal error code?

2. For example, NotFound documentation says:

   NotFound means some requested entity (e.g., file or directory) was not found

   Does that mean we should parse the downstream error and return NotFoundto the caller of ServiceA if ServiceB returns NotFound?

我的 grpc 服务器有一个日志拦截器，并且想为元数据添加一个值（我想在请求的整个生命周期内跟踪请求）：

但文档FromIncomingContext声明：

好的，所以我看一下复制功能并复制元数据：

并想“我如何将这个元数据附加回ServerStream上下文？”，然后我检查是否有一些ss.SetContext(newCtx)，但我没有看到任何类似的东西。我是从错误的角度考虑这个问题，还是我错过了其他东西？

我最近一直在尝试 gRPC 错误处理，并希望将我自己的 proto 消息传递给客户端（定义我自己的错误详细信息和内部错误代码）。在搜索之后，发现了几个使用 gRPC 状态包中的 WithDetails() 来附加自定义元数据的示例。我开始实施如下

gRPC 原型消息

服务器端实现

客户端实现

当我运行代码时，它命中了在服务器代码中添加的 Panic()，这意味着 WithDetails() 出错了。

为了进一步进行，消除了服务器端的恐慌，此客户端引发以下错误

问题：

• WithDetails() 是否仅适用于 googleapis/rpc/errdetails 标准 gRPC 原型定义而不适用于自定义原型？

• 查看 proto 文件和代码实现，我没有看到任何特定于 gRPC errdetails 包的内容。

• 当我尝试使用此包中的 proto 消息时，它工作正常。

[注意：我使用的是gogo protobuf]

任何人都可以告诉我我在这里缺少什么吗？

我原来的用例：

我正在使用gRPC服务器（使用protobuf）在 GO 中构建应用程序，并将其包装在 HTTPS 服务器中（使用gin）。只有 HTTPS 服务器被发布到客户端以供使用（我的意思是我的应用程序可以通过 REST API 访问，然后实际上在 gRPC 端点上拨号），我使用SwaggerOpenAPI3 发布它（版本 3 是主要的这里的要求）规范。gRPC 和 HTTPS 都是必需的，任何解决方案都应遵循此架构。

我不想在两个地方维护我的服务器规范，即我不想同时维护 proto 文件 ( .proto) 和 swagger 规范 ( .json/.yaml)。由于我绝对必须编写 proto 文件来生成 gRPC 服务器，因此我想自动化 swagger 规范生成 (OpenAPI3)。

我在哪里：

我可以使用grpc-gateway库swagger从 protobuf 文件 () 生成 OpenAPI2 规范，如下所示： grpc-rest-go-example。但我的要求是 OpenAPI3；更具体地说，我想使用OpenAPI3 中的功能并从proto 的功能映射到它。这在 OpenAPI2 中是不可能的，因为它不允许 API 具有多个类型定义的请求/响应主体，这是 OpenAPI3 通过启用 oneOf、anyOf 和 allOf 构造添加的功能。.protooneOfoneof

在尝试这样做时，我偶然发现了 GoogleAPIs googleapis/ gnostic 的这个库，它的描述是：

此存储库包含一个 Go 命令行工具，可将 JSON 和 YAML OpenAPI 描述与等效的协议缓冲区表示形式相互转换。

乍一看，这似乎完全解决了我的问题，但事实证明，这个库只在协议缓冲区 (protobuf) 二进制 ( .pb) 和 swagger OpenAPI2/OpenAPI3 ( .json/.yaml) 文件之间相互转换，这让我想到了我的新问题。

例如，对于以下.pb文件：

它生成以下招摇文件：

.pb可能无法正确查看，请在此处访问。所以像：

好像：

对于上面的示例，我首先编写了 swagger 规范，然后生成了.pb同样的方法，但反过来也可以。

当前状态：

如果我有办法在 ( .pb) 和 ( .proto) 文件之间进行转换，则转换循环将关闭并完成 ( .proto-> .pb-> .json/.yaml-> .pb-> .proto)。

我确信必须有一种方法来实现这一点，因此我的原始问题存在解决方案。但是我找不到任何可以做到这一点的文章或代码。是否有健全的方法可以在文件之间进行相互.pb转换.proto？

如果您对我的原始用例有完全不同的解决方案，也请随时分享。这会有很大帮助。

提前致谢！

编辑：

(1) 感谢最近的评论，很明显，在.pb和之间进行“转换”.proto首先是一个荒谬的问题。但最初的问题仍然存在，即如何.proto使用注释、标签或其他方式从 protobuf 文件 () 生成 swagger3 (OpenAPI3) 规范。相应地更改问题标题。

(2) 就在我发布这篇文章的第二天，我碰到了gnostic-grpc存储库，其中的描述说：

此工具将 OpenAPI v3.0 API 描述转换为 gRPC 服务的描述，该服务可用于使用 gRPC-JSON 转码实现该 API。

同样，这让我过早退出。实际上，这是一个 GSOC 项目，尽管这个存储库的想法令人惊叹，但它并不能满足要求。此外，这不是一个相互转换的库，对于任何生产用途都非常不成熟。事实上，它未能提供 OpenAPI3 规范的一些基本特性。

但是这个存储库正朝着正确的方向前进。我的结论是有一个自定义插件可以做到这一点，主要是通过扩展 GO 中的注释库。

(3) 显然，除了gnostic-grpc还非常不成熟，并且正在为任何类型的实际用途进行大量工作之外，没有好的和明显的候选者可以转换.proto为 OpenAPI3 规范 ( )。.yaml/.json

但是对于反向转换，即 OpenAPI3 spec ( .yaml/.json) to .proto，在 OpenAPITools 下有一个名为openapi-generator的好库，它可以将 OpenAPI v2/3 规范转换为几乎所有平台的客户端/服务器存根。但由于这不是最初的问题，所以问题仍然悬而未决。