Leak and Seek: A Go Runtime Mystery

Статья описывает расследование команды Cyolo, связанное с утечкой памяти в приложении на языке Go. После сообщений клиентов о проблемах с производительностью команда обнаружила, что утечка связана с объектами SqliteRows, SqliteStmt и SqliteConn в драйвере SQLite3.

Они исследовали возможность циклических ссылок и проблемы с механизмом финализаторов в Go, но выяснили, что причиной была блокировка горутины финализатора из-за функции Close в пакете go-smb2, выполняющей потенциально блокирующие операции ввода-вывода.

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

👉 Читать

👉 @juniorGolang | #cтатья

⚙️ Go-пакет, совместимый с http.Client и полностью заменяющий его, который под капотом использует настоящий headless-браузер (Chrome через chromedp) для загрузки и взаимодействия с веб-страницами

https://github.com/gleicon/browserhttp

👉 @juniorGolang | #ресурсы

⚙️ Библиотека обработки ошибок на Go с читаемыми трассировками стека и гибкой поддержкой форматирования

https://github.com/rotisserie/eris

👉 @juniorGolang | #ресурсы

Не допускайте сбоя: паттерн повторной попытки (Retry Pattern) в Go

Статья объясняет, как реализовать паттерн повторных попыток (retry) в Go для обработки временных сбоев — например, сетевых ошибок.

Описываются разные стратегии (фиксированная задержка, экспоненциальный бэкофф с джиттером) и дается пример универсального retry-механизма.

👉 Читать

👉 @juniorGolang | #cтатья

API маршрутизатор для серверов #MCP, написанный на Go

https://github.com/chatmcp/mcprouter

👉 @juniorGolang | #ресурсы

Инструмент, который сканирует указанные организации или учетные записи пользователей на GitHub в поиске публичных Go-модулей, парсит их прямые зависимости из файлов go.mod и генерирует граф зависимостей в формате DOT или топологически отсортированный список

https://github.com/ldemailly/depgraph

👉 @juniorGolang | #ресурсы

Стриминг больших файлов между микросервисами: Реализация на Go

Этот проект демонстрирует практическую реализацию на Go для эффективной передачи больших файлов или объёмных payload'ов между микросервисами. Он напрямую отвечает на задачу, озвученную Сумитом Мукхиджей в этом твите:

"Вашему микросервису нужно передавать большие объёмы данных (например, файлы, изображения) между сервисами. Как вы спроектируете коммуникацию, чтобы избежать узких мест в производительности и эффективно обрабатывать большие payload'ы?"

Реализация предлагает решение на основе стандартного HTTP-протокола, с акцентом на следующие аспекты:

🔹Эффективное использование памяти: исключается загрузка целого файла в память как на клиенте, так и на сервере.

🔹Эффективность по пропускной способности: применяется выборочное сжатие для подходящих типов контента с целью снижения сетевого трафика.

🔹Устойчивость: реализована поддержка возобновляемых загрузок для корректной обработки сетевых сбоев.

🔹Производительность: используется буферизация ввода/вывода и возможности стандартной библиотеки Go для оптимизации операций.

Полный исходный код реализации доступен здесь

👉 Читать

👉 @juniorGolang | #cтатья

⚙️ Альтернатива демонa auditd, поставляемому со многими дистрибутивами Linux

https://github.com/slackhq/go-audit

👉 @juniorGolang | #ресурсы

Объяснение CPU requests и limits в контейнерах с настройкой GOMAXPROCS

Одна из самых интересных статей, которые я читал в последнее время

В ней объясняется:

🔹Как на самом деле работают CPU requests и limits, включая внутренние механизмы

🔹Почему установка GOMAXPROCS важна для Go-приложений, работающих в контейнеризованных средах

🔹Как на самом деле работает uber-go/automaxprocs

🔹Какие метрики можно использовать, чтобы определить, подвергается ли контейнер throttling'у

И многое другое

👉 Читать

👉 @juniorGolang | #cтатья

Писать неудобный код — сложно, но приходится

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

Например, чтобы обновить документ в базе данных — почему бы просто не передать клиенту map[string]any, чтобы он сам обновил, что ему нужно?
Лично я такое не приемлю, особенно в командной работе.

Я бы ограничил, какие поля может обновлять клиент, и валидировал бы всё перед записью в базу, даже если для этого нужно больше кода, больше функций.

Я не хочу давать клиенту лишние шансы ошибиться.

Использование any, map[string]interface{}, возврат пустых error, глобальные переменные, сваливание всех хелперов в shared/utils, создание монолитных общих интерфейсов, игнорирование ошибок (или возвращаемых значений) без комментариев, написание огромных функций без разбиения, использование context.Background() ради скорости, возврат 3–4 значений, хардкод вместо констант, наплевательское отношение к дизайну и зависимостям между пакетами, сваливание всех моделей в models/model.go…

Я не утверждаю, что всё это всегда плохо — как обычно, всё зависит от контекста.

Опытные разработчики знают, когда можно отойти от правил, но никогда не злоупотребляют этим.

Каждая из этих практик сама по себе может быть не критична, но в сумме они могут привести к серьёзным проблемам в будущем.

👉 @juniorGolang | #tip

⚙️ Функционально насыщенный, быстрый и гибкий контроллер входящего трафика, нативный для Kubernetes, и шлюз API следующего поколения, построенный на базе Envoy, реализованный на Go.

https://github.com/solo-io/gloo

👉 @juniorGolang | #ресурсы