🌠 NATS.go — клиент для облачного обмена сообщениями на Go. Официальный Go-клиент от команды NATS.io предоставляет простой интерфейс для работы — от базовой pub/sub до персистентных JetStream-сообщений.

Достаточно трёх строк кода, чтобы подписаться на топик и обрабатывать сообщения асинхронно. Клиент поддерживает все фишки NATS: wildcard-подписки, TLS-аутентификацию и даже сервисный API для создания микросервисов.

🤖 GitHub

@golang_google

🕰️ Подводные камни работы с пакетом `time` в Go

Пакет time в языке Go — мощный инструмент, но с рядом нюансов, которые важно понимать, особенно при разработке кросс-платформенного кода, тестировании производительности и работе с часовыми поясами. В статье ["Important Considerations When Using Go's Time Package"](https://dev.to/rezmoss/important-considerations-when-using-gos-time-package-910-3aim) автор выделяет ключевые моменты, на которые стоит обратить внимание каждому Go-разработчику.

Работа со временем — это всегда зона риска: вы можете не заметить, как из-за смены часового пояса или перехода на летнее время ваша система начнёт вести себя непредсказуемо. В Go это особенно критично, поскольку язык делает ставку на простоту, но предоставляет тонкие механизмы управления временем.

Перейдём к основным идеям статьи:

- Монотонное время в Go
Go использует монотонные часы (monotonic time) при сравнении времён и вычислении интервалов. Это означает, что функции вроде time.Since(start) или time.Until(deadline) не зависят от текущего системного времени, что защищает от проблем при его изменении (например, если системное время изменилось вручную или произошло переключение на летнее/зимнее).

Однако есть нюанс: поддержка монотонного времени зависит от операционной системы. Например, на Windows поведение может отличаться от Linux. Кроме того, некоторые функции time.Time, особенно при сериализации (например, MarshalJSON`), не сохраняют информацию о монотонности. Поэтому нельзя полагаться на `time.Since() между разными экземплярами времени, сериализованными и десериализованными между процессами или машинами.

Точность ожиданий
Функции вроде time.Sleep или таймеры (`time.After`) не гарантируют точности в миллисекундах или тем более микросекундах. Если вам важно очень точное ожидание — например, в измерениях производительности — лучше использовать активное ожидание с проверкой времени, хоть это и более затратно для CPU:

deadline := time.Now().Add(1 * time.Millisecond)
for time.Now().Before(deadline) {
    // активный busy-loop
}

Такой способ может быть полезен в тестах, где нужна высокая точность, но для продакшена не рекомендуется из-за нагрузки.

Бенчмаркинг и измерения
Многие разработчики используют time.Now() для измерения производительности кода. Это ошибка. Вместо этого используйте пакет testing и его возможности Benchmark:

func BenchmarkMyFunc(b *testing.B) {
    for i := 0; i < b.N; i++ {
        MyFunc()
    }
}

Go сам подберёт количество итераций и обеспечит надёжные измерения с учётом шумов и сборщика мусора.

Часовые пояса
В Go объект time.Time всегда содержит информацию о часовом поясе. Это важно! Не путайте:

- UTC() — время в UTC
- Local() — локальное системное время
- In(loc *time.Location) — преобразование времени в конкретную временную зону

Вы можете работать с временными зонами через файл zoneinfo, но будьте внимательны — не все контейнерные образы или минималистичные ОС содержат актуальные данные о временных зонах, и это может привести к неожиданным ошибкам.

Сравнение времён
При сравнении времён важно, чтобы они были приведены к одной временной зоне. Даже если два объекта time.Time представляют одинаковую точку во времени, но один — в UTC, а другой — в Local(), t1.Equal(t2) может вернуть false. Для сравнения используйте:

t1.UTC().Equal(t2.UTC())

Или используйте Sub() и Before/After — они учитывают монотонную часть и обычно безопаснее.

📌 Подробности

Пост об аудите криптографии Go от Trail of Bits

Статья на [go.dev](http://go.dev/blog/tob-crypto-audit) посвящена аудиту безопасности криптографических библиотек Go, проведенному Trail of Bits. Основные моменты:

🔐 Высокая надежность криптографии Go: Аудит подтвердил безопасность криптографических пакетов Go, которые отличаются строгим подходом к безопасности, минимальной сложностью кода и тщательным тестированием. Это обеспечивает защиту от уязвимостей, включая проблемы управления памятью, благодаря свойствам языка Go.

🛠 Единственная уязвимость: Обнаружена одна потенциально эксплуатируемая проблема (TOB-GOCL-3) низкой серьезности в экспериментальной интеграции Go+BoringCrypto, используемой только внутри Google. Уязвимость связана с управлением памятью и уже исправлена в Go 1.25. Она не затрагивает стандартные сборки Go, так как Go+BoringCrypto не включена по умолчанию.

🕒 Тайминговые атаки: Найдены незначительные риски тайминговых побочных каналов (TOB-GOCL-1, TOB-GOCL-2, TOB-GOCL-6). Только TOB-GOCL-2 затрагивает операции с секретными данными, но лишь на платформах Power ISA (ppc64, ppc64le). Все замечания исправлены в Go 1.25.

🔍 Дополнительные улучшения: Аудит выявил несколько информационных замечаний, включая потенциальные риски неправильного использования API (TOB-GOCL-4) и отсутствие проверки недостижимого лимита (TOB-GOCL-5). Эти рекомендации также учтены в разработке Go 1.25.

🚀 Будущее криптографии Go: Команда Go планирует внедрить новые высокоуровневые API, упрощающие выбор безопасных алгоритмов, начиная с API для хеширования паролей с автоматическим переходом на новые алгоритмы по мере развития технологий.

https://go.dev/blog/tob-crypto-audit

@golang_google

🕊️ RoadRunner — высокопроизводительный application server на Go. Этот проект заменяет связку Nginx+PHP-FPM, позволяя запускать PSR-7-совместимые приложения с поддержкой HTTP/3, WebSockets и даже Temporal workflow.

Конфигурация через .rr.yaml напоминает docker-compose: можно подключать очереди, кеш и метрики как плагины. Рабочие процессы PHP остаются в памяти, что даёт до 10x прирост скорости против традиционного FPM. Особенно радует встроенная система мониторинга и автоматические рестарты упавших воркеров.

🤖 GitHub

@golang_google

🛠️ История создания “storage-agnostic” message queue

Контекст:
Работая на Go, автор вдохновился инструментами из Node.js экосистемы (BullMQ, RabbitMQ) и захотел сделать что-то похожее, но с нуля, без зависимостей. Так родилась идея — сначала он создал Gocq (Go Concurrent Queue): простую concurrent-очередь, работающую через каналы.

⚡ Основная проблема

Gocq отлично работал в памяти, но не поддерживал устойчивое хранение задач.
Автор задумался: а можно ли сделать очередь, не зависящую от конкретного хранилища — так, чтобы её можно было подключить к Redis, SQLite или совсем без них?

🧱 Как это реализовано в VarMQ

После рефакторинга Gocq был разделён на два компонента:
1) Worker pool — пул воркеров, обрабатывающих задачи
2) Queue interface — абстракция над очередью, не зависящая от реализации

Теперь воркер просто берёт задачи из очереди, не зная, где они хранятся.

🧠 Пример использования

• In-memory очередь:

w := varmq.NewVoidWorker(func(data any) {
   // обработка задачи
}, 2)
q := w.BindQueue()

• С SQLite-поддержкой:

import "github.com/goptics/sqliteq"

db := sqliteq.New("test.db")
pq, _ := db.NewQueue("orders")
q := w.WithPersistentQueue(pq)

• С Redis (для распределённой обработки):

import "github.com/goptics/redisq"

rdb := redisq.New("redis://localhost:6379")
pq := rdb.NewDistributedQueue("transactions")
q := w.WithDistributedQueue(pq)

В итоге воркер обрабатывает задачи одинаково — независимо от хранилища.

✅ Почему это круто

• Гибкость: адаптеры позволяют легко менять хранилище без правок воркера
• Минимальные зависимости: в яд

📌 Читать

⚡️ OneUptime — open-source-платформа для мониторинга всего и сразу. Этот инструмент предлагает готовый комплект: от мониторинга uptime до управления инцидентами. Редкий случай, когда open-source-проект не уступает коммерческим аналогам по функционалу.

Особенность проекта в глубокой интеграция компонентов. Например, при падении сервиса система автоматически создаёт инцидент, уведомляет ответственных через эскалацию и обновляет статус-страницу. Есть даже встроенный APM с трейсами и метриками производительности. Развернуть можно на Kubernetes или через Docker Compose.

🤖 GitHub

@golang_google

🧪 Go synctest — решение для нестабильных (flaky) тестов

Flaky-тесты в многопоточном Go-коде — боль. Новый экспериментальный инструмент synctest из Go 1.24 решает эту проблему с помощью синтетического времени и контроля исполнения goroutine.

📌 Что это такое:
synctest — специальный режим, запускающий тесты в изолированной "песочнице", где:
• time.Sleep не ждёт реального времени
• все goroutine исполняются детерминированно
• нет зависимости от планировщика и нагрузки ОС

🔧 Пример:

import "testing/synctest"

func TestSharedValue(t *testing.T) {
    synctest.Run(func() {
        var shared atomic.Int64
        go func() {
            shared.Store(1)
            time.Sleep(1 * time.Microsecond)
            shared.Store(2)
        }()
        time.Sleep(5 * time.Microsecond)
        if shared.Load() != 2 {
            t.Errorf("shared = %d, want 2", shared.Load())
        }
    })
}

⏱ Даже с Sleep, результат всегда стабилен. Без synctest такой тест может иногда проваливаться.

⚙️ Преимущества:
✅ Устранение race-условий при тестировании
✅ Нет задержек — Sleep срабатывает мгновенно
✅ Можно тестировать поведение с точностью до микросекунды
✅ Подходит для любых atomic, mutex, select, time.After и др.

🚫 Ограничения:
• Пока экспериментально: нужно запускать с GOEXPERIMENT=synctest
• Не подходит для ввода-вывода, работы с сетью или временем вне "bubble"

📖 Подробнее:
https://victoriametrics.com/blog/go-synctest/

@golang_google

📦 Как оптимизировать struct в Go: выравнивание, паддинг и порядок полей

Когда ты работаешь с Go и структурой данных (`struct`), порядок полей — это не просто эстетика. Это напрямую влияет на:
• размер занимаемой памяти
• эффективность использования кэша
• и в итоге — на производительность твоей программы.

Автор [buarki на DEV.to](https://dev.to/buarki/optimizing-struct-layout-and-padding-in-practice-23p1) показывает, как правильно выстраивать поля в структурах, чтобы избежать лишнего паддинга и сделать struct более компактным и быстрым.

🔍 Что такое padding?

Go автоматически выравнивает поля структур по их размеру. Например:

type Bad struct {
    a bool   // 1 байт
    b int64  // 8 байт
    c bool   // 1 байт
}

Кажется, что struct должен занимать 10 байт. Но из-за выравнивания Go вставит паддинг, и итоговый размер окажется 24 байта.

✅ Как это исправить?

Меняем порядок полей:

type Good struct {
    b int64  // 8 байт
    a bool   // 1 байт
    c bool   // 1 байт
}

Теперь структура занимает 16 байт, а не 24 — и всё благодаря грамотному размещению полей.

📌 Рекомендации:

• Сортируй поля от самых крупных к самым мелким
• Группируй однотипные поля
• Избегай перемешивания bool`/`byte с int64`/`float64
• Используй визуализацию (например, viztruct) для анализа struct'ов
• Проверяй размер struct через unsafe.Sizeof()

🎯 Это особенно важно при:
• массовом использовании struct в массивах и слайсах
• передаче struct между потоками
• работе с бинарными протоколами или mmap

📖 Подробнее с примерами: https://dev.to/buarki/optimizing-struct-layout-and-padding-in-practice-23p1

🗃️ Stoolap — лёгкая и быстрая SQL-база данных на чистом Go без зависимостей

Stoolap — это современный HTAP-движок (Hybrid Transactional/Analytical Processing), сочетающий OLTP и OLAP в одном ядре. Подходит как для транзакционных задач, так и для аналитики.

🚀 Возможности:
• Полностью написан на Go — никаких внешних зависимостей
• ACID-транзакции через MVCC
• Колонковое хранение с SIMD-ускорением
• Поддержка SQL: JOIN, агрегаты, оконные функции
• Встроенный тип JSON
• Поддержка database/sql и интеграция с GORM
• CLI-режим и in-memory база

📦 Установка:

go get github.com/stoolap/stoolap

🔥 Быстрый старт (CLI):

stoolap -db memory://

📎 Репозиторий: https://github.com/stoolap/stoolap
🌐 Сайт: https://stoolap.io


@golang_google

🏗️ Как строить масштабируемые multi-tenant приложения на Go — опыт Atlas Cloud

В этой статье команда Atlas делится практическими стратегиями масштабирования multi-tenant приложений на Go, основанными на опыте разработки бэкенда для Atlas Cloud — части их коммерческого продукта.

🔍 Что такое multi-tenancy?

Multi-tenancy — это архитектура, при которой один инстанс системы обслуживает сразу нескольких клиентов (арендаторов).

📦 Но тут важен нюанс: клиенты ожидают, что сервис будет работать так, как будто он только для них — без потерь в скорости, надёжности и безопасности.

Именно поэтому вы *молча* обещаете каждому клиенту две вещи:

1. Изоляция данных — никакой арендатор не должен иметь доступ к чужим данным
2. Стабильная производительность — нагрузка одного арендатора не должна замедлять других

🛡️ Стратегия №1 — Физическая изоляция (Dedicated Instances)

Самый прямой способ выполнить эти обещания — запуск отдельного инстанса приложения на каждого арендатора.

Что это даёт:

✅ Данные арендаторов хранятся в отдельных БД (или даже в разных VPC/облаках)
✅ Полная изоляция ресурсов — никто не шумит и не мешает
✅ Безопасность на уровне инфраструктуры

💸 Но у такого подхода есть и минусы:

• Сложность в управлении: сотни и тысячи развёрнутых инстансов, каждая со своей БД и конфигурацией
• Стоимость: каждый инстанс потребляет ресурсы, и это дорого
• Проблемы масштабирования: каждый новый клиент = новый деплой
• Сложности с наблюдаемостью: логи, метрики и дебаг — теперь распределены по куче окружений

В статье авторы разбирают гибридные подходы, модели хранения, обработку миграций и советы по коду.

🔗 Продолжение читай тут:
https://atlasgo.io/blog/2025/05/26/gophercon-scalable-multi-tenant-apps-in-go

@golang_google