31 lines
2.8 KiB
Markdown
31 lines
2.8 KiB
Markdown
---
|
||
aliases:
|
||
tags:
|
||
- maturity/🌱
|
||
date: 2024-04-12
|
||
---
|
||
- Подходит для [[../../../../wiki/zero/Микросервисная архитектура|микросервисных архитектур]] для межсервисного общения.
|
||
|
||
## Как работает?
|
||
![[../../meta/files/images/Pasted image 20241103005832.png]]
|
||
|
||
- **Шаг 1**: Клиент отправляет REST-запрос. Тело запроса обычно в формате JSON.
|
||
- **Шаги 2 - 4**: Сервис заказов (gRPC-клиент) получает REST-запрос, преобразует запрос в компактный бинарный формат и передает его в транспортный слой
|
||
- **Шаг 5**: gRPC отправляет пакеты по сети через HTTP/2. Благодаря бинарному кодированию и сетевым оптимизациям, gRPC считается в 5 раз быстрее, чем JSON.
|
||
- **Шаги 6 - 8**: Сервис оплаты (gRPC-сервер) получает пакеты из сети, декодирует их и вызывает серверное приложение.
|
||
- **Шаги 9 - 11**: Результат возвращается от серверного приложения, кодируется и передаётся на транспортный уровень.
|
||
- **Шаги 12 - 14**: Сервис заказов получает пакеты, декодирует их и отправляет результат в клиентское приложение.
|
||
## Проблемы
|
||
**Балансировка нагрузки L7 vs L4**: Kubernetes обычно использует балансировку нагрузки на уровне 4 (L4), которая перенаправляет трафик на основе информации IP и порта. Однако gRPC полагается на HTTP/2, что требует балансировки на уровне 7 (L7) для эффективного распределения запросов. Это может потребовать дополнительных настроек или использования специализированных ингресс-контроллеров, поддерживающих HTTP/2.
|
||
***
|
||
## Мета информация
|
||
**Область**:: [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]]
|
||
**Родитель**:: [[Remote Procedure Call|RPC]], [[Протоколы коммуникаций]]
|
||
**Источник**::
|
||
**Автор**::
|
||
**Создана**:: [[2024-04-12]]
|
||
### Дополнительные материалы
|
||
-
|
||
### Дочерние заметки
|
||
<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
|