Question

我正在将具有json序列化的基于REST的服务迁移到具有protobuf序列化的基于grpc的服务。这是一个Java服务。我在项目中有一些资源，看起来像下面的内容（下面提供了一个示例）：

ProductResource.java (v1/Products)

 1. GetProduct (v1/Products/Get)
 2. UpsertProduct (v1/Products/Upsert)
 3. Delete Product (v1/Products/delete)

SupermarketResource.java (v1/SuperMarket)

 1. GetShopkeepers (v1/SuperMarket/GetShopkeepers)
 2. GetAllProducts  ""
 3. UpsertShopkeepers  ""

在我当前基于REST的项目中，我有两个资源类-ProductResource和SupermarketResource，我可以在这些类中添加更多资源方法。在将它们转换为grpc时，我有两个选择，对于上述原型文件，我有两个选择，

resource.proto-所有资源都在一个原始文件中

  rpc GetProduct (Request) returns (Response); 
  rpc UpsertProduct (Request) returns (Response); 
  ..
  ..
  rpc GetShopkeepers (Request) returns (Response)
  ..

当我使用protoc编译器生成存根时，这将创建一个名为resourceImpl.java的impl类，在其中可以实现所有rpc方法。我在这里担心的是，由于所有rpc方法在一个类中的实现，使得impl类变得非常大。因此，我需要将方法实现移到单独的处理程序类中，以便该类中的代码

Product.proto，supermarket.proto

Product.proto
  rpc GetProduct (Request) returns (Response); 
  rpc UpsertProduct (Request) returns (Response); 
  ..
============== 

Supermarket.proto 
 rpc GetShopkeepers (Request) returns (Response)
 ..

当我使用协议编译器生成存根时，这将创建多个impl类，例如productResourceImpl.java，SuperMarketResourceImpl.java等，可以在其中实现所有rpc方法。为每个资源创建多个原型文件是否正确？

Google在他们的文档中说：

我们建议每个服务一个文件及其相应的请求和响应。考虑将此文件命名为.proto。对于仅具有资源的原始文件，请考虑将该文件简单命名为resources.proto。

但是然后他们似乎并不总是遵循自己的API（例如https://github.com/googleapis/googleapis/tree/master/google/streetview/publish/v1）

他们的文档没有明确说明如何在一项服务中处理多个资源，从而使生成的代码更简洁-https://cloud.google.com/apis/design/resource_names

最佳的项目结构是什么？我们目前大约有6-7个资源类，每个资源类中都有2-3个资源方法，但看不到数量过早/迅速增加。任何开源项目链接也将非常有用。

基于grpc + Protobuf的服务的项目结构

0 个答案: