Месяц назад я описывал wizard-подход к настройке sing-box без ручного JSON. Теперь это полноценный нативный macOS-клиент и Windows-клиент с TUN, системным прокси, menu bar, быстрым переключением узлов и решением бага Fyne через Objective-C.
Если вы когда-либо строили высоконагруженные системы поиска, то знаете, что в какой-то момент узким местом становится не код, а сама архитектура. Поиск доступных отелей — как раз тот случай: миллиарды «ночей», десятки тысяч RPS, постоянные обновления календарей, строгая консистентность и высокая цена любой ошибки. Старый стек на Python + Postgres + Redis долго тянул, но однажды стал «тормозить» настолько, что оптимизировать дальше было невозможно — SQL-запросы разрастались, реплики множились, latency прыгала до 60 секунд, а кэширование превращалось в источник инцидентов.
Так мы пришли к идее построить собственную in-memory базу данных на Go — заточенную под наш домен. Быструю, безопасную и синхронизированную с Postgres.
Под катом — история того, как мы её спроектировали, какие архитектурные решения приняли, как победили холодный старт, справились с миллиардами значений. И почему в итоге смогли полностью отказаться от кэша доступности, переведя поиск в real‑time.
В статье я сравниваю четыре реализации одного и того же сервиса поверх PostgreSQL:
1. Spring MVC + JDBC
2. Spring WebFlux + R2DBC
3. Ktor + JDBC
4. Go + pgx
Все сервисы крутятся в Docker с одинаковыми ресурсными лимитами и прогоняются через один и тот же JMeter-план. Для каждого стека я ищу максимальный RPS при соблюдении SLO по p99-латентности.
Я подробно разбираю:
- как устроен стенд (Docker-compose, Postgres, Prometheus, Grafana, JMeter);
- как реализованы сервисы и чем различаются модели конкурентности;
- методологию нагрузочного тестирования и расчёта RPS@p99≤SLA;
- как реально ведут себя блокирующий стек, реактивный стек и Go под честной нагрузкой.
Всем привет! Меня зовут Михаил Пашедко, я backend-разработчик в Авито в команде Автотека. В статье расскажу, как небольшой эксперимент на пару спринтов стал полноценным направлением разработки — и показал, как в зрелой компании можно запускать живые, «стартаперские» инициативы, не теряя при этом контроль над качеством.
До Go 1.25 рантайм по умолчанию выставлял GOMAXPROCS по числу логических CPU на ноде — и в контейнерах это регулярно приводило к странным эффектам: лишние потоки, перерасход квоты и жёсткий троттлинг cgroups с неприятной просадкой задержек, особенно в «хвосте». В статье разбираем, как устроено планирование горутин, чем CPU-лимиты в Kubernetes отличаются от ограничения параллелизма, и почему новый дефолт GOMAXPROCS делает поведение Go в продакшене заметно предсказуемее.
Пару лет я в соло разрабатывал максимально нишевую игру "для программистов" (NebuLeet) на довольно нишевых технологиях (Go + ebitengine), и вот теперь, после релиза, я хочу рассказать про одну из интересных особенностей этой игры - визуальном программировании логики игровых юнитов.
Визуальный язык в игре прошёл несколько итераций развития, от неявных аргументов команд через стек, до чего-то типа регистровой модели, где у ячеек памяти есть имена, а команды принимают аргументы явно.
Вас ждёт увлекательная околокомпиляторная/языковая статья с игровым применением. Всё-таки, языки программирования для игр - это ведь отдельный жанр.
JWT, SSO, OAuth, OpenID Connect — названия знакомые каждому разработчику. Но стоит спросить: «Зачем в продакшене нужен JWKS?» или «Чем отличается OAuth2 от OpenID Connect?» — уверенность сразу исчезает.
В этой статье мы разберём как устроен JWT и его подпись, зачем нужны access и refresh токены, что такое JWKS и в чём отличие OAuth от OpenID Connect.
Вместо скучных стандартов и спецификаций протоколов в статье будет один наглядный образ на примере отелей и пропусков. Это позволит не только запомнить, но и прочувствовать на реальных примерах, избавиться от хаоса и путаницы в голове, когда речь заходит об аутентификации и авторизации. Цель статьи — не дать «рецепт внедрения», а дать возможность понять, как это работает внутри и «пощупать» эти темы на Go.
В этой статье я расскажу, как я для себя понимаю архитектуру десктоп-приложений — и почему в какой-то момент Rust перестал быть «языком, который я когда-нибудь посмотрю», и стал практичным решением.
Сразу оговорюсь: это не попытка доказать, что «Electron — зло», а Rust — «спаситель». Это скорее дневник архитектора, который хотел собрать удобный продукт и по дороге несколько раз наступил на грабли. Некоторые грабли были с подогревом.
Мухи — отдельно, котлеты — отдельно. Отделяем Go-код от SQL-запросов. Зачем это делать и как?Личный опыт миграции большого проекта на новую СУБД показал: смешивание SQL с кодом приложения создаёт проблемы. Представляю простую библиотеку SQLSet для хранения именованных SQL-запросов в отдельных файлах.
Синтаксис Go глазами того, кто последние пять лет писал на TypeScript.
В первой части мы разобрались с философией Go и настройкой рабочего окружения. Теперь к коду. Эта статья про синтаксис и ключевые концепции Go. Не ждите пересказа документации. Будут сравнения, будут подводные камни, будет код.
Команда Go for Devs подготовила перевод статьи о трёх языках, которые всё чаще оказываются в одном ряду, но на самом деле решают принципиально разные задачи: Go, Rust и Zig. Автор несколько месяцев изучал каждый из них и попытался понять, какие ценности стоят за их устройством. Go выбирает минимализм и корпоративную предсказуемость, Rust — безопасность и максимальную выразительность, Zig — радикальный контроль и отказ от ООП-мышления. Получился честный и местами провокационный разбор того, зачем нужны эти языки и кому из разработчиков они подходят.
Kubernetes-операторы давно стали привычным инструментом автоматизации и управления сложными системами. Однако на практике их поведение далеко не такое предсказуемое, как в примерах из документации. Небольшие отклонения в логике цикла согласования, обработке ошибок или обновлении статуса быстро превращаются в зацикливание, дублирование ресурсов и прочие сюрпризы, которые трудно отладить. Новичкам полезно понимать, почему так происходит, а опытным разработчикам — помнить, какие принципы стоит держать в голове при проектировании оператора.
Меня зовут Стас Иванкевич, я техлид в команде разработки управляющего слоя Platform V DropApp в СберТехе. В управляющий слой входят установщик кластера, консоль, API, другие компоненты и самое релевантное для этой статьи — наши многообразные операторы.
За последние несколько лет мы разработали целую пачку операторов — на один-два контроллера или сразу на множество. В ходе работы мы собрали и упорядочили лучшие практики, проверенные реальной эксплуатацией, а также подводные камни и типичные ошибки. И сегодня хотим поделиться нашей подборкой с вами.
Сталкивались ли вы с болью при управлении порядком запуска и остановки зависимостей в вашем Go-сервисе?
Разработка больших сервисов неизбежно приводит к необходимости управлять множеством зависимостей. В этом контексте мы говорим о долгоживущих компонентах, чья работа обеспечивается отдельными горутинами: как правило, это блокирующий метод (например, Start), внутри которого крутится цикл обработки.
Примерный сценарий жизненного цикла сервиса выглядит так:
При запуске критически важно, чтобы пул соединений с БД, кэш и очереди были полностью готовы до того, как HTTP-сервер откроет порт и начнет принимать входящий трафик.
С graceful shutdown ситуация обратная: порядок должен быть строго зеркальным. Сначала нужно перестать принимать новые запросы, дождаться завершения текущих, остановить воркеры, и только потом разрывать соединения с инфраструктурой. Иначе мы получаем неприятные ошибки подключения и даже потерянные транзакции в момент деплоя.
Если эти проблемы вам не знакомы, смело закрывайте вкладку. Скорее всего, эта статья не принесет вам пользы.
Но если вы ищете способ автоматизировать эту рутину, сохранив код чистым - добро пожаловать под кат.
Golang: Пакет для мульти-логирования на основе log/Slog
Привет Хабр! Это моя первая статья тут, я надеюсь получилось читабельно и интересно :-)
В статье я описываю свой небольшой проект мульти-логера, написанный на основе распространённого в go пакета log/Slog.
Я собрал минимальный набор практик, без которых микросервис очень быстро превращается в «чёрный ящик»: логи, трассировка, метрики, конфигурация, feature flags, тестирование и чуть-чуть документации. Это не теория — это вещи, которые я выстрадал, пока делал Go-шаблон для коллег, переходящих после Ruby/PHP, и пытался сделать так, чтобы сервис было реально удобно запускать, отлаживать и поддерживать.
Внутри — простые объяснения, почему эти штуки окупаются, и примеры на Go: как разделить логи и связать их с trace_id, как руками добавить span, какие метрики имеет смысл считать, как организовать конфиг, зачем OpenFeature, почему testcontainers — это не боль, и почему Makefile иногда экономит больше времени, чем очередной «идеальный рефакторинг».
Статья содержит описание работы утилиты для видео звонков из командной строки say. Рассказывается о том как всё устроено под капотом, как оптимизированно и почему всё работает так быстро с минимальным размером памяти и нагрузки на CPU.
Так же небольшой обзор утилиты see для просмотра фильмов опять же в окне терминала.
В этой части (первая тут) мы поговорим о структуре Go-программы с использованием ассемблера, о хитростях макросов. Будем писать дальше нашу ассемблерную функцию.
Если JS/TS это динамичный, асинхронный «ассемблер» для веба, построенный вокруг одного потока и цикла событий, то Go это строгий, параллельный «ассемблер» для облака, построенный на простоте, явности и истинном параллелизме.
Многие классические учебные материалы по Go, которые вы можете найти, уже устарели. Официальный документ "Effective Go", написанный в 2009 году, не охватывает ни модули, ни дженерики. Два аспекта, которые являются фундаментальными для современного Go. Аналогично, многие популярные книги, такие как "The Go Programming Language", были написаны до появления дженериков. Этот документ призван стать современной отправной точкой, ориентированной на версию Go 1.25+ и использующей ваши существующие знания JS/TS для ускорения обучения.
В слое Domain 90% проектов с тактическим DDD забыли о самом главном. Сегодня мы вспомним то о чем забыли или узнаем то чего не знали.
Команда Go for Devs подготовила перевод статьи о том, как GoLand помогает разработчикам вовремя находить и устранять утечки ресурсов. Файлы, соединения, HTTP-ответы, SQL-строки — всё это может незаметно накапливаться и ломать сервис под нагрузкой. В статье на реальных примерах показано, как одна пропущенная Close() приводит к сбоям, и почему встроенный анализ утечек становится незаменимым инструментом для стабильного продакшена.
