微服务中的grpc组织

Question

我正在使用微服务架构创建系统。有两个微服务A和B，每个都位于自己的存储库中。

有一个user.proto包含protobuf定义和gRPC方法签名的文件。用作服务器的A用途user.pb.go。B使用user.pb.go作为（一个客户A）。

一种构造方法是在中出现原型定义A，并B具有对以下内容的代码依赖性A：

 A
 ??? pb
 ?   ??? user.proto
 ?   ??? user.pb.go
 ??? service.go
 B
 ??? service.go

B-->A

另一种方法是使用另一个P包含原始定义的回购，A并B取决于新的回购：

 A
 ??? service.go
 B
 ??? service.go
 P
 ??? user.proto
 ??? user.pb.go

A-->P
B-->P

或者，新的仓库可能只包含原始文件，并且在A和B中都生成了代码：

 A
 ??? service.go
 ??? pb
     ??? user.pb.go
 B
 ??? service.go
 ??? pb
     ??? user.pb.go
 P
 ??? user.proto

这里有什么更好的方法？

Answer 1

第二种方法更好。

为什么？因为当您添加服务 C 时，它会自然地与 A 和 B 内联。任何现有组件都不需要更改导入路径代码。

是的，第三种方法可以声明这一点，但它会user.pb.go在每个微服务中复制生成的内容。最好进行整合以避免重复。

您还可以在存储库的顶层（即 A 和 B 级别）使用 go 的内部包功能。重命名P为可确保此子包可供、（或等）internal使用，但不会邀请其他第三方包引用此“内部”包。ABC