Использование GRP C в качестве внутренней коммуникации архитектуры микроуслуг - PullRequest
0 голосов
/ 01 апреля 2020

У меня есть система, реализующая архитектуру микросервисов. У меня есть API-шлюз, отвечающий за предоставление внешнего набора наших API через REST. Этот API-шлюз после вызова каждого необходимого микросервиса для получения информации объединяется на уровне DTO API-шлюза для отправки клиентам. Связь между шлюзом API и микросервисами осуществляется через GRP C. Чтобы сделать это, я сталкиваюсь с первым преобразованием, мне нужно преобразовать те DTO, упомянутые выше, в слой DTO Protobuff. Когда вызов Grp c достигает микросервисов, я сталкиваюсь со вторым раундом конвертации, мне нужно конвертировать из DTO Protobuff в Entity, связанный с моделью микросервисов. Первый вопрос здесь: имеет ли смысл эти два процесса преобразования? Есть ли способ оптимизировать это? Переход к возможному ответу. Есть несколько возможных решений, упомянуть два:

  • Я мог бы использовать те же DTO Protobuff для предоставления в REST API шлюзом. Я хочу избежать этого, потому что DTO Protobuff реализуют больше деталей, чем я хочу поделиться с моими клиентами.

  • Я мог бы сериализовать DTO шлюза API и отправить их в микросервис через Grp * 1020. *, инкапсулируя в байтовый массив, продукт сериализации, внутри Protobuff как универсальное поле c bytes . Я использую эту возможность в качестве опции le git, поскольку весь наш код написан на одном языке (Java). Второй вопрос: что вы, ребята, думаете об этом подходе?

...