Организация протобуф файлов в микросервисной архитектуре - PullRequest
5 голосов
/ 20 марта 2019

В моей компании у нас есть система, состоящая из микросервисов с выделенным git-репозиторием для каждой службы. Мы хотели бы представить gRPC, и нам было интересно, как делиться файлами protobuf и создавать библиотеки для наших различных языков. Основываясь на собранных нами примерах, мы решили в конце концов создать единый репозиторий со всеми нашими протобуфами, который кажется наиболее распространенным способом, и его легче поддерживать и использовать.

Я хотел бы знать, есть ли у вас примеры на вашей стороне? У вас есть несколько примеров того, как компании делают прямо противоположное, то есть хостинг protobuf в распределенном режиме?

Ответы [ 2 ]

3 голосов
/ 20 марта 2019

Каждый из наших микросервисов имеет свой собственный API (protobuf или несколько файлов protobuf).Для каждого API у нас есть отдельный репозиторий.Также у нас есть CI-работа, которая встраивает протоклассы в jar (и не только для Java, но и для другого языка) и публикует его в нашем центральном репозитории.Чем вы просто добавляете зависимости в API, который вам нужен.

Например, у нас есть микросервис A, у нас также есть репозиторий a-api (содержит только протофайлы), который встраивается по заданию в jar (и на другие языки)com.api.a-service.<version>

1 голос
/ 29 марта 2019

У нас есть отдельное репо для протофайлов (называемое schema) и несколько репо для каждого микросервиса. Также мы никогда не храним сгенерированный код. Файлы сервера и клиента создаются с нуля protoc во время каждой сборки на CI.

На самом деле этот подход работает и хорошо соответствует нашим потребностям. Но есть две потенциальные ловушки:

  1. Несоответствие между schema и микросервисными репозиториями. Коммиты для двух разных репозиториев git не являются атомарными, поэтому во время schema обновлений всегда есть небольшой период времени, когда обновляется schema, в то время как репо микросервисов еще нет.
  2. В случае, если вы используете Go, существует потенциальная проблема перехода на модули Go, представленные в Go 1.11. Мы еще не провели всестороннее исследование этого вопроса.
...