gRPC API с буферами протоколов
В прошлой статье мы создали дизайн API для приложения для социальных сетей. Мы написали определение пяти конечных точек REST для сообщения с использованием протокольных буферов, а также аннотации HTTP для каждой конечной точки. Мы также сгенерировали код для реализации обратного прокси-сервера с помощью плагина grpc-gateway.
В этой статье мы продолжим создание API, а следующим шагом будет реализация обратного прокси.
Если вы пропустили предыдущую статью, рекомендую читать статьи в следующем порядке:
- Дизайн Go API с протокольными буферами и gRPC
- Создание обратного прокси-сервера (gRPC-Gateway)
- 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
указанной версии.
И последнее, прежде чем мы создадим сервис, добавьте .env
file с вашим токеном доступа 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.
Оставайтесь с нами, и спасибо за чтение!