Go *

Привет! На связи Влад, разработчик product-facade — сердца витрины Ozon и одного из самых высоконагруженных сервисов, который выдерживает до 2,2 млн RPS. В прошлой моей статье я рассказывал об одном из архитектурных вызовов, с которым мы столкнулись в процессе работы. В этот раз продолжим тему микросервисной архитектуры и поговорим о том, что происходит, когда привычная строгость контрактов начинает мешать.

Одна из ключевых причин использования gRPC для связи между сервисами — строгий protobuf-контракт. Он даёт типизацию, фиксирует схему данных и снижает риск случайно сломать интеграцию. Но иногда случаются ситуации, когда эти плюсы загоняют нас в рамки. Например, когда сервис просто передаёт данные дальше, но его всё равно приходится обновлять из-за изменений, которые нужны только конечному потребителю. В таких случаях полезно знать, какие механизмы protobuf позволяют работать с контрактом более гибко, не отказываясь от него полностью. В статье расскажу о трёх из них и приведу примеры, для чего они могут применяться.

Я думаю, что все заметили, что в последнее время доступ к большинству зарубежным ресурсам и API оставляет желать лучшего. Для обычного человека потеря связи с любимыми или нужными ресурсами посреди рабочего дня — это очень неприятно. Полагаться на один зарубежный сервер стало неэффективно: узлы падают, скорость проседает. У меня у самого появилась это проблема, поэтому я захотел ее решить.

Что я решил сделать, рассказываю дальше

Привет, Хабр! Когда я был мелкий и трава зеленее, провайдеры всегда выдавали не белый, а «серый» адрес. Да, он менялся при каждом подключении, но всегда можно было открыть порт и поиграть с корешами в ту же CS 1.6 или Minecraft. Время прошло, и сейчас чтобы получить белый IP, нужно пройти три круга ада. И то не факт, что дадут. Или: «Купите наш тариф за миллион денег, тогда дадим».

Предыстория: от идеи к прототипу

Всё началось с того, что мы с коллегами по работе решили собраться и поиграть в CS 1.6. Желающих много, а вот чтобы все были в одном месте — уже не получается. И тогда меня посетила мысль: а что если сделать приложение, чтобы, потягивая пивко, можно было открыть игровой сервер для друзей? А не качать какие‑то Hamachi, ngrok и прочее, а потом ещё 15 минут настраивать порты, пока пиво остывает.

Я не начинал с идеи написать «убийцу JavaScript». Честно говоря, такие заявления обычно только мешают думать.

Сначала была гораздо более скромная мысль: мне нравится Go, мне нравится его простота, типизация и ощущение предсказуемого инструмента. Но когда дело доходит до интерактивного веб‑интерфейса, почти неизбежно оказываешься в другой вселенной: JavaScript, Node.js, сборщики, плагины, отдельная модель компонентов, отдельная экосистема.

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

Так появился мой небольшой экспериментальный проект GoFrame. Сейчас это не готовый фреймворк для продакшена, а исследование в сторону Go‑first подхода для браузера через WebAssembly: маленький рантайм, JSX‑подобная разметка .gox, компиляция этой разметки в обычный Go‑код и утилита goxc, которая способна сгенерировать, собрать и упаковать приложение. В README проекта это прямо описано как экспериментальный Go‑first фреймворк и набор инструментов для интерактивных браузерных приложений на WebAssembly; там же честно указано, что проект не заявляет готовность к продакшену, стабильный API 1.0, SSR, гидратацию, серверные API, форматтер или LSP.

В этой статье я не хочу пересказывать ридми. Интереснее другое: как маленькая идея «а что если сделать JSX для Go?» довольно быстро потянула за собой компилятор, компонентную идентичность, состояния, эффекты, маршрутизацию, проверки в браузере и даже бюджет размера WebAssembly‑бандла.

Привет!

Буду с вами честен, для меня читать сухие переводы документации или смотреть 40-часовые видеокурсы - то еще удовольствие. Поэтому я решил устроить эксперимент и разбирать Go прямо в публичном поле, шаг за шагом документируя весь процесс.

Я не новичок в разработке - повседневно пишу на Python и TypeScript, знаком с базовым devops. Но вот на территорию Go осознанно захожу впервые.

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

Этот цикл статей - мой интерактивный учебник, который я пишу в реальном времени параллельно с изучением языка. Я не Go-гуру и не архитектор с многолетним опытом в этом стеке.

Поэтому если вы опытный Go-разработчик и видите в тексте неточность или косяк - буду искренне рад конструктивным подсказкам в комментариях.

Полгода назад я начал писать in-memory базу с векторным поиском на Go: RESP-протокол, HNSW-индекс, WAL, многопоточность. Рассказываю, что из этого вышло: как я мерил производительность и на каких граблях стоял, что реально ускоряет векторный поиск, а что нет. Все цифры воспроизводимы, код открыт.

Всем привет!
Эта статья является выжимкой моего опыта. Возможно для кого-то это очевидные вещи, тем не менее, считаю, что она может мыть полезна начинающим и не только.

Для работы с базами данных в го есть несколько подходов от стандартного "ручного", до удобных, таких как sqlx, GORM, sqlc... Список можно продолжать дальше.
При разработке очередного ПО я познакомился с sqlc (https://sqlc.dev/) и его подход мне понравился: на основе sql запросов создается полноценная обертка над бд - чем не песня, но как ее грамотно использовать в соответствии с принципами SOLID и Го подходом?

Чтобы измерять нагрузку, ошибки, задержки и потребление ресурсов, осознанно поддерживать SLO и настраивать алерты, не обойтись без Prometheus. Он принимает текстовый формат на HTTP-эндпоинте. Только вот Kafka, PostgreSQL, сетевое железо и Redis метрики по HTTP не отдают, либо понимают только JMX, SNMP и собственный REST API. Так что без переводчика не обойтись.

Всем привет! Я DevOps-разработчик из MTC Web Services. Этим материалом я открываю цикл из пяти постов, благодаря которому вы шаг за шагом напишете собственный Prometheus exporter с нуля на языке Go. Но просто написать код может и ИИ. Моя же цель — дать не только практическую, но и теоретическую основу, чтобы в будущем вы могли легко разработать свой exporter под любую задачу. 

Если вдруг вам уже знакома теория и важнее практика — заглядывайте за ней в оглавление. В качестве примера я выбрал kafka_exporter: он покрывает несколько типов источников, позволяет реализовать паттерн Custom Collector и его легко тестировать локально. А еще есть много популярных kafka_exporter, с которыми мы сможем сравнить наш результат. Код буду коммитить в репозиторий.

Когда компания растёт из одного продуктового направления в несколько, технический долг начинает выглядеть иначе. Проблема уже не в «старом коде», устаревших зависимостях или сложной поддержке legacy-системы. Долг начинает накапливаться в расхождении инженерных решений между сервисами.

Для нас в QIC digital hub это особенно заметно на фоне миграции на новый Go-бэкенд. Исторически платформа развивалась на разнородном стеке: разные части системы были написаны на разных технологиях. Сейчас мы постепенно переезжаем на Go. Часть сервисов уже в проде, часть ещё на пути. Именно в такой момент легко создать новый слой техдолга поверх старого: переписать поведение на новом языке, но оставить команды один на один с десятками одинаковых инфраструктурных задач, которые каждая решает по-своему.

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

- go-kit — общая библиотека с переиспользуемыми инженерными решениями;

- go-service-template — шаблон, который делает эти решения стандартным способом запуска нового сервиса;

- shared-renovate-config — общий Renovate-конфиг с единой политикой обновления зависимостей для всех репозиториев.

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

Представьте себе высоконагруженный сервис, который решает, с какого из множества складов нужно отправить товар покупателю. В пике через него проходит около 600 000 RPS, а строгий SLA требует ответа в пределах 50 мс. Для расчёта нужно за минимальное время выбрать оптимальный склад с учётом остатков, доступности и других данных, которые хранятся в разных микросервисах и их базах данных.

Первое, что приходит на ум, — обратиться к этим сервисам по API во время запроса и получить всё необходимое для расчёта. Но один запрос может затрагивать сотни и даже тысячи складов, не считая связанных сущностей. Такое число сетевых вызовов быстро превысит SLA и приведёт к клиентским таймаутам. Сетевые запросы к мастер-системам в нашем случае — непозволительная роскошь, поэтому мы вынуждены держать слепок данных прямо в памяти подов. А значит, появляется новая проблема: как быстро и надёжно доставлять постоянно меняющиеся данные из мастер-систем в оперативную память сотен подов.

Я давно хотел убрать из backend‑разработки одну особенно липкую рутину: когда для каждой новой сущности снова и снова приходится собирать одни и те же слои REST API — repository, service, handlers, request/response модели, OpenAPI, auth, тесты, curl‑примеры, Docker и прочую инфраструктуру.

В этой статье рассказываю про query‑first подход и open‑source Go CLI rest, который позволяет реализовать эту идею. Смысл простой: если SQL‑запросы или MongoDB‑контракты уже описывают, какие операции нужны приложению, то из них можно сгенерировать согласованный каркас REST‑сервиса.

В статье показано, как это работает для PostgreSQL и MongoDB, что именно генерируется, что такоеrest doctor и почему цель инструмента — не заменить бизнес‑логику, а снять первые 80–90% повторяющейся ручной работы.

Я хотел использовать Claude прямо в мессенджере MAX — без браузера, без переключения контекста. Готового решения не было. Нашёл на GitHub китайский проект cc-connect — Go-фреймворк с plugin-архитектурой для подключения AI-агентов к мессенджерам. Telegram, Feishu, Discord там были. MAX — нет.

Написал адаптер, открыл PR. Приняли. Теперь поддержка MAX — часть основного репозитория.

Что такое cc-connect

cc-connect — Go-фреймворк с чёткой трёхслойной архитектурой:

Эта статья прежде всего будет полезна студентам и начинающим специалистам.

В отрасли разработки программного обеспечения под системным дизайном (System Design) понимают процесс проектирования архитектуры, компонентов, баз данных и связей информационной системы. Цель системного дизайна - обеспечить масштабируемость, отказоустойчивость и высокую производительность системы, в том числе при росте нагрузки. В этой статье я затрону базовые задачи системного дизайна - как спроектировать и разработать систему так, чтобы она обладала архитектурой, чтобы развитие и поддержка системы не приносила много страданий, чтобы доработки не ломали действующий функционал.

С момента написания первой статьи о B4 прошло полгода. Казалось бы, не очень много времени, но софтина получила ну очень большое количество фич, о которых хочется рассказать подробно. Не буду скрывать: хабраэффект сделал своё дело, и благодаря большому интересу после первой статьи очень многие не разочаровались в отсутствии какого-то функционала, а активно помогали - коммуникацией, запросами, тестированием, - благодаря чему все эти фичи в B4 и появились.

В итоге на сегодняшний день B4 - это не инструмент для обхода блокировок (коим и задумывался изначально), а полноценный сетевой мультитул с гибкой и продвинутой маршрутизацией таргетированного трафика.

Обзор асинхронности WASM с выходом WASI 0.3

WASM уже вышел за пределы браузеров и выглядит как перспективная технология для серверной разработки. Однако в вопросе серверного компьюта рано или поздно встает вопрос асинхронной обработки I/O-bound нагрузки. В данной статье попробуем разобраться, что как отвечает экосистема WASM на данный вызов. Статья особенно актуальна в свете того, что совсем недавно официально представлен WASI 0.3

Проблема
Мне как бэкэнд-разработчику приходится работать с деплоем своих проектов, каждый раз одна и та же рутина: настройка сервера, nginx, ssl, безопасность сервера(fail2ban, user), CD и многое другое. Это отнимает очень много времени.

Что сделал
После десятков задеплоенных проектов я понял, что все эти действия можно автоматизировать, и решил написать скрипт.

С чего все началось

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

Думал, это вечер работы. requests.get(), выдрать цену, сравнить, отправить в телегу (упрощенно, конечно).

Оказалось, парсинг цен на маркетплейсах — это не про HTTP‑запрос. Это про репутацию IP‑адресов, про то, как браузер выдает себя поведением, и — на финале — про пост‑квантовую криптографию в TLS‑рукопожатии. Три площадки (Ozon, WB, Яндекс.Маркет) дали мне три совершенно разных уровня защиты, и на каждом я застревал по‑своему.

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

Я подключил mcp-server-fetch и попросил агента извлечь из документа несколько фрагментов. Ответ получился складным и уверенным. Проанализировав трафик JSON-RPC между клиентом и сервером, я выяснил, что ответ вернулся обрезанным на 6000 символах, причём сервер пометил его как успешный.

В самом конце ответа сервер добавил для модели инструкцию:

Язык Go сейчас очень популярен, и на него переходит много разработчиков с Java, C#, PHP и Python.

У многих возникают проблемы с Go по одной любопытной причине: все кажется слишком простым. «Где наш фабричный метод?», «Где наследование?», «Где привычные паттерны?».

Больше 30 лет назад «банда четырех», она же GoF, выпустила книгу Design Patterns, где впервые описала 23 паттерна, которые сейчас считаются классическими. Это была революция: раньше приходилось долго объяснять, что ты делаешь в коде, а теперь можно просто сказать: «Я пишу адаптер».

Пару раз я встречала в описаниях вакансий на позицию Go‑разработчика требования знать ООП‑паттерны. Или слышала мнение, что Go частично реализует ООП, или что это вообще недо‑ООП язык. При этом сами разработчики языка на вопрос «Является ли Go ООП языком?» отвечают уклончиво: и да, и нет.

В этой статье я хочу обсудить особенности Go, которые, на мой взгляд, формируют собственные паттерны — те, что реализуют поведение классических ООП‑паттернов, но делают это в своем гошном стиле.

Недавно мы с женой придумали небольшой совместный проект: она креативит, я прогаю. Сделав каркас в Codex, я завел чат на троих с Hermes Agent. Пошерил ему доступы и контекст, теперь моя пассия добавляет фичи и двигает пиксели голосовухами. Это сработало так круто, что я всунул Гермеса много куда — и не могу не поделиться этим с вами!

В этой статье я расскажу: что такое Hermes Agent, как я его использую и как сделать себе также.