gRPC API с буферами протоколов

В прошлой статье мы создали дизайн API для приложения для социальных сетей. Мы написали определение пяти конечных точек REST для сообщения с использованием протокольных буферов, а также аннотации HTTP для каждой конечной точки. Мы также сгенерировали код для реализации обратного прокси-сервера с помощью плагина grpc-gateway.

В этой статье мы продолжим создание API, а следующим шагом будет реализация обратного прокси.

Если вы пропустили предыдущую статью, рекомендую читать статьи в следующем порядке:

  1. Дизайн Go API с протокольными буферами и gRPC
  2. Создание обратного прокси-сервера (gRPC-Gateway)
  3. Go API — подключение к базе данных

Мы будем использовать docker и docker-compose, поэтому я рекомендую сначала установить docker и docker-compose и убедиться, что вы можете запускать контейнеры.

Перейдите к своему GOPATH, если вы не знаете, какой у вас каталог пути перехода, вы можете запустить echo $GOPATH, и это напечатает правильный путь. Там создайте структуру папок src/github/com/yaairfernando, заменив последний каталог вашим дескриптором GitHub. Как только вы окажетесь там, создайте следующую структуру проекта:

mkdir socialMedia
cd socialMedia
touch docker-compose.yaml

Хорошо, давайте начнем с определения yaml-файла docker-compose.

Из приведенного выше файла yaml мы определяем службу proxy, из конфигурации этой службы мы видим, что имя контейнера — proxy, а образ, который будет использоваться, — sma:proxy, в случае, если образ докера не существует, он будет создан его из папки ./proxy, мы также передаем в качестве аргументов токен доступа GitHub, это необходимо только в том случае, если вы создали приватное репо для дизайна API из предыдущей статьи.

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

Мы также указываем команду и две переменные среды для запуска: одну, чтобы указать оставшийся порт, на котором будет работать сервер, и URL-адрес grpc, который указывает на службу, которую прокси-сервер будет передавать запросы.

Мы также указываем, что порт, который эта служба будет предоставлять, — 9094, а внутри — 8081.

Давайте теперь создадим папку прокси и файл main.go:

mkdir proxy
cd proxy
touch main.go

Внутри папки прокси мы запустим эту команду, чтобы создать модуль go

go mod init github.com/yaairfernando/proxy

Это создаст файл go.mod в папке прокси.

module github.com/yaairfernando/proxy
go 1.18

Файл main.go выглядит так:

Основная функция только инициализирует новый сервер, передавая grpcURL, restPort и вызывая метод start на экземпляре сервера.

Давайте посмотрим, как выглядит файл сервера. Создайте папку сервера и файл server.go.

mkdir server
cd server
touch server.go

В этом файле сервера есть вся логика для регистрации обработчика ресурса Posts, добавления простого регистратора, создания HTTP-сервера и прослушивания указанного порта.

  • В строке 36 мы создаем новый серверный мультиплексор
  • В строке 38 мы обернули этот сервер простым регистратором.
  • В строке 40 регистрируем все обработчики. В нашем случае у нас есть только один для ресурса Posts на данный момент.
  • Наконец, в строках 45–49 мы создаем HTTP-сервер, передающий обработчик, и начинаем слушать

Как видите, некоторые вспомогательные функции в этом файле не определены. Я добавил их в файл utils.

Хорошо, теперь создадим Dockerfile:

Я не буду углубляться в то, что делает этот файл докера, но по сути он использует образ Golang в качестве сборщика, устанавливает некоторые переменные среды go, устанавливает рабочий каталог и копирует файл go.mod. После этого он загружает все зависимости, копирует остальные файлы и, наконец, устанавливает точку входа.

Это файл go.mod со всеми используемыми пакетами.

Это окончательная структура папок для проекта:

Мы почти закончили. Теперь давайте загрузим нужные нам пакеты go, выполнив следующие команды в папке прокси:

go mod download
go mod tidy

Как видите, для пакета sma мы указали, что нам нужна версия v0.1.0 из этого пакета, но когда мы создавали дизайн API, мы не создавали никаких версий. Давайте сделаем это.

Создать тег Git

Вернитесь туда, где у вас есть проект sma, и давайте создадим тег:

git tag v0.1.0

И отправляем в репозиторий:

git push origin v0.1.0

Теперь, вернувшись в папку proxy, запустите эту команду, чтобы загрузить эту версию пакета sma:

go get github.com/yaairfernando/[email protected]

Приведенная выше команда загрузит пакет sma указанной версии.

И последнее, прежде чем мы создадим сервис, добавьте .envfile с вашим токеном доступа GitHub на случай, если ваш репозиторий для дизайна API является частным.

GITHUB_ACCESS_TOKEN=your_gihub_access_token

Сборка Docker-сервиса

Теперь мы можем создать прокси-сервис, выполнив следующую команду в корневой папке:

docker-compose up --build -d proxy

При выполнении этой команды вы получите некоторые ошибки, говорящие о загрузке некоторых пакетов, которые мы указали в файле go.mod. Просто загрузите пакеты, запустив go mod download package_path. И повторно запустите команду docker-compose.

После завершения сборки мы должны увидеть работающий контейнер. Отправить POST-запрос на http://localhost:9094/v1/posts пока не получится, но лог можно посмотреть.

Это все для этой статьи. Мы реализовали обратный прокси. В следующей статье мы продолжим создание API.

Оставайтесь с нами, и спасибо за чтение!