Все это время я писал REST API. Я знал, что есть несколько других способов для этой цели, но я никогда не пробовал ни одного из них. Тем временем я слышал о gRPC, который является коммуникацией следующего уровня по HTTP / 2.
Итак, я подумал о том, чтобы поделиться своим опытом о gRPC. Эта статья посвящена тому, как я узнаю о gRPC. В статье будет серия эпизодов. Это Эпизод 01, где я пишу об основном вступлении о gRPC.
Улучшение межсервисного взаимодействия - это то, что мы делаем, как инженеры-программисты (разработчики API). Когда мы начинаем рассматривать варианты межсервисного взаимодействия, мы выделяем два основных.
- REST (R презентационный S tate T ransfer)
- RPC (R эмоция P процедура C все)
REST (R презентационный S tate T ransfer)
Отправляет ресурсы туда и обратно и манипулирует этими ресурсами
RPC (R эмоция P процедура C все)
Это отличается от REST, потому что REST основан на ресурсах, а RPC основан на функциях и процедурах.
В любом случае ожидания от обоих вариантов одинаковы.
Почему RPC, чем REST?
REST использует для связи текстовые сообщения и семантику HTTP.
RPC имеет следующие функции, которые сделают его более понятным при взаимодействии со службами.
- Это сфокусированные на действиях
- Использует семантику программирования
- Он использует сообщения на основе двоичного кода (очень маленький по сравнению с текстом в REST)
Некоторые факты о gRPC
- Он поддерживает кроссплатформенность
- Масштабируемость
- Он обеспечивает потоковую передачу - не предназначен для одного запроса и ответа, он может управлять фрагментом запросов и ожидать одного ответа или отправлять один запрос и ожидать фрагментов ответов.
- Бесплатно и открыто - нет платы за использование, и исходный код есть для вас.
- Это быстро и эффективно
В конечном счете
gRPC позволяет всем другим различным технологиям (языкам) общаться друг с другом изначально, не зная, на каком языке написана служба.
Структура gRPC
Как мы все знаем, большинство систем состоит из одного сервера и одного клиента. На самом деле это не обязательно должно быть похоже на карту «один к одному», у него может быть несколько серверов и несколько клиентов.
Сервер отвечает за обработку запроса и соответствующий ответ.
Клиент отвечает за отправку запроса на сервер и ожидает ответа.
в gRPC и сервер, и клиент будут иметь сгенерированный код, который разрешает соединение между клиентом и сервером. Преобразование кода на желаемый язык абстрагируется под этим сгенерированным кодом.
А транспортный уровень поможет, подключив эти сгенерированные коды со стороны клиента и со стороны сервера. Этот уровень будет передавать сообщения туда и обратно и позволяет клиенту и серверу обмениваться данными.
Жизненный цикл gRPC
Создание канала - это первое, что нужно сделать. Это только разовый процесс. После создания канала вы можете использовать его для связи на протяжении всего жизненного цикла приложения.
Затем создается клиент, который является обязательным компонентом. Он инициирует запрос, который должен быть отправлен на сервер. Этот запрос может быть встроен с метаданными. Одна из основных целей отправки и получения метаданных - это подтверждение связи. Аутентификация - один из примеров.
Наконец, в жизненном цикле сообщения будут отправляться туда и обратно.
Усилия по стандартизации поддерживались браузерами Chrome, Opera, Firefox, [11], Internet Explorer 11, Safari, Amazon Silk и Edge. [12] Большинство основные браузеры добавили поддержку HTTP / 2 к концу 2015 года. [13] Около 98% используемых веб-браузеров имеют такую возможность, [14], в то время как, по данным W3Techs, по состоянию на август 2020 года, 47% 10 миллионов веб-сайтов поддерживали HTTP / 2. [15]
gRPC поддерживает HTTP / 2, поэтому его стоит изучить и попрактиковаться.
Поговорим об аутентификации
gRPC - Аутентификация
Это не проверка подлинности на уровне пользователя или отклонение и разрешение функций в зависимости от роли пользователя. Эта аутентификация - это механизм, который используется для распознавания клиента и сервера, чтобы иметь безопасное соединение.
Просто это значит узнавать друг друга и знать, что они общаются безопасно.
gRPC имеет 4 различных механизма аутентификации.
- Небезопасный - не имеет каких-либо мер безопасности.
- SSL / TLS
- Аутентификация на основе токенов Google
- Поставщики услуг пользовательской аутентификации
Давайте обсудим каждое из вышеперечисленных отдельно.
Ненадежный
Здесь клиент и сервер будут общаться друг с другом поверх HTTP / 1. Это в основном текстовое общение. Мне не нужно акцентировать внимание на риске, когда я общаюсь таким образом, но я часто использую это в среде разработки. Не рекомендуется использовать в производстве. Чтобы использовать этот механизм, особого обращения не будет. Это означает, что нам не нужно обращаться к каким-либо центрам сертификации для проверки сертификатов.
SSL / TLS
Когда у нас есть SSL / TLS в качестве механизма аутентификации, наши данные, передаваемые туда и обратно, защищены. Здесь используется HTTP / 2. HTTP / 2 обменивается информацией быстрее и эффективнее, чем HTTP / 1. Итак .. Это преимущество тоже есть. Другое дело, что клиент проверяет сертификаты (клиент связался с центром сертификации, чтобы узнать, действителен ли сертификат).
Аутентификация на основе токенов Google
Этот механизм должен быть поверх механизма безопасной аутентификации. Это означает, что аутентификация на основе токенов Google работает поверх SSL / TLS.
Обычай
Когда мы говорим о настраиваемой аутентификации, на ум приходит OAuth. В любом случае это еще не поддерживается gRPC. Это указанный язык, вы можете разработать свой собственный.
Параметры связи gRPC
Мы также можем называть их типами сообщений. Здесь мы можем узнать 4 метода опций.
- Унарный - простой запрос и ответ
- Серверная потоковая передача - серверная потоковая передача данных обратно клиенту
- Клиентская потоковая передача - клиентская потоковая передача данных на сервер.
- Двунаправленная потоковая передача
Унарный RPC
Это действует как обычный ответ на запрос на клиенте и сервере. Клиент может создать запрос к серверу. Сервер обработает его и отправит ответ. Таким образом, это будет один запрос и один ответ в вызове процедуры.
rpc methodName(RequestType) returns (ResponseType)
для этого требуется тип запроса и тип ответа даже при отсутствии данных.
Сервер потоковой передачи RPC
Здесь конвейер ответа на запрос остается таким же, как указано выше. Но вместо одного запроса и ответа сервер может отправлять множество ответов во время обработки запроса или после завершения обработки запроса. Просто то, что он делает, - это потоковая передача данных обратно клиенту.
Пример: потоковое видео
rpc methodName(RequestType) returns (stream ResponseType)
Клиент потоковой передачи RPC
Это обратная потоковая передача на сервере. Я начну с примера. Подумайте о сценарии загрузки, как будто мы должны отправить несколько фрагментов на сервер для обработки. Особенность заключается в том, что сервер ждет, пока он не получит полный запрос, и в конце сервер отправит один ответ.
rpc methodName(stream RequestType) returns (ResponseType)
Двунаправленный потоковый RPC
Это немного безумие, потому что и запросы, и ответы происходят асинхронно. Массив данных можно отправлять по одному, а массив данных будет отправляться обратно по одному в качестве ответа.
rpc methodName(stream RequestType) returns (stream ResponseType)
На этом мы завершаем этот эпизод. Я поймаю вас еще одной статьей, в которой объясняется, как я пробовал использовать gRPC с Node js.
