Всем привет! Недавно мне выпала возможность разработать шаблон сервиса, который можно было бы использовать как для монолитной, так и для микро‑сервисной архитектуры. Шаблон должен был придерживаться принципов Domain‑Driven Design (DDD). В этом процессе, я столкнулся с двумя интересными проблемами:

Проблема 1: Сложности обеспечения транзакционности базы данных

При разработке сервисов, часто возникает неотъемлемая потребность в использовании транзакций базы данных для обеспечения целостности данных. Однако, при попытке интегрировать транзакционную логику в традиционные подходы, столкнулся с трудностями. Связывание транзакционной логики с логикой слоя базы данных оказалось нетривиальным и привело к нарушению принципов разделения ответственности. Это, в свою очередь, сказалось на тестировании и поддержке кода.

Проблема 2: Нарушение изолированности слоя

В попытке решить первую проблему, некоторые разработчики переносят работу с транзакциями на уровень слоя приложения, чтобы избежать прямой зависимости от базы данных. Однако, такой подход, несмотря на его обоснование, может нарушить изолированность слоев и противоречить принципам DDD и чистой архитектуры. Это, в конечном итоге, затрудняет поддержку приложения и усложняет его масштабирование.
Эти две проблемы стали отправной точкой для исследования применения паттерна Unit of Work и его роли в обеспечении надежности и консистентности данных в контексте Golang и DDD.

В статье я расскажу о своем подходе к решению этих задач.

В продолжение к заметке Инструкция: как быстро настроить GitLab CI/CD на Flutter-проекте.

Больше спасибо автору, всё получилось относительно легко. Я усложнил задачу: поднял GitLab локально на Хакинтоше, прикрутил executor = "docker" вместо "shell". И началось веселье.

При разработке безопасных и/или анонимных приложений всегда наступает такой момент, когда становится необходимым выйти из своих сугубо теоретических размышлений, выйти из скованного дебагом одиночества, выйти из затворничества программных реализаций в открытое общество, безжалостно указывающее на все неправильные, нелогичные, ошибочные, уязвимые части «итогового продукта». Это есть необходимый этап в разрушении ожиданий, идеалов, а также сомнений, чтобы вследствие своей закалки, продукт стал бы поистине безопасным.

Ошибки это один из самых важных аспектов любого языка программирования. То, как обрабатываются ошибки, влияет на приложения многими способами. То, как определяются ошибки в Golang, немного отличается от таких языков как Java, Python, Javascript. В Go ошибки – это значения.

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

Рекомендации по стилю для проектов Google с открытым исходным кодом

Лучшие практики Go

Этот документ — часть документации по стилю Go в Google. Он не является ни нормативным, ни каноничным, это дополнение к «Руководству по стилю». Подробности смотрите в Обзоре.

О документе

Здесь приведены рекомендации по лучшим практикам применения требований «Руководства по стилю» для Go. Это руководство охватывает общие и распространенные случаи, но не может применяться к каждому частному случаю. Обсуждение альтернатив, по возможности, включено в текст руководства вместе с указаниями о том, когда они применимы, а когда — нет.

Полная документация руководства по стилю описывается в обзоре.

# Шаблон backend сервера на Golang — часть 5 — оптимизация Worker pool

Пятая часть посвящена оптимизации Worker pool и особенностям его работы в составе микросервиса, развернутого в Kubernetes.

Представленный Worker pool поддерживает работу с двумя типами задач

• "Короткие" — не контролируется предельный timeout выполнения и их нельзя прервать
• "Длинные" — контролируется предельный timeout выполнения и их можно прервать

Накладные расходы Worker pool на добавление в очередь, контроль очереди, запуск обработки task, контроль времени выполнения task:

• Для "коротких" task — от 300 ns/op, 0 B/op, 0 allocs/op
• Для "длинных" task — от 1400 ns/op, 16 B/op, 1 allocs/op

Для task, которые должны выполняться быстрее 200 ns/op представленный Worker pool использовать не эффективно

Собираются следующие метрики prometheus:

• wp_worker_process_count_vec — количество worker в работе
• wp_task_process_duration_ms_by_name — гистограмма длительности выполнения task в ms с группировкой по task.name
• wp_task_queue_buffer_len_vec — текущая длина канала-очереди task — показывает заполненность канала
• wp_add_task_wait_count_vec — количество задач, ожидающих попадания в очередь

Ссылка на репозиторий проекта.

Шаблон goapp в репозитории полностью готов к развертыванию в Docker, Docker Compose, Kubernetes (kustomize), Kubernetes (helm).

Ссылки на предыдущие части:

• Первая часть шаблона была посвящена HTTP серверу.
• Вторая часть шаблона была посвящена прототипированию REST API.
• Третья часть посвящена развертыванию шаблона в Docker, Docker Compose, Kubernetes (kustomize).
• Четвертая часть будет посвящена развертыванию в Kubernetes с Helm chart и настройке Horizontal Autoscaler.

До недавнего времени у тех, кто пишет на Go было два пути: копипаста и кодогенерация. Фанатом ни первого, ни второго я не являюсь, однако к моей радости, теперь и в Go есть обобщенные типы. Казалось бы, проблема решена! Но не тут-то было, дженерики Go имеют весьма специфические ограничения, которые, портят всю малину. С одним из них мне и захотелось разобраться.

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

При проектировании нового программного решения была поставлена задача выбрать язык и фреймворк. По результатам проведенного исследования был выбран язык Go, как обеспечивающий высокую производительность вместе со скоростью разработки, а также фреймворк Flamingo для реализации принципов Domain Driven Design. Всем, кому интересно узнать, что же за птица такая Flamingo, приглашаю под кат.

Концепция предметно-ориентированного проектирования, она же DDD (Domain Driven Design), описанная Эриком Эвансом, активно используется при построении информационных систем для предприятий. Не стоит пересказывать основные принципы DDD, благо, помимо книги самого Эванса, они описаны в большом количестве статей. Нам важно другое. Эти принципы гораздо проще реализовать в своей информационной системе, если они поддерживаются фреймворком.

Для .Net, например, есть ASP.NET Boilerplate (https://aspnetboilerplate.com/), полностью реализующая все компоненты DDD – Entity, Value, Repository, Domain Service, Unit of Work и еще много всего. Но мы для одной из своих внутренних информационных систем используем Go. 

Мы решили использовать фреймворк Flamingo, распространяемый под лицензией MIT. Он разработан немецкой компанией AOE GmbH в 2018 году и к настоящему моменту “дорос” до версии 3.4 и до 331 звезды на Github. Flamingo используется в информационных системах аэропортов Окланда, Франкфурта и Хитроу, а также в T-Mobile.

Привет! Меня зовут Илья, мне 19 лет, и последние полтора года я занимаюсь продуктовой разработкой на языке Go. 

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

Всем привет! Спешу поделиться кое-какой разработкой. Golang-клиент для NIC.ru API.

Данная статья описывает работу пакета nnhelper, предназначенного для создания и использования нейронных сетей в программах на языке Go.

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

Go пакет nnhelper разработан для быстрого создания нейронной сети и использовании ее в приложениях, написанных на языке Go. Для использования nnhelper не потребуется ничего дополнительного, кроме Go. Пакет nnhelper является надстройкой над пакетом gonn. И это единственная внешняя зависимость.

Давайте я сразу зайду с козырей. Сколько ошибок в коде этой функции вы можете найти за 60 секунд?

func NewConnectionString(host, path, database, user, password string, debug bool) string {
	return fmt.Sprintf(
		"proto://%s/%s?userName=%s&password=%s&database=%s&debug=%t",
		host, path, database, user, password, debug,
	)
}

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

• очевидная — перепутаны параметры;
• не очевидная — параметры не экранируются.

Ладно, признавайтесь — наверняка каждый за 60 секунд смог заметить первую ошибку, но не все из вас смогут заметить вторую. Если ваш список ошибок оказался короче, чем мой — тогда прошу под кат.

При переводе формата отправки транзакций на EIP-1559 столкнулись с задачей по оценке комиссии за транзакцию в зависимости от ожидаемой скорости. Работали долгое время с одним известным источником транзакций, пока не начали приходить ошибки на запросы. Поиск альтернатив, которые бы дали возможность оценить стоимость комиссии в зависимости от ожидаемой скорости не нашлось. Было принято решение еще раз погрузиться в процесс изучения, возможных подходов к решению задачи по оценке комиссии за транзакцию. Задача стоит в том, чтобы сделать оценку в виде комиссии для скоростей fastest, fast, average, safeLow.

В работе над одним проектом нам в компании NUT.Tech понадобилась система событий, работа которой не влияла бы на основной поток выполнения программы. Как ни странно, но мы не смогли найти полностью отвечающую нашим требованиям готовую библиотеку. И тогда, конечно же, мы решили написать ее сами.

В настоящее время существует огромное количество консенсус алгоритмов для блокчейн систем, каждый из которых имеет свои преимущества и недостатки присущие только ему, либо целому классу сходных алгоритмов. Так или иначе, в данное время лидирует две концепции консенсуса - основанные на майнинге (PoW) [1] и форжинге (PoS) [2], которые в свою очередь представляют конкурентную и последовательную модели генерации блоков непосредственно. Такое разделение либо предполагает крайне большое расходование материальных ресурсов, либо представляет собой необходимость комбинации с другими методами консенсуса [3], что приводит к сложности реализации, а следовательно и к проблеме доказуемой безопасности конечного решения [4, с.319]. Альтернативной моделью конкуренции и последовательности может являться алгоритм объединения узлов (PoU), решающий общую задачу сообща и главным преимуществом которого является простота реализации, сродни PoW и быстрота генерации блоков, эквивалентная PoS.

Golang приложение в кластере kubernetes

Привет! Я — golang разработчик в Каруне. Kubernetes сегодня — звезда среди систем оркестровки и контейнеризации приложений. Важно понимать, как с ним работать. Поделюсь примером демонстрационного api приложения, которое написано на golang, и покажу способы взаимодействия с ним.

В этом небольшом туториале, мы чуть подробнее разберем использование Gorilla WebSocket для написания своего websocket сервера, на примере чуть более функциональном, чем базовый пример и более легком для понимания, чем пример чата.

Поставил Linux? Напиши об этом статью. Нашел на Github интересный проект? Напиши об этом статью. Примерная такая логика привела к написанию этой статьи.

Недавно мне потребовалось наполнить базу данных из более чем 300 таблиц со сложной структурой и кучей внешних ключей тестовыми данными. Требования к наполнению минимальны, нужны просто таблицы с заполненными полями, семантика пока не важна. Сделать надо быстро, с минимальными усилиями и как можно ближе к уровню СУБД.

Если вам интересно, как была решена поставленная задача, прошу под кат.