Какие технологии используются для обмена сообщениями в реальном времени (real-time)?

А, ну ты про то, как серверу с клиентами в реальном времени общаться? Давай разжую, только не ори, что я слишком умно говорю. Тут, в общем, вариантов — как говна за баней, но не все одинаково годные.

Ну, первое, что всем на ум приходит — это WebSockets. Это типа как обычный HTTP, но с прокачанным дофамином. Соединение одно установили и по нему туда-сюда можно слать что угодно, пока кто-то не отвалится. Для чатов, игр — самое то. В Го для этого есть gorilla/websocket, библиотека, проверенная временем и слезами разработчиков.

Вот, смотри, как просто, ёпта:

var upgrader = websocket.Upgrader{}

func handleConnections(w http.ResponseWriter, r *http.Request) {
    conn, err := upgrader.Upgrade(w, r, nil)
    if err != nil {
        log.Println("Upgrade error:", err)
        return
    }
    defer conn.Close()

    for {
        // Читаем, что клиент нам прислал
        messageType, p, err := conn.ReadMessage()
        if err != nil {
            break
        }
        // И тут же ему в ответ плюём тем же самым (эхо-сервер, блядь)
        if err := conn.WriteMessage(messageType, p); err != nil {
            break
        }
    }
}

Дальше идёт SSE (Server-Sent Events). Это такая хитрая жопа, когда сервер может писать клиенту, а клиент — молчать как рыба и слушать. Представь ленту твиттера или уведомления — сервер пёрнул событие, а у тебя на фронте обновилось. Одностороннее, но простое, как три копейки.

func sseHandler(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "text/event-stream")
    w.Header().Set("Cache-Control", "no-cache")
    w.Header().Set("Connection", "keep-alive")

    flusher, ok := w.(http.Flusher)
    if !ok {
        http.Error(w, "Streaming unsupported!", http.StatusInternalServerError)
        return
    }

    for {
        select {
        case <-r.Context().Done(): // Клиент свалил
            return
        default:
            // Шлём ему текущее время каждую секунду, чтобы жизнь мёдом не казалась
            fmt.Fprintf(w, "data: %snn", time.Now().Format(time.RFC3339))
            flusher.Flush()
            time.Sleep(1 * time.Second)
        }
    }
}

А ещё есть gRPC Streaming. Это уже для серьёзных пацанов, когда твои микросервисы общаются между собой быстрее, чем ты успеваешь сказать «охуенно». Потоковая передача, там свои приколы, но скорость — просто пиздец.

Ну и куда же без брокеров сообщений. Это типа таких почтальонов-алкашей, которые бегают между сервисами и разносят записки. NATS, RabbitMQ, Kafka, Redis Pub/Sub — выбирай на вкус. Хочешь построить систему, которая не развалится, если один сервис накрылся медным тазом? Вот тебе решение.

И отдельно MQTT — протокол для всяких умных чайников и лампочек. Лёгкий, экономный, для IoT самое то. Устройство с памятью на три байта сможет слать тебе данные, что у него батарея сдохла.

Так что же выбрать, спросишь ты?

• WebSockets — если делаешь что-то интерактивное в браузере, где нужно туда-сюда болтать.
• SSE — если нужно просто пинать данные с сервера на фронт, без обратной связи.
• gRPC Streaming — для внутренней кухни, когда сервисы между собой на высокой скорости треплются.
• Брокеры (NATS/Kafka/etc.) — когда архитектура сложнее, чем твои отношения с бывшей, и нужно всё масштабировать и не терять сообщения.
• MQTT — если твои клиенты — это не браузеры, а какие-нибудь датчики в подвале.

Вот, вроде всё. Выбирай с умом, а то потом будешь как Герасим — молчать и мумукать от безысходности, когда всё пойдёт по пизде.