我正在使用微服务架构创建一个系统。有两个微服务A和 B ，每个人都生活在自己的存储库中。
有一个user.proto包含 protobuf 定义和 gRPC 方法签名的文件。 A使用生成的 user.pb.go作为服务器。 B使用 user.pb.go作为客户(A)。
构造它的一种方法是在 A 中出现 proto 定义。 , 与 B对 A 有代码依赖:
A
├── pb
│ ├── user.proto
│ └── user.pb.go
└── service.go
B
└── service.go
B-->A
另一种方法是拥有另一个 repo
P包含原型(prototype)定义，带有 A和 B取决于新的 repo : A
└── service.go
B
└── service.go
P
├── user.proto
└── user.pb.go
A-->P
B-->P
或者新的 repo 可能只包含 proto 文件，并在 A 和 B 中生成代码:
A
├── service.go
└── pb
└── user.pb.go
B
├── service.go
└── pb
└── user.pb.go
P
└── user.proto
这里有什么更好的方法？
最佳答案
如果你的团队不喜欢 monorepo，我认为第三种选择是最合适的。 1 个用于 proto 文件的 repo。然后，它可以作为 git 子模块包含在 A 和 B 中(如果您使用的是 git)。 A 和 B 可以有自己的 protoc 脚本，生成的 protobuf 文件取决于他们使用的编程语言。
关于architecture - 微服务中的 grpc 组织，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/56082458/