Большинство бизнес-приложений, которые используются сегодня, взаимодействуют друг с другом с помощью HTTP 1.1 и REST. Это стало стандартом в отрасли благодаря своей простоте и почти не требует усилий для интеграции приложений.
Однако, как только ваше приложение переходит на уровень обработки миллиона запросов в секунду и более, недостатки вышеупомянутого механизма становятся очевидными. Давайте сначала обратимся к ним -
Без мультиплексирования
Одно соединение HTTP 1.1 может использоваться только для отправки одного запроса и ответа за раз. Это соединение блокируется до получения ответа, что крайне неэффективно.
Ограниченное сжатие
Заголовки HTTP 1.1 не сжимаются, что приводит к ненужному увеличению размера данных запроса. В HTTP / 2 они сжимаются с использованием алгоритма HPACK, который имеет степень сжатия 99%.
Текстовая передача
HTTP 1.1 основан на тексте, что крайне неэффективно для передачи данных. Для них требуются сложные синтаксические анализаторы, а также они не поддерживают высокий уровень сжатия.
HTTP 2 был создан, чтобы избавиться от всех этих ограничений. Он поддерживает мультиплексирование, которое позволяет клиенту отправлять несколько параллельных запросов по одному соединению. Заголовки сжимаются с использованием алгоритма сжатия HPACK и передают двоичные данные.
В статье ниже приводится подробное сравнение с показателями производительности для обоих протоколов.
В этой статье мы рассмотрим, как можно использовать HTTP / 2 в своей службе. В настоящее время самый популярный способ сделать это - использовать gRPC от Google.
gRPC
Проще говоря, это веб-фреймворк, используемый для подключения нескольких сервисов с помощью HTTP / 2. В настоящее время его используют сотни компаний для эффективного подключения микросервисов.
Сервисы gRPC отличаются от REST тем, что они предоставляют не конечные точки, а методы / процедуры. Клиент просто вызывает метод, как если бы он реализован локально, а в фоновом режиме на сервер отправляется вызов RPC, который содержит фактическую реализацию метода.
Интерфейс сервиса и его методы определены в файле .proto. Это связано с тем, что gRPC использует буферы протокола для передачи данных между различными службами, а также для создания клиентских и серверных заглушек. Это приводит к увеличению скорости сериализации и десериализации на порядок.
Вызов RPC выполняется через HTTP / 2. Это позволяет пользователям gRPC автоматически использовать все функции вышеуказанного протокола.
Давайте создадим простой сервис Hello World в gRPC с использованием Java. Приведенный здесь пример можно найти на https://grpc.io/docs/quickstart/java/.
Определите услугу
Сначала мы определяем интерфейс службы в файле .proto. Назовем этот файл greeter.proto
Мы называем сервис Greeter. Этот сервис содержит метод SayHello. Метод принимает объект HelloRequest и возвращает объект HelloReply.
Затем мы определяем формат HelloRequest и HelloReply ProtocolBuffers.
Сгенерируйте интерфейсы
Затем мы сгенерируем интерфейс службы и клиентскую заглушку с помощью компилятора protobuf. Создайте свой обычный Java-проект maven. Затем скопируйте файл greeter.proto в папку src / main / proto.
Как только он появится, мы можем использовать прототип компилятора maven для генерации классов Java из этого файла.
Классы будут сгенерированы в каталоге target / generated-sources / protobuf.
Внедрить услугу
Теперь мы можем расширить сгенерированный служебный интерфейс для реализации методов.
Реализуйте клиента
Теперь клиенты могут просто вызвать этот метод sayHello, и служба вернет ответ через HTTP / 2.
Запускаем сервер
Вы можете использовать сервер, связанный с grpc, или вы можете использовать внешние фреймворки, которые уже предоставляют привязки grpc, такие как Vert.x Java
Теперь вы успешно реализовали базовую службу gRPC.
Балансировки нагрузки
Нетривиальная часть запуска службы http / 2 в производственной среде - это балансировка нагрузки. gRPC нарушает стандартную балансировку нагрузки на уровне соединения, то есть создает новое соединение с другим экземпляром для запроса, который по умолчанию предоставляется в Kubernetes или HAProxy. Это связано с тем, что gRPC построен на HTTP / 2, а HTTP / 2 предназначен для одного долговременного TCP-соединения.
Решение состоит в том, чтобы выполнить балансировку нагрузки на уровне запроса. Это означает создание долговременных подключений, а затем распределение запросов по этим подключениям.
Самый простой и эффективный способ сделать это - использовать linkerd2. Это сервисная сетка, которая может работать рядом с вашим Kubernetes / Mesos или любым другим кластером. Linkerd2 служит прокси для входящего запроса. Поскольку он написан на ржавчине, он добавляет очень минимальную задержку (‹1 мс) и запросы балансировки нагрузки между хост-машинами, которые он может обнаружить через k8s API или DNS.
В Linkerd2 не нужно ничего настраивать, он по умолчанию обрабатывает трафик HTTP 1 и 2.
Если вы хотите узнать больше о gRPC, linkerD или http / 2, вы можете перейти по ссылкам ниже:
- Балансировка нагрузки gRPC на Kubernetes без слез
- HTTP / 2: разница между HTTP / 1.1, преимущества и способы его использования
- GRPC Java - Основы
Свяжитесь со мной в LinkedIn или Twitter или напишите письмо на [email protected]
