带有protobuf文件的grpc的典型组织答案

【问题标题】：typical organization of grpc with protobuf files带有protobuf文件的grpc的典型组织
【发布时间】：2018-03-15 05:53:30
【问题描述】：

我正在使用 gRPC 在服务和 protobuf 序列化之间进行通信。我以前没有真正使用过 RPC，我想知道 proto 文件的最佳结构是什么？目前，我在一个产品中拥有所有原型文件，具有以下示例布局：

protos/
  identity/
    models/
      Member.proto
    MemberService.proto
  vault/
    models/
      Authentication.proto
      Session.proto
      HttpHeader.proto
    AuthenticationService.proto

我认为我应该将模型与实际的服务定义分开，这样我就可以导入单个模型而不需要整个服务。

那么，每个服务都有如下布局

synatx "proto3";

import "models/Session.proto"

message GetRequest {
  uint64 member_id;
}

message GetResponse {
  Session session;
}

rpc AuthenticationService {
  get (GetRequest) returns (GetResponse);
}

有没有更规范的方法来做到这一点？我应该在与我的服务相同的文件中包含模型“消息”定义吗？ import "../protos-gen/AuthenticationService.grpc.h 只使用单个 Authentication.proto 模型似乎很奇怪。

【问题讨论】：

标签： protocol-buffers rpc grpc

【解决方案1】：

通常，人们将他们的服务定义放在他们的消息原型旁边。只有当protos变得非常大时，人们才会将它们分解，但这种情况很少见。

构建 protos 的规范方法是拥有一个高级根目录，并通过绝对路径引用所有 protos，甚至是同一目录中的兄弟姐妹。将服务与消息类型分开的主要原因是生成的代码是否变得太大。这并不常见。

【讨论】：

所以标准方式实际上就是“protos/{AuthenticationService.proto,MemberService.proto,xyzService.proto}”，然后将所有内容都放入服务文件中。这似乎很奇怪，然后我不能只传递消息而不导入整个服务，但我很欣赏这种洞察力。
根据我的经验，人们没有很大的接口，所以 proto 文件从来没有真正变得那么大。如果需要，您可以将服务部分从消息中拆分出来，但将它们保存在同一个 proto 包和同一个目录级别中。