Когда рассказывают про интеграции и про API, обычно сервер рисуют как черный ящик. Вот в него входят HTTP-запросы, дальше говорим про URI, параметры, схемы данных.
Но для новичков иногда непонятно, чем отличаются разные технологии. Однажды на тренинге по интеграциям мне задали вопрос: про Кафку мы поняли, её нужно ставить как дополнительное ПО. А вот gRPC — он тоже ставится на отдельный сервер?..
Тут, кажется, стоит вернуться к основам, попробовал нарисовать.
Клиент обращается к серверу (1). Сервер — это компьютер, у него есть сетевая карта (или даже несколько), у карты есть IP-адрес. На него из сети приходит запрос. В запросе указан порт.
Операционная система смотрит по своей таблице портов, в какой из запущенных сервисов отправить этот запрос (2). На одном порту отвечает только один сервис. Всего TCP-портов может быть 65535, то есть один сервер может отвечать по-разному на разных портах. Связь порта и сервиса называется биндинг, приложение при запуске пытается этот биндинг создать и дальше "слушать" порт, то есть ждать из него сообщений.
Стандартные порты — HTTP:80, HTTPS:443. То есть, всё, что приходит на 443, будет отправлено в HTTP-сервер, если он запущен. HTTP-сервер может быть встроен в приложение бекэнда, а может быть отдельным сервисом. Как правило, из соображений безопасности и производительности, в промышленном контуре HTTP-сервер отдельный. HTTP-сервер устанавливает зашифрованное соединение, проверяет корректность запроса и доступы.
Дальше он пытается выполнить запрос. Есть три основных варианта:
— просто отдать файл, лежащий на диске (3.1). Это называется "статика" — обычно это картинки или другие медиа, документы, HTML-страницы, стили, JS-скрипты. Статика отдается очень быстро (зависит от размера, конечно). Структура URL при этом не должна повторять структуру реальных папок на диске — мэппинг настраивается на HTTP-сервере.
— выполнить скрипт, лежащий на диске (3.2). Эта технология называется CGI. Веб-сервер запускает скрипт, и отдает клиенту результат выполнения. Скрипт при этом может обращаться к БД или ещё что-то делать — это обычная программа. Так работают многие PHP-фреймворки. У HTTP-сервера должен быть установлен мод для запуска скриптов на конкретном языке (Perl, PHP и т.д.). На каждый запрос запускается свой отдельный экземпляр скрипта в отельном потоке.
— передать запрос запущенному в памяти сервису (3.3) — приложению бэкенда (в UNIX-подобных системах он ждет запросов тоже по TCP, на каком-нибудь порту. Поэтому легко разнести HTTP-сервер и сервер приложений на разные машины, если понадобится). В сервере приложений в ответ на входящий запрос запускается функция роутинга всех входящих запросов, которая парсит заголовок запроса и вызывает соответствующую функцию (метод) у себя внутри (4). Эта функция уже делает всё, что нужно, чтобы обработать запрос и выдать ответ: обращается к БД (5) или к внешним сервисам (6) — тогда ваш сервер приложений работает частично как шлюз API.
Всё это может работать на одной машине, а когда нагрузка растет — мы разносим их по разным: HTTP-сервер, сервер приложений, СУБД.
Теперь, где работает GraphQL? GraphQL — это замена вашему фреймворку для обработки вызовов на сервере приложений. Есть три варианта: встроить в ваш фреймворк — тогда ваш сервер приложений по одному из эндпоинтов будет отвечать как GraphQL; поставить отдельно в параллель вашему серверу приложений; поставить перед ним, как API-шлюз.
Где gRPC? gRPC работает вместо вашего фреймворка, занимающегося парсингом входящих сообщений. HTTP-сервер, если он есть, будет проксировать TCP-трафик на ваш сервер, где его ловит gRPC и вызывает нужные процедуры.
Когда рассказывают про интеграции и про API, обычно сервер рисуют как черный ящик. Вот в него входят HTTP-запросы, дальше говорим про URI, параметры, схемы данных.
Но для новичков иногда непонятно, чем отличаются разные технологии. Однажды на тренинге по интеграциям мне задали вопрос: про Кафку мы поняли, её нужно ставить как дополнительное ПО. А вот gRPC — он тоже ставится на отдельный сервер?..
Тут, кажется, стоит вернуться к основам, попробовал нарисовать.
Клиент обращается к серверу (1). Сервер — это компьютер, у него есть сетевая карта (или даже несколько), у карты есть IP-адрес. На него из сети приходит запрос. В запросе указан порт.
Операционная система смотрит по своей таблице портов, в какой из запущенных сервисов отправить этот запрос (2). На одном порту отвечает только один сервис. Всего TCP-портов может быть 65535, то есть один сервер может отвечать по-разному на разных портах. Связь порта и сервиса называется биндинг, приложение при запуске пытается этот биндинг создать и дальше "слушать" порт, то есть ждать из него сообщений.
Стандартные порты — HTTP:80, HTTPS:443. То есть, всё, что приходит на 443, будет отправлено в HTTP-сервер, если он запущен. HTTP-сервер может быть встроен в приложение бекэнда, а может быть отдельным сервисом. Как правило, из соображений безопасности и производительности, в промышленном контуре HTTP-сервер отдельный. HTTP-сервер устанавливает зашифрованное соединение, проверяет корректность запроса и доступы.
Дальше он пытается выполнить запрос. Есть три основных варианта:
— просто отдать файл, лежащий на диске (3.1). Это называется "статика" — обычно это картинки или другие медиа, документы, HTML-страницы, стили, JS-скрипты. Статика отдается очень быстро (зависит от размера, конечно). Структура URL при этом не должна повторять структуру реальных папок на диске — мэппинг настраивается на HTTP-сервере.
— выполнить скрипт, лежащий на диске (3.2). Эта технология называется CGI. Веб-сервер запускает скрипт, и отдает клиенту результат выполнения. Скрипт при этом может обращаться к БД или ещё что-то делать — это обычная программа. Так работают многие PHP-фреймворки. У HTTP-сервера должен быть установлен мод для запуска скриптов на конкретном языке (Perl, PHP и т.д.). На каждый запрос запускается свой отдельный экземпляр скрипта в отельном потоке.
— передать запрос запущенному в памяти сервису (3.3) — приложению бэкенда (в UNIX-подобных системах он ждет запросов тоже по TCP, на каком-нибудь порту. Поэтому легко разнести HTTP-сервер и сервер приложений на разные машины, если понадобится). В сервере приложений в ответ на входящий запрос запускается функция роутинга всех входящих запросов, которая парсит заголовок запроса и вызывает соответствующую функцию (метод) у себя внутри (4). Эта функция уже делает всё, что нужно, чтобы обработать запрос и выдать ответ: обращается к БД (5) или к внешним сервисам (6) — тогда ваш сервер приложений работает частично как шлюз API.
Всё это может работать на одной машине, а когда нагрузка растет — мы разносим их по разным: HTTP-сервер, сервер приложений, СУБД.
Теперь, где работает GraphQL? GraphQL — это замена вашему фреймворку для обработки вызовов на сервере приложений. Есть три варианта: встроить в ваш фреймворк — тогда ваш сервер приложений по одному из эндпоинтов будет отвечать как GraphQL; поставить отдельно в параллель вашему серверу приложений; поставить перед ним, как API-шлюз.
Где gRPC? gRPC работает вместо вашего фреймворка, занимающегося парсингом входящих сообщений. HTTP-сервер, если он есть, будет проксировать TCP-трафик на ваш сервер, где его ловит gRPC и вызывает нужные процедуры.
