gRPC: введение

gRPC - это современный фреймворк RPC с открытым исходным кодом, изначально разработанный в Google. Он использует буферы протокола в качестве языка описания интерфейса, protobuf - это механизм для сериализации структурированных данных. Вы просто определяете свои сервисы и их структуру данных в файле proto, а gRPC автоматически генерирует клиентские и серверные заглушки для вашего сервиса на различных языках и платформах. Использование profobuf позволяет нам общаться с использованием двоичного кода вместо JSON, что делает gRPC намного быстрее и надежнее. Некоторые из других ключевых функций gRPC - это двунаправленная потоковая передача и управление потоком, блокирующие или неблокирующие привязки и подключаемая аутентификация. gRPC использует HTTP / 2, который использует мультиплексирование, с помощью которого клиент и серверы могут инициировать несколько потоков в одном базовом TCP-соединении. Подробнее о gRPC можно прочитать здесь.

gRPC-web

gRPC-Web - это библиотека javascript, с помощью которой мы можем напрямую общаться со службой gRPC через веб-браузер. Клиенты gRPC-Web подключаются к службам gRPC через специальный прокси-сервер шлюза (прокси-сервер Envoy), который в нашем случае будет службой докеров, работающей на том же сервере, который связывает GRPC (HTTP / 2) с связью с браузером (HTTP / 1.1).

Это изменило правила игры, потому что изначально мы могли использовать gRPC только для связи между сервисами или микросервисами, а клиент мог использовать только вызовы REST API для доступа к данным, но теперь, используя gRPC, мы можем использовать возможности gRPC во всем нашем приложении и исключить REST

Почему gRPC лучше, чем REST

Основные различия между REST и gRPC:

  • Тип полезной нагрузки, REST использует JSON, а gRPC использует Protobuff
  • Протокол передачи, REST использует HTTP / 1.1, а gRPC использует HTTP / 2

Поскольку мы используем Protobuf в gRPC, нам не нужно заботиться о глаголах (GET, PUT), заголовках и т. Д. Кроме того, он сокращает код сериализации, который мы должны писать для всех моделей данных, заглушек, сгенерированных платформой gRPC. заботится об этом.

Поскольку мы используем HTTP / 2 в gRPC, теперь мы можем выполнять потоковую передачу как запросов, так и ответов и избавляться от проблем с задержкой, блокировки заголовка строки и сложности в установлении TCP-соединений.

Необходимые инструменты и программное обеспечение

  • Protoc v3.6.1 - компилятор Protobuf для создания клиентских и серверных заглушек.
  • go v1.11 - Наш сервер будет построен с использованием go lang.
  • NodeJS - для создания внешнего интерфейса Vue.JS.
  • Докер - для запуска прокси-сервера посланника.

Структура папки

Обзор тем, которые необходимо обсудить

  1. Создание прото файла
  2. Создание заглушек сервера и написание обработчиков служб gRPC
  3. Создание сервиса gRPC
  4. Создание прокси-сервиса Envoy
  5. Создание клиентских заглушек и клиентского приложения

1. Прото файл

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

В первой строке файла указывается версия прото-буфера, которую мы собираемся использовать, то же имя пакета, которое мы указали во второй строке, также будет использоваться в сгенерированном файле go. В нашем todoService у нас есть три метода RPC addTodo, deleteTodo, getTodos с типами запросов в качестве аргументов и типами ответов в качестве типа возврата метода RPC. Для каждого типа сообщения мы указываем теги, такие как=1, =2, которые являются уникальными тегами, которые будут использоваться во время кодирования и декодирования. Ключевое слово repeated означает, что поле может повторяться любое количество раз.

2. Создать файл-заглушку сервера

Следующим шагом после создания нашего прото-файла является создание заглушек сервера, с помощью которых мы будем создавать наш сервер gRPC. Мы собираемся использовать protoc для создания файлов-заглушек, используйте команду ниже из корня проекта.

protoc -I todo/ todo/todo.proto --go_out=plugins=grpc:todo

В приведенной выше команде мы указываем нашу выходную папку как todo/, а входной файл - как todo/todo.proto, а также указываем имя плагина и имя пакета для сгенерированного файла-заглушки. после выполнения вышеуказанной команды вы можете найти новый файл с именем todo.pb.go внутри папки todo.

Теперь нам нужно написать методы-обработчики для всех наших методов RPC, указанных в файле proto, мы будем создавать новый файл handler.go внутри той же папки todo.

Для простоты я не собираюсь использовать какую-либо базу данных для хранения и извлечения наших задач. Поскольку мы находимся в одном сгенерированном пакете задач, я могу использовать типы данных запроса и ответа из сгенерированных файлов-заглушек. Все наши методы-обработчики привязаны к структуре сервера.

В функции обработчика addTodo я использую пакет UUID для создания уникального идентификатора для каждой задачи, создания объекта задачи и добавления его в список Todos в структуре сервера.

В функции GetTodoshandler я просто возвращаю список Todos внутри структуры сервера.

В функции обработчика deleteTodo я просто выполняю операцию поиска и удаления с использованием идентификатора задачи и обновляю список Todos в структуре сервера.

3. Подключите сервер gRPC

Теперь нам нужно подключить весь обработчик и запустить сервер gRPC, мы собираемся создать новый файл server.go в корне нашего проекта.

В приведенном выше файле мы создаем новый сервер на порту 14586, пустой экземпляр сервера задач и новый сервер gRPC, мы используем RegisterTodoService для регистрации нашей службы задач на вновь созданном сервере gRPC, а затем обслуживаем созданный сервер gRPC.

Чтобы запустить указанный выше файл, используйте go run server.go из корня проекта, который запустит сервер gRPC.

4. Настройка прокси для Envoy.

Прокси-сервер Envoy будет службой докеров, которая будет находиться между нашим сервером и клиентскими приложениями, ниже приведены файлы докеров прокси-сервера посланника и файлы конфигурации.

Наша служба todo gRPC будет работать на порту 14586, а Envoy будет перехватывать трафик HTTP 1.1 на 8080 и перенаправлять его на 14586 как HTTP2 (GRPC).

Чтобы построить контейнер Docker

sudo -E docker build -t envoy:v1 .

Чтобы запустить прокси-сервер envoy, запустите контейнер докера, используя

sudo docker run  -p 8080:8080 --net=host  envoy:v1

5. Интерфейсное приложение Vue.js

Теперь единственной недостающей частью является клиент, мы собираемся использовать фреймворк Vue.js для создания нашего клиентского веб-приложения, для простоты мы рассмотрим только методы, которые отвечают за добавление и удаление задач.

Создайте проект Vue.js с помощью vue-cli

vue create todo-client

Это создает новую папку с именем todo-client в корне нашего проекта. Затем мы должны создать клиентские заглушки.

Используйте приведенную ниже команду для создания клиентских заглушек.

protoc --proto_path=todo --js_out=import_style=commonjs,binary:todo-client/src/ --grpc-web_out=import_style=commonjs,mode=grpcwebtext:todo-client/src/ todo/todo.proto

Приведенная выше команда создаст два файла todo_pb.js и todo_grpc_web_pb.js в папке src. Для простоты я собираюсь охватить только те части, где используется клиент службы gRPC.

import { addTodoParams, getTodoParams, deleteTodoParams } from "./todo_pb";
import { todoServiceClient } from "./todo_grpc_web_pb";

В компоненте todo нашего клиентского приложения импортируем все необходимые типы данных из todo_pb.js и клиента из todo_grpc_web_pb.js, затем мы создаем новый экземпляр клиента, используя todoServiceClient, и используем URL-адрес localhost с портом, который мы настроили для прослушивания прокси-сервером нашего посланника в качестве URL-адреса сервера. и сохраните экземпляр клиента.

Выше приведены методы, подключенные к компонентам: нажмите кнопку добавления задачи и щелкните значок задачи удаления. Мы просто используем наши клиентские заглушки для выполнения наших сервисов gRPC и используем заглушки типов данных, а также их сеттеры и геттеры для обработки данных, которые должны быть отправлены / получены с сервера.

Заключение

Спасибо, что нашли время прочитать это до конца😁, Если у вас есть какие-либо вопросы относительно этого или чего-то, что я должен добавить, исправить или удалить, не стесняйтесь комментировать ниже.

Если вам действительно понравилось читать, не забудьте нажать на значок хлопка.

Вы можете найти полный исходный код в этом репо и подписаться на меня на GitHub и LinkedIn.