Отреверсили проприетарный gRPC и выложили в опенсорс 100% совместимый аналог их сервера, потом CLI

17.09.2026 11:00:17 | Хабр

Хабы: Блог компании h3llo.cloud, Open source, IT-инфраструктура, DevOps

А вы тоже организуете общение между микросервисами по HTTP/1.1 + JSON? Так вот, адекватные люди на хайлоаде давно так не делают.

Как это выглядит в классическом REST: какой-нибудь сервис заказов стучится в сервис оплаты и отдаёт JSON-файлик: {"user_id": 123, "amount": 1000}. Принимающий сервис этот текст читает, парсит, валидирует, переводит в машинный код...

JSON сделан для людей. Человеку удобно читать JSON, потому что это текст. Но серверу для обработки текста приходится тратить драгоценные такты процессора на поиск и разбиение. Ещё классический HTTP тащит за собой гигантские заголовки с метаданными. Часто они весят больше, чем сама полезная нагрузка. Ещё если вы передаете число 123456789, в JSON оно займёт 9 байт (по байту на символ), а в бинарном виде — всего 4 байта.

Гугл ещё в 90-х это посчитал. Они со своими масштабами столкнулись с проблемами за 10 лет до того, как с ними столкнулся весь остальной мир. Для DNS-а в Гугле сделали внутреннюю систему Borg-NS. Они пытались сделать предка gRPC, чтобы решить две фундаментальные проблемы. Во-первых, зоопарк технологий. Когда у тебя тысячи микросервисов — одни на Java, другие на C++, третьи на Python, четвёртые на Go (ладно, этих тогда точно не было) — им нужен единый язык общения. Нужно было запилить стандарт: описали спецификацию интерфейса в одном независимом стиле — и система сама сгенерировала готовый сетевой код для всех нужных языков.

А во-вторых — это как раз производительность обмена.

Поэтому сейчас используется gRPC. И вот когда началась какая-то там по счёту волна санкций, внезапно выяснилось, что в России нет поддержки серверов gRPC.

Подробнее

Читайте также