Всем привет! В этой статье рассмотрим наиболее полную реализацию паттерна Transactional Outbox, которую можно будет легко расширять и применять в продакшне. Данная статья будет полезна как для разработчиков, которые еще не встречались с данным паттерном, так и тем, кто уже применял его в своей работе.
Прежде чем перейти к определению паттерна, определим ключевых акторов:
Паблишер - процесс, инициирующий изменения и создающий события.
Консьюмер - процесс, обрабатывающий эти события.
Привет! 👋
В современной разработке мы привыкли решать проблемы производительности стандартным набором инструментов. "База не тянет? Поставь Redis!" — это стало почти рефлексом. Но всегда ли оправдано тащить в инфраструктуру лишний сервис, настраивать сетевые хопы и следить за инвалидацией, если ваша задача — это всего лишь быстрый доступ к небольшому справочнику?
В нашем Open Source проекте BMSTU-ITSTECH/SSOЧитать полностью »
Общеизвестен™ такой подход к проектированию решений и, в частности, решений микросервисных, как Domain-Driven Design. Его суть, для тех кто не слышал этот общеизвестный™ Читать полностью »
В этой статье я хотел бы рассмотреть микросервисные паттерны под другим углом. Когда я начинал изучение микросервисных паттернов, у меня постоянно был вопрос: Так это же было в другом паттерне. Я решил немного структурировать их: объединить по похожим элементам. Кластеризировать микросервисные паттерны достаточно тяжело так как каждый паттерн по‑своему уникален, однако для запоминания на собеседованиях или для себя это сделать можно. Основной контент статьи — картинка, далее идёт описание, чтобы всё было в одном месте.
Сталкивались ли вы с болью при управлении порядком запуска и остановки зависимостей в вашем Go-сервисе?
Разработка больших сервисов неизбежно приводит к необходимости управлять множеством зависимостей. В этом контексте мы говорим о долгоживущих компонентах, чья работа обеспечивается отдельными горутинами: как правило, это блокирующий метод (например, Start), внутри которого крутится цикл обработки.
Примерный сценарий жизненного цикла сервиса выглядит так:
При запускеЧитать полностью »
Всем привет! Меня зовут Яна Курышева, и я тимлид одной из команд разработки бэкенда в Спортсе’’.
Мы – спортивное медиа. Наш продукт – это сайт и приложения со спортивной статистикой, новостями, редакционным и пользовательским контентом, пушами, рекомендациями и комментариями.
За 25+ лет развития архитектура Спортса’’ стала достаточно разнообразной под капотом: десятки микросервисов на Go соседствуют с монолитными Perl- и PHP-приложениями, которые мы планомерно переводим на новый стек.
Чтобы вся система оставалась управляемой, мы активно используем трейсинг с помощью Elastic APMЧитать полностью »
Микросервисы тут, микросервисы там… Из каждого утюга доносится дивный сказ про прекрасный мир микросервисов. А ведь это всего лишь один вид из десятка архитектурных стилей, который имеет свои достоинства и недостатки.
Первый Docker-образ для моего Go-приложения весил 1.92 GB. Для микросервиса на 100 строк — абсурдно. Решил разобраться, куда именно уходит место и как добиться максимально лёгкого образа.
За несколько итераций оптимизации удалось уменьшить образ в 91 раз — до 21 MB production вариант. С дополнительным UPX-сжатием в 213 раз — до 9 MB.
Максимальная оптимизация Docker-образа для Go
Выбор базового образа и техник для каждого сценария
Функционал:
/healthЧитать полностью »
Последние лет 5 работаю над сложными высоконагруженными системами, и хотел бы поделиться нюансами перехода из разработки голосовых роботов в финтех.
Первые два голосовых проекта в разных компаниях мы реализовывали на связках .Net + Asterisk с преобразованием TCP/GRPC трафика. Более интересен именно второй проект в этой области, где в полной мере использовалась микросервисная архитектура (тогда как на первом, в рамках стартапа, несмотря на задел под микросервисы с тз организации кода, у нас сильно проседал деплой).
