Определение RPC для gRPC - PullRequest
Новая
       16

Определение RPC для gRPC

0 голосов
/ 12 сентября 2018

Я ищу несколько предложений здесь. Вариант использования - это сетевое устройство (например, маршрутизатор) с сетевыми операциями, выполняемыми через gRPC.

Допустим, есть "n" объекты модели, такие как маршрутизатор, интерфейсы, объекты конфигурации маршрутизации, такие как OSPF и т. Д. Каждая сетевая операция, например, в конечном счете, выполняется CRUD для одного или многих объектов модели.

Теперь, при определении этого через службу gRPC, кажется, есть 2 варианта:

  1. Определите общие RPC gRPC, такие как "SET" и "GET". Параметр будет список объектов и операций. Как SET ((маршрутизатор, обновление), (интерфейс, обновление) ..

  2. Определите очень специфические RPC. Как и "setInterfaceProperty_x", "createOSPFInstance" .. И таких RPC может быть много.

С помощью # 2 мы создаем интеллект приложения в самих RPC. Каждой новой функции могут потребоваться новые RPC из этой службы.

С # 1 средства RPC являются средством, но интеллект находится в приложении, которое использует RPC в контексте. Список RPC будет очень небольшим и не изменится со временем.

Какой предпочтительный подход? Общие RPC (и их очень мало) или имеют десятки (или более) RPC, управляемых операциями? Я вижу, что некоторые проекты с открытым исходным кодом, такие как P4Runtime, используют подход № 1.

Спасибо за ваше время. Я могу предоставить больше информации, если требуется.

1 Ответ

0 голосов
/ 17 сентября 2018

Вы должны использовать вариант № 2.Это помещает ваш интерфейсный интерфейс в протокол, а не в ваше приложение.Вы оставляете себе много открытых дверей, выбирая вариант № 2, который был бы громоздким или не поддерживал бы в противном случае:

  • Если определение API объекта не соответствует внутреннему представлению, вам нужно определить отображениемежду двумя.Предположим, вы обновили свой внутренний код, чтобы больше не нуждаться в InterfaceProperty, и вместо этого он был перемещен в новое поле с именем BetterInterfaceProperties.Вариант 1 заставит вас оставить старое поле доступным, а вариант 2 позволит вам переосмыслить вызов и сделать правильные вещи.
  • Мелкозернистые элементы управления доступом легче с определенными методами.Все пользователи могут установить publicProperty, но только администраторы могут установить dangerousProperty.Сгруппировав все поля в один вызов (как в # 1), ваш вызывающий абонент должен переосмыслить сообщения об ошибках, в то время как опция # 2 более понятна, почему авторизация не удалась.
  • Меньшие возвращаемые значения.Наличие метода, подобного getSpecificProperty, будет выполнять гораздо меньше работы, чем getFullObject.Поскольку ваша модель данных становится все более сложной, вам придется включать все больше данных в ответные сообщения.Даже если звонящий заботится только об одном, им приходится ждать их всех.Рассмотрим приложение базы данных.Базы данных, возможно, придется выполнить несколько ненужных запросов, чтобы заполнить поля, которые клиент никогда не будет читать.

Есть причина использовать # 1, но они не так важны, пока вы не определите, какие свойства объединяютсяи логически один RPC.(например, Get)

...