Несколько лет назад я прочитал статью о параллелизации в GO и ничего не понял – я тогда только начинал программировать на этом языке. Но размышления автора мне очень понравились – они подкреплялись бэнчмарками, что было довольно убедительно. Автор игрался c параметром GOMAXPROCS и показал, что увеличение этого параметра не всегда приводит к увеличению производительности. Под конец статьи он подобрал такое значение, которое будет максимально эффективным для его функции, на мое удивление, это значение оказалось равно единице! Т.е. его код работал максимально эффективно, если работал всего на одном ядре процессора! Однако, в одном из комментариев под той статьей я прочел, что все эти изыскания нелепы, поскольку та же самая функция из статьи запущенная всего в один поток оказывается эффективнее любой ее параллельной реализации.

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

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

Яркие примеры таких приложений: YouTube или Google. Естественно, на одной машине такие сервисы не развернуть, поэтому в архитектуре используются тысячи компьютеров, именуемых Нодами (worker node). Однако эти Ноды, как части общего механизма, могут выходить из строя, и тогда их нужно заново поднимать, более того, хорошо бы вообще постоянно мониторить каждый Нод и считывать его состояние. Выполнять такие задачи становится очень сложно вручную. И, возможно, именно для этих площадок, а может быть и нет, но Google разработала технологию Kubernetes, которая выполняет роль оркестрации контейнеров. Kubernetes следит за Нодами и поднимает те, что выходят из строя, но это не единственная ее задача. Технология также может отключать неиспользуемые Ноды, оптимизируя расход ресурсов.

Привет! Меня зовут Антон Жуков, я руковожу группой разработки в Сбермаркете. В профессии я уже более 12 лет, с Golang работаю с 2016 года, а с Kubernetes — с 2018 года.

В этой статье расскажу об основах Kubernetes, возможных проблемах и решениях, а также о том, как грамотно использовать ресурсы этой платформы, чтобы выжать максимум из Go-приложений. Кроме того, в конце статьи я опишу кейс настройки GOMAXPROCS на примере нашего приложения и расскажу, как нам удалось повысить его производительность на 20-50%.

Изящное завершение работы (Graceful Shutdown) важно для любого длительного процесса, особенно для того, который обрабатывает состояние. Например, что если вы хотите завершить работу базы данных, поддерживающей ваше приложение, а процесс db не сбрасывает текущее состояние на диск, или что если вы хотите завершить работу веб-сервера с тысячами соединений, но не дожидаетесь окончания запросов. Изящное завершение работы не только положительно сказывается на пользовательском опыте, но и облегчает внутренние операции, что приводит к более счастливым инженерам и менее напряженным SRE.

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

Небольшие правки в первой части и программа для связки пары ключей для подписи и домена(имени).

Использование обратного резолвинга(хеш на домен) в смарт-контракте ENS для привязки пары ключей для подписи с доменом(или именем).

Разделяй и влавствуй, или как провести клининг легаси-кода GoLang.

Этот пост является частью большого цикла статей, в которых мы демонстрируем, как создавать приложения на Go, которые легко разрабатывать, поддерживать и с которыми приятно работать в долгосрочной перспективе. Мы делаем это, делясь проверенными методами, основанными на множестве экспериментов с командами, которыми мы руководили, и научных исследованиях («при съёмках фильма ни одно животное не пострадало»).

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

Что касается подхода к «чистой» архитектуре, описываемого далее, то это симбиоз двух идей: разделение Ports и Adapters, а также контроль за тем, как пакеты ссылаются друг на друга...

Я люблю время от времени взять и переделать что-нибудь уже готовое. Цель не в том, чтобы сделать что-то лучше или доказать свою гениальность – я просто ищу опыт. Как получить опыт в разработке сложного инструмента, если ты берешь уже готовые фреймворки и пакеты и просто собираешь из них свое решение? Да, это быстро и часто довольно эффективно, но получаешь ли ты ценный опыт, узнаешь ли о вероятных подводных камнях и начнешь ли ты лучше понимать язык на котором программируешь? Конечно нет.

Сразу скажу: велосипедостроение в коммерческой разработке — зло. Создавать что-то, что уже существует и было отлажено многократно – это бессмысленно. И учитывая время, необходимое для выхода на рынок (Time To Market), это еще и опасно. Кроме того, новый код — это новые ошибки. Именно поэтому часто проще взять готовое и дополнить его до нужного уровня при работе в реальных продуктовых проектах.

Тем не менее, я противоречу сам себе, опровергая то, что сказал ранее. Я разработал на языке GO свой собственный easyjson в рамках именно продуктовой разработки, за что мне бесконечно стыдно. Если кто-то скажет, что я потратил деньги бизнес-заказчика в угоду своим амбициям, я не буду с ним спорить, но у меня были определенные причины, а главное теперь у меня есть интересный опыт. Об этом опыте я и расскажу.

В этой статье мы рассмотрим, почему API-шлюзы стали ключевым элементом экосистемы современных облачных вычислений и как появление Kubernetes API Gateway упростило и стандартизировало работу с ними. 

Статья составлена на основе сразу двух англоязычных материалов. В первом (его мы поместили в самое начало) авторы на примере профессий объясняют роль различных компонентов облачных приложений, а во втором — проводят глубокий анализ все возрастающей значимости API-шлюзов для экосистемы облачных приложений, их места в рамках концепции «Kubernetes — облачная операционная система» и того, как повлияет на дальнейшее развитие API-шлюзов появление Kubernetes API Gateway. 

Привет, Хабр!

Когда приложения становятся все более сложными и распределенными, и эффективное управление ими требует глубокого понимания происходящего внутри. Мониторинг позволяет нам наблюдать за состоянием приложения, собирать ценные метрики о его работе и предоставлять нам обратную связь в реальном времени. Это помогает в обнаружении и устранении проблем до того, как они станут серьезными. Мониторинг также дает возможность планировать масштабирование и оптимизацию, основываясь на данных, а не на предположениях.

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

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

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

В этой статье я расскажу о паре способов увеличить пропускную способность системы с помощью партиций kafka и каналов go. В качестве библиотеки-клиента kafka буду использовать segmentio/kafka-go. Статья будет полезна начинающим go-разработчикам, которые уже знакомы с основными концепциями Apache Kafka (producer, consumer, consumer group, offset, топик, партиция), но еще не задумывались о масштабировании. Все рассуждения будут опираться на игрушечный пример, который, я надеюсь, хотя бы немного напоминает реальные системы.

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

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

Привет, Хабр!

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

gRPC – высокопроизводительный и мощный инструмент для построения микросервисных систем.

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

Всем привет! Меня зовут Ефим Воробьёв, я учусь на программиста в университете, создаю свои проекты и работаю в стартапе. Я с девятого класса разрабатывал веб-приложения на PHP и Python, зарабатывая на фрилансе. Со временем я понял, что хочу развиваться дальше, и поступил на курс «Go-разработчик» в Практикуме. 

С новыми знаниями я пришёл в стартап «умных дверей». Для него я написал плагин для Protobuf, который собирает служебную информацию из proto-файлов, сопоставляет её с информацией от контроллера и преобразует в понятный человеку формат. Это происходит автоматически и без использования рефлексии.

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

В статье представлен ряд советов и методов, которые помогут читателям оценить производительность своих SQL-запросов и улучшить ее при необходимости. Здесь будут рассмотрены некоторые ключевые аспекты оптимизации запросов для SQL Server, чтобы помочь пользователям сделать их более эффективными и быстрыми.

В этой главе мы погрузимся в мир тестовых двойников и рассмотрим, как они влияют на процесс тестирования и разработки. Мы раскроем ограничения традиционных mocks (имитаторы), stubs (заглушки) и spies (шпионы) и представим более эффективный и адаптируемый подход с использованием подделок (fakes) и контрактов (contracts).

Эта глава является продолжением главы "Введение в приёмочные тесты". Готовый код этой главы можно найти на GitHub.

Приёмочные тесты очень важны, они напрямую влияют на вашу способность уверенно развивать систему с течением времени при разумной стоимости изменений.

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

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

В компании $WORK мы столкнулись с необходимостью "плавного завершения работы" наших сервисов. Грациозное завершение работы позволяет убедиться в том, что система правильно финиширует перед завершением. В качестве аналогии можно привести ситуацию, когда человек пытается правильно завершить телефонный разговор перед тем, как перейти к следующей встрече, а не просто бросает трубку на середине фразы.

В этой главе мы расскажем о том, что такое плавное завершение работы в контексте HTTP-сервера, а также о том, как писать "приемочные тесты", чтобы быть уверенным в поведении своего кода.

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

Постараемся рассмотреть шаблоны проектирования на примере языка Go

В первой статье цикла рассмотрим один из самых простых паттернов - Adapter.