Разработчики проекта nginx объявили (https://www.nginx.com/blog/nginx-1-13-10-grpc/) о включении (https://hg.nginx.org/nginx/rev/2713b2dbf5bb) в кодовую базу модуля с реализацией прокси для протокола gRPC (http://www.grpc.io/), позволяющего организовать работу микросервисов на различных языках программирования, которые взаимодействуют между собой при помощи универсального API. Сетевое взаимодействие в gRPC реализовано поверх протокола HTTP/2 и базируется на применении Protocol Buffers для сериализации данных. В настоящее время ведётся тестирование снапшотов (https://hg.nginx.org/nginx/) nginx с поддержкой gRPC и если не будет выявлено проблем, модуль gRPC будет интегрирован в выпуск nginx 1.13.10.Если раньше nginx мог лишь проксировать TCP-соединения gRPC, не разбирая содержимого запросов, то предложенный для тестирования модуль ngx_http_grpc_module даёт возможность управлять потоками gRPC, выделяя отдельные сервисы и методы. Например, появляется возможность маршрутизировать gRPC по разным бэкендам, в зависимости от запрошенной операции, блокировать или ограничивать интенсивность определённых вызовов, инспектировать трафик gRPC или организовывать балансировку нагрузки.
Возможна работа с использованием шифрования TLS или без (h2c cleartext), в том числе на базе nginx можно реализовать обёртку для применения шифрования и аутентификации для внутренних сервисов gRPC, изначально не поддерживающих такие возможности. Также nginx может выполнять роль межсетевого экрана для разграничения доступа или как единая точка входа, распределяющая обращение к разным сервисам и методам по связанным с ними бэкендам. Поддерживается применение различных схем балансировки нагрузки, например round-robin (круговой перебор, при котором соединения равномерно распределяются среди обработчиков), least-connections (запрос перенаправляется к менее нагруженному серверу), least_time (перенаправление на сервер, демонстрирующий наиболее высокую отзывчивость) и hash (перенаправление на основе хэша от определённого пользователем параметра, например, IP).Для настройки проброса реализована новая директива grpc_pass и введена в обиход схема URL "grpc://". Для маршрутизации вызовов могут применяться штатные блоки location. Например:
location /helloworld.Greeter {
grpc_pass grpc://192.168.20.11:50051;
}
location /helloworld.Dispatcher {
grpc_pass grpc://192.168.20.21:50052;
}
URL: https://www.nginx.com/blog/nginx-1-13-10-grpc/
Новость: https://www.opennet.dev/opennews/art.shtml?num=48283
Зачем микросервисы привязывать к single point of failure?
кто запрещает поставить ещё один nginx?
Убогая система лицензирования.
И чем же вам помешала BSD license?
если приложение работает за reverse-proxy nginxом, то без nginx оно все-равно недоступно. Поэтому можно этим же процессом и балансировать запросы далее. А трафик между frontend с nginxом и так как-нибудь да балансируется. Так что проблем нэма
и много кто пользует этот grpc? гошники?
Ага, Л.Седоля уволили за ненадобностью и он теперь серверы админит с голодухи...
Пускай в кс:го перекатывается, там нейросети пока не тащат.
В доту таки уже показали кто здесь папа, так что это не на долго.
> и много кто пользует этот grpc? гошники?Скорее крестовики. У go в стандартной библиотеке есть net/rpc.
Например, для андроид-приложения это самый удобный вариант - всё в коробке и унифицировано с гугловскими сервисами.
Не так давно Яндекс рассказывал про историю оптимизации своего сервиса поиска. Взаимодействие части микро-сервисов у них реализовано с помощью gRPC. https://www.youtube.com/watch?v=uilqCFLlZKY