[БЕЗ_ЗВУКА] В прошлых
видео мы успешно связывали между собой несколько сервисов по протоколу grpc.
Однако иногда есть желание сделать http интерфейс к вашему grpc сервису,
потому что для вашего целевого языка нет генераторов protobuf файлов,
либо же вы не хотите усложнять и идти дальше простого http.
В этом случае в экосистеме grpc есть утилита под названием grpc-gateway,
которая позволяет сгенерировать Reverse Proxy до вашего сервиса,
который будет принимать в себя json по http обычному,
а в ваш сервис будет доходить уже по grpc и возвращать соответственно тоже json.
Давайте посмотрим, каким образом это получается на практике.
Итак, вот есть наш сервис AuthChecker,
уже знакомый вам, и методы Create, Check, Delete.
И мы расширяем эти методы при помощи некоторых опций,
в данном случае это google.api.http опция.
И в этой опции мы указываем, что post и url,
что body мы принимаем прямо целиком, либо, например,
проверку сессии мы осуществляем через get и параметры указываем прямо в самом url.
Сам плагин для grpc gateway
умеет обрабатывать эти опции и создаст вам,
сгенерирует файл, где будет обвязка,
которая будет делать routing и ходить в ваш уже сервер по grpc.
Рассмотрим генерацию.
Итак, вот генерация самого protobuf файла, самого grpc сервиса.
Следующим идет генерация уже http обвязки для вашего сервиса,
и наконец описание для сваггера, то есть документация.
Итак, попробуем сгенерировать это все.
Так, создали сервис,
создали обвязку и создали сваггер-описание.
Давайте посмотрим немножко на то, что нам сгенерировалось в обвязке.
Итак, сгенерировался довольно большой такой файл, на 300 строк почти.
У него есть свой серверный мультиплексор,
своя валидация и много своих небольших утилит.
Но вы туда погружаться не будете.
Вот, например, в любом мультиплексоре он
принимает POST — это для метода Create, принимает валидация, функция,
которой все это вызывается и которая потом идет уже внутрь вашего сервиса.
Не будем смотреть на автогенерированный код, посмотрим,
как это использовать дальше на практике.
Теперь посмотрим уже непосредственно сервис,
который будет использовать этот код.
Итак, вот я подключаю как раз свою сессию, где у меня все сгенерировано.
И я стартую прямо в одном сервисе и grpc сервис,
куда будет входить моя proxy, и саму proxy.
grpc сервис — тут ничего интересного нет, мы это уже видели.
Я слушаю сокет по TCP и регистрирую свой SessionManager в обработчиках.
Далее, в HTTPProxy я подключаюсь к grpc, устанавливаю соединение.
Потом я создаю мультиплексор, серверный мультиплексор,
для обработки запросов уже от grpc-gateway.
В нем я регистрирую свой уже клиент к моему
AuthChecker, то есть я передаю туда контекст, в котором сейчас ничего нет.
указываю, в какой мультиплексор зарегистрировать, и какой grpc-коннект.
Далее я объявляю свой собственный уже мультиплексор, стандартный,
стандартный в http.
И все запросы на /v1/session/ я отправляю уже в grpc.
То есть я могу совмещать.
У вас необязательно должен быть всего одна proxy на один сервис.
Вы можете сделать в одной proxy доступ ко множеству
сервисов или непосредственно уже к вашей бизнес-логике.
И начинаю уже слушать сокет по http.
Итак, давайте это запустим.
Запускаем.
Так.
Отлично, у меня стартовал gRPC сервер на порту 8081 и HTTP сервер на порту 8080.
Теперь я возьму подготовленные выражения для доступа к этому сервису.
Обратите внимание: я даже не запрашиваю их из браузера,
а просто дергаю api через curl.
Скопировали.
Открываем терминал.
Вставляем.
Обратите внимание: я создал свой сервис, создал себе сессию,
получилась ID, я получил теперь эту сессию и теперь удалил.
Вот, пожалуйста,
буквально небольшими силами мы создали HTTPProxy до grpc сервиса.
Теперь все ваши старые клиенты, которые не хотят тащить за собой какие-то
непонятные библиотеки, могут ходить в ваш микросервис просто по http.
Еще у нас остался не разобранным файл для сваггера,
которому мы посвятим следующее видео.
