Микросервисы *

Привет Хабр! Осень - традиционно богата на ИТ-события, где есть возможность познакомиться с новыми людьми, посетить актуальные доклады и узнать о компаниях на стендах.

Меня по-прежнему зовут Антон и мы подготовили митап по разработке!

Когда?

Начало митапа: 19 октября в 19.00 

Встречаемся: 19 октября в 18:00 на площадке LOFT IDEALISTA (г. Москва, Нижняя Сыромятническая ул., 11, корп. 1, этаж 3)

Так же будет доступна онлайн‑трансляция митапа.

В билете после регистрации будет указана ссылка.

О чем расскажем?

Будем разбираться в вопросе, как писать код так, чтобы при этом создавать меньше багов? Какие "оверхеды" с точки зрения производительности и трудозатрат приносит микросервисная архитектура и нужно ли нам обратно в монолит? А так же постараемся разобраться насколько хорош паттерн Transactional Outbox и есть ли ему альтернатива?

Привет, Habr! Возможно, кто-то меня даже помнит: совсем недавно я создал Python Framework для асинхронных приложений - Propan.

Два месяц назад я делился с вами прогрессом и говорил, что работа над PropanV2 активно ведется. И вот, она завершена. Вот только вместо PropanV2 свет увидел немного другой фреймворк - FastStream, разработкой которого занимался уже не только я, а целая команда AirtAI.

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

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

Java долгое время была и остается фаворитом в enterprise решениях, но все чаще в высоконагруженных проектах предпочтение отдается более "производительным" языкам, таким как Go, а порой даже C++. Но вдруг Java тоже может быть быстрой?

❓Как проектировать системы, которые будут толерантными для различного вида отказов и ошибок?

Что такое отказоустойчивость и стабильность?

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

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

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

В данной статье представлен простой способ реализации микросервисной архитектуры с использованием Kafka, Golang и Docker.

Еще одна статья о том, как можно применять Spring Cloud Config Server при выборе Git репозитория как хранилища конфигураций приложений в облаке и не только в облаке.

Друзья, привет! Если у вас так же много разработчиков как у нас, то и им, возможно,  стало тесно стоять в очереди на deploy в монолите. А значит, вы можете решить перейти на микросервисную архитектуру и дать каждому игроку свой мяч каждой команде свой микросервис. 

Меня зовут Дмитрий Лукиянчук, и я руковожу отделом в IT-платформе СберМаркета. В этой статье я сделаю обзор инструментов, которые у нас есть сейчас, спустя 2,5 года, и какие задачи эти инструменты решают. Вы узнаете, что вам нужно будет сделать, если вы сами решите взяться за построение платформы, а если у вас уже есть своя платформа, то вам будет интересно найти 10 отличий в своей и нашей реализации.

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

Меня зовут Денис Исаев, и я работаю в Яндекс Go. Сегодня я поделюсь опытом решения проблем с отказоустойчивостью из-за ретраев. Основано на реальных инцидентах в системе из 800 микросервисов.

Этот пост — продолжение вымышленных историй о разработчике Васе, который несколько лет назад разбирался с идемпотентностью в распределённых системах. Теперь перед ним новые задачи — получится ли справиться с ними в этот раз? Давайте узнаем.

Привет, Habr! С вами Антон, руководитель Архитектурного комитета компании SimbirSoft. Мы продолжаем цикл статей, посвященных практическому внедрению подхода Design API First в разработку наших проектов. Настало время поделиться практическим опытом использования спецификаций OpenAPI для кодогенерации контрактов backend.

Дисклеймер: Материал публикации в первую очередь передает практический опыт работы системных аналитиков и практикующих архитекторов при интеграции Design API First с непосредственным процессом разработки. Некоторые технические детали реализации будут описаны не полностью.

В книге Криса Ричардсона «Микросервисы: паттерны разработки и рефакторинга», описывается что-то около 20 паттернов, использующихся в микросервисной архитектуре. Все они делятся на 5 больших групп: decomposition patterns, integration patterns, database patterns, observability patterns и cross-cutting concern patterns. Я, узнав про паттерны, которые могут быть применимы в микросервисной архитектуре, немного изучила их и попробовала реализовать один из них. Всем привет, меня зовут Екатерина Попкова, я Java/Kotlin-разработчик в Альфа-Банке, и хочу рассказать, как можно обеспечить консистентность данных в микросервисной архитектуре с помощью применения паттерна «Сага».

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

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

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

У некоторых в команде уже был опыт работы с xa-транзакциями.
Довольно удобный способ, когда у вас есть несколько ACID СУБД. Процесс состоит из двух фаз.

Сегодня расскажем о выборе CNI: что мы использовали в Calico, в каких конфигурациях и как применяем Cilium.

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

Во время технических презентаций нашей технологии – платформы быстрой разработки Jmix – мы, как правило, доходим до вопроса архитектуры создаваемых приложений и часто встречаем грусть в глазах разработчиков, когда сообщаем, что создаваемое приложение имеет монолитную архитектуру. Удивительно, но случается, что команды разработки приложений на Delphi или Oraсle EBS непременно заинтересованы в реализации микросервисной архитектуры, отождествляя ее с чем-то очень современным и самым продвинутым. К счастью, хайп вокруг микросервисов постепенно начал замещаться новой информационной повесткой о необходимости рационального использования ресурсов и выбора типа архитектуры приложений на основе компетенций команд разработчиков и масштабов создаваемого решения. В Jmix есть все необходимое, чтобы создавать современные корпоративные информационные системы в рекордные сроки и с минимальными затратами. Мы понимаем, что монолитная архитектура приложений Jmix не может закрыть все кейсы, но мы верим, что для каждой задачи есть подходящий инструмент. Прочитайте перевод статьи из блога Camunda, возможно, она поможет понять какой тип архитектуры подходит для вашего проекта, чтобы сэкономить время, деньги и нервы.

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

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

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

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

Тестирование микросервисов: просто и эффективно даже для начинающих

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

Всем привет! На связи Николай Мезинов из команды Тинькофф. Предлагаю разобрать интересную задачу — тестирование приложений с помощью микросервиса. Прочитав предыдущее предложение, можно подумать: «Microservice for testing? Are you kidding me?» И я с ухмылкой отвечу: «No, I am not»

Привет, Хабр! Представьте: вы – член большой команды среди десятка таких же команд на крупном и зрелом проекте. Казалось бы, все процессы уже выстроены, все масштабные разработки завершены и теперь остается только с наслаждением разрабатывать и дополнять проект новыми интересными фичами.

Гармония и красота.

Но откуда ни возьмись, появляется она – недоработанная масштабная функциональность, словно щупальцами оплетающая все базовые процессы сразу. Как монстр, затаившийся в пещере, она не давала покоя бизнесу вот уже 3 года, и успела  «сожрать» несколько команд разработки. И вот бизнес снова объявил охоту на монстра… а вы оказались в этом отряде самоубийц героев, призванных положить конец бесчинствам чудовища. 

Цели озвучены, задачи поставлены, команда в ужасе собрана. Но вот незадача, поле для сражений одно: либо ваша команда будет монстра рубить, либо остальные команды – семена сажать. И что же делать?