gRPC

gRPC - это современная высокопроизводительная среда RPC с открытым исходным кодом, которая может работать в любой среде. Она может эффективно соединять службы внутри и между центрами обработки данных с помощью подключаемой поддержки для балансировки нагрузки, трассировки, проверки работоспособности и аутентификации. Она также применима в последней миле распределенных вычислений для подключения устройств, мобильных приложений и браузеров к внутренним службам.

Основные сценарии использования:

  • Эффективное подключение сервисов полиглотов в микросервисной архитектуре
  • Подключение мобильных устройств, клиентов браузера к бэкенд-сервисам
  • Генерация эффективных клиентских библиотек

Основные функции, которые делают его потрясающим:

  • Идиоматические клиентские библиотеки на 10 языках
  • Высокоэффективный на проводе и с простой структурой определения сервиса
  • Двунаправленная потоковая передача с использованием транспорта на основе http/2
  • Подключаемая аутентификация, трассировка, балансировка нагрузки и проверка работоспособности

Многие компании уже используют gRPC для подключения нескольких сервисов в своей среде. Вариант использования варьируется от подключения нескольких сервисов к сотням сервисов на разных языках в локальных или облачных средах.

История gRPC

Google использует единую инфраструктуру RPC общего назначения под названием Stubby для подключения большого количества микросервисов, работающих в центрах обработки данных Google, в течение более десяти лет. Внутренние системы Google уже давно используют микросервисную архитектуру, набирающую популярность сегодня. Stubby поддерживает все межсервисные соединения Google на протяжении более десяти лет и является основой RPC для каждой службы Google, которую вы используете сегодня. В марте 2015 года в Google решили создать новую версию Stubby в открытом доступе, чтобы Google могли поделиться своими знаниями с отраслью и сотрудничать с ними для создания следующей версии Stubby как для микросервисов внутри и вне Google, так и для последней мили вычислений (мобильный, интернет и IOT) - так появился gRPC.

Комментарии

Отправить комментарий

Популярные сообщения из этого блога

Язык поисковых запросов в Graylog

Изображение
Синтаксис языка поисковых запросов в Graylog Синтаксис поиска очень близок к синтаксису Lucene. По умолчанию все поля сообщения включены в поиск, если вы не указали поле сообщения, в котором проводить поиск. Сообщения, содержащие термин ssh : ssh Сообщения, содержащие термин ssh или login : ssh login Сообщения, содержащие точную фразу ssh login : "ssh login" Сообщения, в которых поле type содержит ssh : type:ssh Сообщения, в которых поле type включает в себя ssh или login : type:(ssh login) Сообщения, в которых поле type содержит точную фразу ssh login : type:"ssh login" Сообщения с полем type : _exists_:type Сообщения, которые не имеют поля type : NOT _exists_:type Сообщения, которые соответствуют регулярному выражению ethernet[0-9]+ в поле type type:/ethernet[0-9]+/ По умолчанию все термины или фразы в поисковом запросе связаны между собой по логическому типу OR (ИЛИ), поэтому возвращаются все
Далее...

Хэш-таблица: разрешение коллизий

Изображение
Хэш-коллизии практически неизбежны при хэшировании случайного подмножества большого набора возможных ключей. Например, если 2450 ключей хэшируются в миллион корзин (buckets), даже при совершенно равномерном случайном распределении, в соответствии с проблемой дня рождения, существует приблизительно 95% вероятность того, что по крайней мере два ключа будут хэшированы в один и тот же слот. Поэтому почти все реализации хэш-таблиц имеют некоторую стратегию разрешения коллизий для обработки таких событий. Некоторые общие стратегии описаны ниже. Все эти методы требуют, чтобы ключи (или указатели на них) были сохранены в таблице вместе со связанными значениями. Отдельная цепочка В методе, известном как отдельная цепочка , каждая корзина (bucket) независима и имеет своего рода список записей с одинаковым индексом. Время для операций с хэш-таблицами - это время нахождения корзины (bucket) (которое является постоянным) плюс время для операции со списком. В хорошей хэш-таблице каждая корзина (
Далее...

Нормальные формы, пример нормализации в базе данных

Изображение
Кодд представил концепцию нормализации и то, что сейчас известно как первая нормальная форма (1NF) в 1970 году. Кодд продолжал определять вторую нормальную форму (2NF) и третью нормальную форму (3NF) в 1971 году, также Кодд и Рэймонд Ф. Бойс определили нормальную форму Бойса-Кодда (BCNF) в 1974 году. Неформально отношение реляционной базы данных часто описывается как "нормализованное", если оно соответствует третьей нормальной форме. Большинство отношений 3NF не содержат аномалий вставки, обновления и удаления. Нормальные формы (от наименее нормализованных до наиболее нормализованных): UNF: ненормализованная форма 1NF: первая нормальная форма 2NF: вторая нормальная форма 3NF: третья нормальная форма EKNF: Элементарный ключ, нормальная форма BCNF: нормальная форма Бойса-Кодда 4NF: четвертая нормальная форма ETNF: нормальная форма основного кортежа 5NF: пятая нормальная форма DKNF: нормальная форма ключа домена 6NF: шестая нормальная форма UNF (1970) 1NF (1
Далее...