在微服务架构中组织protobuf文件

问题描述

在我的公司中，我们有一个由微服务组织的系统，每个服务都有专用的git存储库.我们想介绍gRPC，我们想知道如何共享protobuf文件并为我们的各种语言构建库.根据我们收集的一些示例，我们最终决定在内部存放所有protobuf的单个存储库，这似乎是最常用的存储方式，并且似乎更易于维护和使用.

In my company, we have a system organized with microservices with a dedicated git repository per service. We would like to introduce gRPC and we were wondering how to share protobuf files and build libs for our various languages. Based on some examples we collected, we decided at the end to go for a single repository with all our protobuf inside, it seems the most common way of doing it and it seems easier to maintain and use.

我想知道您是否有一些例子?您是否有一些相反的例子，说明公司做相反的事情，即以分布式方式托管protobuf?

I would like to know if you have some examples on your side ?Do you have some counter examples of companies doing the exact opposite, meaning hosting protobuf in a distributed way ?

推荐答案

我们为原型文件(称为schema)提供了一个单独的存储库，为每个微服务提供了多个存储库.同样，我们从不存储生成的代码.服务器和客户端文件是由protoc在CI上的每次构建过程中从头开始生成的.

We have a distinct repo for protofiles (called schema) and multiple repos for every microservice. Also we never store generated code. Server and client files are generated from scratch by protoc during every build on CI.

实际上，这种方法可以很好地满足我们的需求.但是有两个潜在的陷阱:

Actually this approach works and fits our needs well. But there are two potential pitfalls:

1. schema与微服务存储库之间的不一致.提交到两个不同的git repos并不是原子的，因此，在schema更新时，总是有一点时间在更新schema时，而微服务的repo还没有.
2. 如果使用Go，则可能会转移到Go 1.11中引入的Go模块.我们尚未对此进行全面研究.

1. Inconsistency between schema and microservice repositories. Commits to two different git repos are not atomic, so, at the time of schema updates, there is always a little time period when schema is updated, while microservice's repo is not yet.
2. In case if you use Go, there is a potential problem of moving to Go modules introduced in Go 1.11. We didn't make a comprehensive research on it yet.

这篇关于在微服务架构中组织protobuf文件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！