Comments 23
Спасибо за статью, как и первая - очень интересно!
Спасибо.
В итоге, я считаю что микросервисы переоценены. Особенно, как средство повышения быстродействия. Сейчас можно использовать до 2 процессоров по 128 ядер по 2 потока. Не хватит что-ли? И всего-то за 2-5 месячных зарплат программиста.
Это раньше оракл с лицензией на пару десятков ядер стоил миллионы долларов. Всего-то 15 лет назад
Я описал менее травматичные способы масштабирования. И микросервисы тоже описал.
Остальные архитектурные цели в других статьях.
Хабр вообще рассчитан на 5 минутные статьи.
По моему, в плюсах МС никогда не было "повышения быстродействия". Наоборот, всегда пишется о задержке сети.
Как вы можете писать, что "микросервисы переоценены", если сами в предыдущей статье предложили решение на микросервисах?
Решение на микросервисах только для отдельных доменах и больше для безопасности (изоляции системы платежей), а аналитическая система всё равно отрезана из-за cqrs.
Я же написал всё
в плюсах МС никогда не было "повышения быстродействия"
Щас поищем. Scalability наверняка там есть
Щас поищем. Scalability наверняка там есть
Ну так это про масштабируемость. А это явно не слабая сторона микроскрвисов.
Я же написал всë
Вы обосновали выбор микросервисной архитектуры. Почему же вы выбрали именно эту архитектуру, если настолько разочарованы в ней и есть множество решений лучше?
Я не выбрал шаблонный способ "все домены выделить в отдельные микросервисы", я отделил только то что нужно там где нужно.
Я разочарован именно таким штампом в мозгу.
Но именно эту мысль донести не получилось ни в этой статье, ни в предыдущей. Надо ли выделять МС с умом? Надо. Плох ли микросервисный подход от этого? Конечно, нет. У него свои плюсы и свои минусы, и при выделении нового микросервиса мы всегда должны определить - получим ли мы от этого больше, чем потеряем.
А у вас получилось "микросервисы не очень, и есть множество более грамотных подходов".
Видимо, тут родовая травма микросервисов: все почему-то думают терминами микросервисная архитектура есть или нет. А надо думать в каждом частном случае (для каждого домена) - выгодно ли выделить его из монолита или нет. И даже "допустимо ли чтобы вот эти два домена разделились по данным и по единице деплоя и общались по сети".
И да, для большинства доменов "микросервисы не очень, и есть множество более грамотных подходов"
В результате, нафиг не надо никаких тысяч микросервисов с трудоёмкостью не более 2 человеко- месяца как я встречал во многих книжках
Ну так даже если внутри архитектуры есть большой сервис с большой функциональностью, вокруг которого микросервисы - это уже микросервисная архитектура (исключим случаи распределенных монолитов). И в этом случае много минусов микросервисной архиьектуры уже присутствуют, поэтому, например, волноваться за появление еще одной единицы деплоя вряд ли стоит.
Но думать, нужен ли для функциональности отдельный МС- надо всегда.
И да, для большинства доменов "микросервисы не очень, и есть множество более грамотных подходов"
Дак вы сами привели пример микросервисной архитектуры в своей же статье. Почему не выбрали другой подход, если есть лучше?
Спустя годы эксплуатации согласен с тем что микросервисы переоцены)
Мне в таких статьях не нравится то, что они дают только поверхностное представление о подходах.
Проблема не в авторах и не в статьях. Проблема в том, что такие темы можно понять только на практике. Если изучать по теории, то придется изучать множество чужих практик. И это всё займет не мало времени, и не даст того, что дадут свои набитые шишки.
Т.е. для незнающих это даст только поверхностные знания, для знающих вспомнят теорию.
Это на словах может быть легко развернуть кластер с микросервисами, либо наоборот, использовать эффективно все 64 ядра. Но по факту, знающему человеку нет особой разницы, 16 машин по 4 ядра, или одна на 64. Есть задача, есть ресурсы, есть существующая инфра. И уже от вводных начинаешь скакать и придумывать решение на компромиссах. Я не говорю что можно выполнить любую задачу из любых вводных, Я говорю о том, что большинство задач можно решить разными способами и построить разные архитектуры.
Точно так же и в выборе монолит/микросервис. Если соблюдать простой принцип разделения ответственности, то в 90%+ случаев этого будет достаточно для выделения отдельных БЛ в сервисы.
То есть вам нужны примеры перехода от монолита к микросервисам и наоборот от микросервисов к укрупнению в монолит(ы)? Да ещё в большом количестве? Да ещё при прочих равных?
Ну, этим я вряд-ли вас порадую. Хотя, на Хабре можно найти кейсы как в одну так и в другую сторону.
Я вот не видел хорошо обоснованных переходов на микросервисы
Я от вас не жду этого =)
Я боюсь что подобные темы развернуто больше подходят не для статей, а для более глубоких и больших работ.
Я высказал общее мнение по поводу "Статья на тему архитектуры приложение". Т.е. высказал не конкретно о вашей статье, а о всех статьях на эту тему, включая вашу =)
Ну и я хотел подчеркнуть для "неопределившихся", что не нужно засиживаться над продумыванием. Если у вас продумывание архитектуры превращается в бесконечный квест, то лучше сделать как умеете, просто держите код в хорошем состоянии. Что-то сделав, задеплоив, когда начнут пользоваться люди, тогда вы поймёте в какую сторону стоит развивать систему.
То есть вам нужны примеры перехода от монолита к микросервисам и наоборот
Мне кажется посыл был такой - аудитории нужны очень простые сказки. Сложные не нужны. Краткие и ёмкие тоже не нужны.
Ваш текст оценит парочка-другая профессионалов, а остальные либо мимо пройдут, либо минус поставят.
Ну и по вашим выводам:
В конечном итоге цель любой системы — найти баланс между производительностью, масштабируемостью и сложностью, который будет соответствовать требованиям бизнеса
Баланс здесь очень толстый. Если затраты на IT составляют, скажем, 10% от расходов в десятки миллиардов рублей, то плюс-минус несколько сот миллионов никто не заметит. И этим активно пользуются, изобретая микросервисы, велосипеды, ну и прочих монстров.
То есть на уровне бизнеса нет вменяемости при оценке затрат. Они банально не понимают, где можно больше, и где можно меньше. Вы же предлагаете абстрактным последователям забыть о собственном кармане и делать эффективные решения (при этом не давая критериев эффективности, в том числе денежных). Какова будет эффективность абстрактной системы последователей? Как архитектор вы должны дать неприятный для себя ответ.
С другой стороны, краткое напоминание о часто встречающихся шаблонах вполне полезно в качестве шпаргалки. Но в реальной разработке все вопросы, касающиеся целевого проекта, обдумываются гораздо глубже, нежели в наборе предложенных шаблонов. Поэтому там пользы будет немного, разве что мельком пробежаться по тексту, не упустил ли чего. Да и то не факт, что поможет, ведь ключевые места с пониженной эффективностью давно уже обдуманы, стандартные шаблоны давно уже всплывали в голове и либо отвергались, либо принимались в работу.
В целом текст получается почти развлекательный - без занудных деталей (для специалистов, разумеется). Но плотность материала намекает на попытку собрать нечто не совсем развлекательное. Вот эта плотность аудиторию раздражает отсутствием разжёвывания. Но тем не менее, в закладки положили, то есть шпаргалку оценили. Хотя, как уже сказал выше, оценка эта не от профессионалов, а от где-то рядом с темой обитающих, но в тему не погружавшихся. Им-то и нужно разжёвывание. А его нету.
Хотя, с другой стороны, общий подход типа "выяви бутылочное горлышко" мог бы быть подан ещё короче. Ну пусть ещё к нему добавить список инструментов. Вот и всё. Но даже список инструментов лишний, ведь они на разных привычных стеках разные.
Ну и мысль вместо вывода - не переоценена ли важность архитектуры, когда вся она укладывается во фразу про бутылочное горлышко?
Обойдутся без разжевывания
По большому счету я писал эти статьи как рефлексии после курсов архитектора и своих завершенных проектов, поэтому статья нужна мне, а не этим абстрактным читателям. Ну еще обратную связь получить.
не давая критериев эффективности, в том числе денежных
Делал уже такое https://habr.com/ru/articles/803295/
И да, руководитель склонен к разрастанию сложности и стоимости своего проекта, своей личной значимости и незаменимости.
В целом верно, но ещё дополнение =)
Если свести мой посыл до пары предложений, то он будет звучать примерно так:
Если у вас нет никаких вводных данных и ограничений, то делайте так, как хотите, так, как больше опыта, т.к. для большинства задач подойдёт множество разных решений, в том числе монолит/микросервис. Придерживайтесь правилам написания кода, они позволят в будущем с меньшей болью переходить что в одну сторону, что в другую. Но в большинстве случаев это не потребуется.
Размышлять глобально над архитектурой стоит только тогда, когда есть какие-то вводные.
Очень понравилась статья. Однако, поставить "лайк" не хватает кармы.
Господа, подскажите, пожалуйста, какие архитектурные паттерны или методологии используете при формализации входящих требований для того, чтобы на выходе получилось информация, которую можно отдать аналитику для постановки задач программисту?
На работе дали задание описать текущий бизнес-процесс обработки запроса пользователя, который состоит из более чем 20 крупных шагов (которые декомпозируются до 80 мелких шагов) и нескольких тысяч строк кода, располагающегося в разных компонентах системы. Требуется:
а) описать текущий механизм работы кода,
б) описать новый бизнес-процесс, который должен быть похож на имеющийся, но будет отличаться обработкой других видов документов и будет предназначаться для передачи документов в другую систему, отличную от используемой сейчас,
в) предложить архитектурное решение, оптимальное по срокам, сложности и по возможности переиспользует максимум текущего кода.
Как это всё можно описать? С помощью каких диаграмм и нотаций, чтобы было с одной стороны и понятно, а с другой стороны чтобы не было перегруза информации на диаграммах? Использовать sequence? Но на этих sequence вообще будет мешанина из-за множества вызовов и множества кода, участвующего в процессе. И сами эти sequence долго рисовать.
С4 не подойдёт, так как она слишком высокоуровневая. Нужна с одной стороны детализация, с другой стороны возможность словами описать бизнес-процесс, дополнить.
Мне видится путь:
Рисовать в draw.io BPMN как старого так и нового бизнес-процесса (2 закладки на сайте draw.io), показать дельту
С целью типизации передаваемых/принимаемых данных сервисами, а также с целью пояснения хода бизнес-процесса написать текстовый документ, где порядковый номер шага бизнес-процесса будет соответствовать номеру "квадратика" на схеме BPMN.
С целью получения фактуры для аналитика с целью постановки задачи программисту нужно нарисовать структурную схему, указывающую, какие добавились/изменились классы или сервисы.
Описать требуемый к реализации функционал словами (ФТ + НФТ требования)
Правильно ли я думаю?
Судя по сложной обработке заявки это система документооборота где заявка согласуется большим количеством людей или роботов/сервисов или организаций. Какой-то процесс одобрения кредита или заявки. Вот с особенностей предметной области и начинай. Наверняка, там есть какие-то наработки и советы.
Дальше по инструментам
C4 Model — это архитектурная карта:
Поможет программистам понять, какие компоненты нужно модифицировать/добавить (например, новый адаптер для экспорта).
Покажет связи между сервисами, что критично для оценки сложности изменений
BPMN — это масштабируемый инструмент для процессов:
Можете показать высокоуровневые этапы (например, "Прием запроса → Валидация → Обработка → Экспорт") без деталей кода.
Легко выделить изменения между старым и новым процессами (например, новый шаг "Конвертация в формат Системы Б").
Подходит для согласования с бизнесом и аналитиками
State Diagram — это дополнение, а не замена:
Используй его для описания сложных жизненных циклов (например, статусы документа в процессе обработки).
Но он не заменит BPMN/C4, так как не показывает общий процесс или архитектуру
За подробностями реквестирую LLM спать хочу. Вроде, правдоподобно.
1. BPMN: Описание бизнес-процессов
Цель: Визуализировать текущий и новый процессы, выделить различия.
Пример текущего процесса (draw.io):
[Старт] → [Прием запроса] → [Валидация данных] → [Обработка документа] → [Сохранение в БД] → [Передача в Систему А] → [Финиш].
Подпроцесс "Валидация данных" (декомпозиция):
[Проверка формата] → [Проверка цифровой подписи] → [Верификация контента].
Пример нового процесса:
[Старт] → [Прием запроса] → [Валидация данных] → [Конвертация в XML] → [Сохранение в БД] → [Передача в Систему Б] → [Финиш].
Дельта (изменения выделены цветом):
Добавлен шаг "Конвертация в XML".
Изменен конечный этап "Передача в Систему Б".
Как избежать перегруза:
Группируйте 80 мелких шагов в логические блоки (например, "Подготовка данных", "Обработка ошибок").
Используйте гиперссылки в draw.io для переходов между диаграммами.
2. C4 Model: Архитектурное описание
Цель: Показать, какие компоненты системы затронуты изменениями.
Уровень 1 (Контекст):
[Пользователь] → [Система обработки документов] → [Система А]
↓
[Система Б] (новая интеграция)
Уровень 2 (Контейнеры):
[Веб-интерфейс] → [API Gateway] → [Сервис валидации] → [Сервис обработки] → [База данных]
↓
[Адаптер для Системы Б] (новый контейнер)
Уровень 3 (Компоненты):
Сервис обработки:
[DocumentProcessor] → использует [Validator], [Converter], [Exporter].Адаптер для Системы Б:
[SystemBAdapter] → реализует интерфейс [IExporter].
3. UML: Детализация логики
Пример State Diagram (жизненный цикл документа):
[Черновик] → [На проверке] → (Успех) → [Одобрен] → [Экспортирован]
↓ (Ошибка)
[Отклонен] → [Требует исправлений].
Пример Activity Diagram (обработка ошибок):
[Старт] → [Попытка экспорта] → (Успех) → [Финиш]
↓ (Ошибка)
[Повторная попытка] → (Успех) → [Финиш]
↓ (Ошибка)
[Запись в лог] → [Уведомление админа] → [Финиш].
4. Примеры данных и требований
JSON-схема для нового документа:
{
"document_id": "string",
"type": "XML",
"content": "base64",
"metadata": {
"author": "string",
"creation_date": "date"
}
}
Функциональные требования (ФТ):
1. Система должна поддерживать конвертацию документов в формат XML.
2. Экспорт в Систему Б должен выполняться через REST API с аутентификацией по OAuth2.
Нефункциональные требования (НФТ):
1. Время обработки документа не должно превышать 3 секунд.
2. Сервис должен обрабатывать до 1000 запросов в минуту.
5. Интеграция всего вместе
Структура документации:
BPMN-диаграммы (draw.io):
Основной процесс + подпроцессы.
Цветом выделены изменения для нового процесса.
C4-диаграммы:
Контейнеры и компоненты с акцентом на новый адаптер.
UML-диаграммы:
State Diagram для статусов документа.
Activity Diagram для сложных этапов (например, обработка ошибок).
Текстовое описание:
Таблица соответствия шагов BPMN и компонентов C4.
Пример:
Шаг "Конвертация в XML" → компонент "XMLConverter".
Примеры данных:
JSON/XML-схемы.
Примеры запросов/ответов API.
6. Итоговый подход
Для аналитиков:
BPMN + текст — чтобы понимать логику процесса.
Примеры данных — для тестирования.
Для программистов:
C4 + UML — чтобы видеть, какие компоненты менять.
ФТ/НФТ — чтобы оценить сложность.
Для архитекторов:
C4 + BPMN — чтобы оценить влияние изменений на систему.
НФТ чтобы оценить применение архитектурных паттернов и технического стека.
Результат:
Понятная документация без перегруза.
Минимизация рисков за счет четкого разделения слоев (бизнес-логика → архитектура → код).
Экономия времени на согласовании между командами.
Архитектурные паттерны для высокой масштабируемости. Часть 2