Grpc微服务架构实现

Posted 2023-03-08

【中文标题】Grpc微服务架构实现

【英文标题】：Grpc microservice architecture implementation

【发布时间】：2017-12-26 04:54:35

【问题描述】：

在微服务架构中，是否建议集中收集 proto 文件并将它们作为客户端和服务器的依赖项？还是每个客户端和服务器只有 1 个 proto 文件？

【参考方案1】：

如果您的组织使用单一代码库（即，所有代码都存储在一个存储库中），我强烈建议使用同一个文件。另一种方法是仅复制文件，但您必须保持所有版本同步。

如果您在发送方和接收方之间共享协议缓冲区文件，您可以静态检查发送方和接收方是否使用相同的架构，特别是如果一些新的微服务将使用静态类型语言（例如 Java）编写.

另一方面，如果您没有单一的代码库，而是有多个存储库（例如，每个微服务一个），那么共享协议缓冲区文件会更加麻烦。您可以做的是将它们放在单独的存储库中，这些存储库可以作为依赖项添加到需要它们的微服务中。这是我在以前的公司看到的。我们有多个用于架构的小型 API 存储库。

所以，如果使用同一个文件很容易，我建议这样做而不是创建副本。但是，在某些情况下，复制它们更实际。缺点是您总是必须在所有副本上应用更改。在最好的情况下，您知道要更新哪些文件，那么这只是乏味的。在最坏的情况下，您不知道要更新哪些文件，并且您的架构将不同步。等代码放出来，你就会发现。

请注意，单体代码库并不意味着单体架构。您可以拥有微服务，并且仍然将所有源代码放在一个存储库中。著名的例子当然是谷歌。 Google 还大量使用协议缓冲区进行内部通信。我没有看到他们的源代码，但如果他们不在服务之间共享他们的协议缓冲区文件，我会感到惊讶。