Написано Навином М.

Фон

Как часть нашей команды по платформе Kubernetes, мы постоянно сталкиваемся с проблемой обеспечения прозрачности рабочих нагрузок пользователей в режиме реального времени. От мониторинга использования ресурсов до отслеживания активности кластера Kubernetes и состояния приложений — для каждой конкретной категории доступно множество решений с открытым исходным кодом. Однако эти инструменты часто разбросаны по разным платформам, что приводит к фрагментации пользовательского опыта. Чтобы решить эту проблему, мы воспользовались возможностями потоковой передачи на стороне сервера, что позволяет нам предоставлять информацию об использовании ресурсов, событиях Kubernetes и статусе приложений в реальном времени, как только пользователи получают доступ к порталу нашей платформы.

Введение

Реализуя потоковую передачу на стороне сервера, мы можем беспрепятственно передавать данные в пользовательский интерфейс, предоставляя актуальную информацию без необходимости ручного обновления или постоянных вызовов API. Этот подход революционизирует взаимодействие с пользователем, позволяя пользователям мгновенно визуализировать состояние и производительность своих рабочих нагрузок в унифицированном и упрощенном виде. Будь то мониторинг использования ресурсов, получение информации о событиях Kubernetes или отслеживание состояния приложений, наше решение потоковой передачи на стороне сервера объединяет всю важную информацию на единой информационной панели в режиме реального времени, но это будет применимо для всех, кто хочет предоставлять данные потоковой передачи в реальном времени в пользовательский интерфейс.
Прошли те времена, когда приходилось использовать множество инструментов и платформ для сбора важной информации. Благодаря нашему оптимизированному подходу пользователи могут получить доступ к комплексному обзору своей среды Kubernetes в тот момент, когда они попадают на портал нашей платформы. Используя возможности потоковой передачи на стороне сервера, мы изменили способ взаимодействия пользователей с рабочими нагрузками и их мониторинга, сделав их работу более эффективной, интуитивно понятной и продуктивной.
В нашей серии блогов мы стремимся познакомить вас с тонкостями настройки потоковой передачи на стороне сервера с помощью таких технологий, как React.js, Envoy, gRPC и Golang.

В этом проекте задействованы три основных компонента:
1. Бэкэнд, разработанный с использованием Golang и использующий потоковую передачу данных на стороне сервера gRPC.
2. Прокси-сервер Envoy, который отвечает за доступность серверной службы для внешнего мира.
3. Интерфейс, построенный с использованием React.js и использующий grpc-web для установления связи с серверной частью.
Серия разделена на несколько частей, чтобы учесть разнообразные языковые предпочтения разработчиков. Если вас конкретно интересует роль Envoy в потоковой передаче или вы хотите узнать о развертывании прокси-сервера Envoy в Kubernetes, вы можете перейти ко второй части (Envoy как внешний прокси-сервер в Kubernetes) и изучить этот аспект или просто заинтересоваться интерфейсную часть, то вы можете просто просмотреть интерфейсную часть блога.
В этой начальной части мы сосредоточимся на самом простом сегменте серии: «Как настроить потоковую передачу на стороне сервера gRPC с помощью Go». Мы собираемся показать примеры приложений с потоковой передачей на стороне сервера. К счастью, в Интернете доступно множество материалов по этой теме, адаптированных к предпочитаемому вами языку программирования.

ЧАСТЬ 1. Как настроить потоковую передачу на стороне сервера gRPC с помощью Go

Пришло время претворить наш план в жизнь! Предполагая, что у вас есть базовое понимание следующих концепций, давайте углубимся в реализацию:

1. gRPC: это протокол связи, который позволяет клиенту и серверу эффективно обмениваться данными.
2. Потоковая передача на стороне сервера: эта функция особенно полезна, когда серверу необходимо отправить большой объем данных клиенту. Используя потоковую передачу на стороне сервера, сервер может разделить данные на более мелкие части и отправлять их один за другим. Затем клиент может прекратить получение данных, если он получил достаточно или ждал слишком долго.

Теперь давайте начнем с реализации кода.

Шаг 1. Создайте файл прототипа
Для начала нам нужно определить файл protobuf, который будет использоваться как клиентской, так и серверной стороной. Вот простой пример:

syntax = "proto3";

package protobuf;

service StreamService {
  rpc FetchResponse (Request) returns (stream Response) {}
}

message Request {
  int32 id = 1;
}

message Response {
  string result = 1;
}

В этом файле прототипа у нас есть единственная функция под названием FetchResponse, которая принимает параметр Request и возвращает поток ответных сообщений.

Шаг 2. Создайте файл буфера протокола

Прежде чем продолжить, нам нужно сгенерировать соответствующий файл pb, который будет использоваться в нашей программе Go. Каждый язык программирования имеет свой собственный способ создания файла буфера протокола. В Go мы будем использовать библиотеку протоколов.
Если вы еще не установили его, вы можете найти руководство по установке, предоставленное Google.
Чтобы создать файл буфера протокола, выполните следующую команду:

protoc --go_out=plugins=grpc:. *.proto

Теперь у нас есть файл data.pb.go, готовый к использованию в нашей реализации.

Шаг 3. Реализация на стороне сервера
Чтобы создать файл сервера, следуйте приведенному ниже фрагменту кода:

package main

import (
        "fmt"
        "log"
        "net"
        "sync"
        "time"

        pb "github.com/mnkg561/go-grpc-server-streaming-example/src/proto"
        "google.golang.org/grpc"
)

type server struct{}

func (s server) FetchResponse(in pb.Request, srv pb.StreamService_FetchResponseServer) error {

        log.Printf("Fetching response for ID: %d", in.Id)

        var wg sync.WaitGroup
        for i := 0; i 



В этом серверном файле я реализовал функцию FetchResponse, которая принимает запрос от клиента и отправляет обратно поток ответов. Сервер имитирует параллельную обработку с помощью горутин. На каждый запрос он передает клиенту пять ответов. Каждый ответ задерживается на определенную продолжительность для имитации разного времени обработки.

Сервер прослушивает порт 50005 и регистрирует StreamServiceServer на созданном сервере. Наконец, он начинает обслуживать запросы и регистрирует сообщение, указывающее, что сервер запущен.

Теперь у вас есть файл сервера, готовый обрабатывать потоковые запросы от клиентов.


  
  
  Часть 2


Ждите части 2, где мы продолжим погружаться в захватывающий мир потоковой передачи данных и то, как она может революционизировать ваш пользовательский интерфейс.