Важно: здесь мы разбираем только кейс с получением tickers. Мы не разбираем доп API с /show-tickers
Технологии:
- gRPC стриминг для эффективной передачи данных
- Около 100 серверов API рассчитано по пропускной способности сети (120 КБ/с на клиента)
То есть именно этот сервис будет subscriber’ом на redis и он делают агрегацию по tickers для клиентов. Также они держат соединения между клиентами и нашей системой.
Далее разберем формат подключения от клиентов до API сервисов
- GeoDNS нужен для выбора ближайшего LB к клиенту
- API Gw выполняет несколько ролей:
- auth
- Для браузеров будет менять формат соединения с gRPC-Web (об этом далее) на gRPC. Или чисто WebSocket
- Распределение нагрузки на какой-то из сервисов (так как L7, то можно задействовать Api GW, а можно поставить до LB L7)
Немного про виды gRPC:
В gRPC есть несколько режимов взаимодействия между клиентом и сервером:
- Unary (однонаправленный вызов): клиент отправляет один запрос, сервер отвечает одним ответом.
- Server streaming: клиент отправляет один запрос, сервер возвращает поток сообщений.
- Client streaming: клиент отправляет поток сообщений, сервер отвечает одним ответом.
- Bidirectional streaming: и клиент, и сервер обмениваются потоками сообщений одновременно.
gRPC streaming — это режимы server streaming или bidirectional streaming, позволяющие передавать данные непрерывно без необходимости открывать новое соединение. Именно эти режимы используем.
- Почему именно такие виды? Так как клиенту нужно иногда делать запросы, если он хочет поменять тикеры. В остальное время клиент “слушает” изменения от системы
Для браузеров будем использовать gRPC-Web, чтобы также использовать все плюсы HTTP 2.0. Но если в рамках тестирования мы увидем, что latency на переупаковку слишком большой — для Web клиентов делаем WebSocket.