Что такое дизайн информационных систем

На собеседованиях на позицию middle/senior разработчика часто задают вопросы по распределенным транзакциям в микросервисной архитектуре.

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

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

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

Всем привет!

Будем использовать GitHub Actions. Создадим виртуальную машину в Яндексе. И многое другое.

Сегодня настраиваем деплой из GitHub в Яндекс Облако, используя Docker compose.

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

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

Особенно интересной эта задача становится, когда для интеграции используется Kafka, так как она имеет свои ограничения, касающиеся реализации транзакционности. Вообще, сейчас Kafka достаточно широко применяется именно  в качестве платформы для асинхронной интеграции, это справедливо и для проектов, которые мы в ЛАНИТ — Би Пи Эм реализуем, например, в Альфа-Банке и ВТБ. Поэтому, надеемся, данная тема будет интересна многим.

В этой статье рассмотрим подход к реализации распределённых транзакций (в рамках одного Java-приложения), которые охватывают Kafka и реляционную СУБД. Для этого воспользуемся средствами управления транзакциями, имеющимися в Spring.

Варианты с организацией eventual consistency с помощью типовых паттернов (Saga, Transactional Outbox и др.) и/или использования дополнительных платформ (Debezium, Kafka Connect и пр.) - тема для отдельной статьи (так что ждите продолжения). В этой статье тему затрагивать не будем. 

Если вы знакомы с подходом к документированию, предложенным Саймоном Брауном, вы могли заинтересоваться им, но, возможно, задавались вопросом о его реализации. Этот репозиторий заполняет пробел, представляя конкретный шаблон реализации подхода, который состоящего из:

1. Модели архитектуры программного обеспечения как код, построенные с использованием Structurizr Lite
2. Документация, созданная с помощью шаблона Arc42
3. Журнал решений, созданный с помощью ADR Tools

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

Всем привет! 

Меня зовут Владимир Олохтонов, я руковожу командой разработки в отделе Message Bus, который является частью платформы Ozon. Мы занимаемся разработкой самых разных систем вокруг Kafka, etcd и Vault. В этой статье я расскажу о том, как мы строили линейно масштабируемую gRPC-прокси перед Kafka, способную обслуживать миллионы запросов в секунду, используя Go.

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

Эта статья для DevOps, Kubernetes administrators и SRE инженеров, которым важно и интересно разобраться в том, как устроена сетевая инфраструктура Kubernetes, какое взаимодействие происходит на уровне ядра Linux и различных приложений (Go, Java, Python и т.п.); изучить две обширные технологии eBPF и OpenTelemetry, активно продвигаемые CNCF сообществом. А главное при помощи каких инструментов можно упростить принятие решений инженерам при использовании Kubernetes в своих проектах и продуктах.

Всем привет! В этой статье я бы хотел затронуть тему горизонтального масштабирования SpringBoot-приложений, использующих вебсокеты. Основная особенность таких приложений - наличие состояния (state). Вебсокеты для работы используют постоянное TCP-соединение, собственно оно и является этим состоянием. А наличие состояния обычно вызывает проблемы при масштабировании. 

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

Уверен, что многие, кто интересовался подходами к разработке микросервисной архитектуры, знакомы с трудами Криса Ричардсона на эту тему и уже встречали transactional outbox pattern. А для тех, кто не знаком, кратко расскажу основную идею:

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

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

Привет, Хабр! Меня зовут Гриша Скобелев, я бэкенд-разработчик, у меня есть гитара, кошка и скейтборд. Я так сильно люблю Spring Framework, что назвал кошку в честь него — Веснуша. Возглавляю программный комитет Podlodka Java Crew, где мы делаем классные конференции. Еще я организовал книжный клуб для бэкенд-разработчиков { между скобок }. Хочу поделиться своим опытом развития бэкендера — от собеседования до наработки разных навыков для роста. Тут будет много ссылок, практических советов и инструкций, которые я наработал за время своей карьеры, общения с другими бэкендерами и проведения конференций и консультаций.

В этой статье продемонстрирую и объясню работу Kafka, используя как можно меньше определений и больше практики. Мы рассмотрим 3 сценария работы с Kafka. Для последнего сценария мы поднимем Kafka Cluster в Docker и с помощью UI увидим, как происходит общение между сервисами.