Почему больше разработчиков не означает меньше работы

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

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

Рост команды сам по себе не уменьшает объём изменений, необходимых для каждой фичи. Разберём одну из причин, по которой этот объём растёт: сильную связность модулей внутри сервиса. При сильной связности небольшое изменение затрагивает сразу несколько компонентов. Разработчик меняет нужную логику, затем связанные с ней интеграции, проверяет соседний код и исправляет тесты. Задача растёт, хотя бизнес просил примерно то же, что и раньше. Новый сотрудник получает ту же систему зависимостей. Ему тоже нужно разобраться, что затронет его правка. Дополнительные люди могут взять часть работы, но сам объём изменений от этого не сокращается.

Разделение на микросервисы эту проблему само по себе не решает. Даже внутри отдельного сервиса бизнес-правила могут быть тесно связаны с конкретной базой данных или внешним API. Поэтому полезно посмотреть, сколько кода приходится менять из-за одной новой интеграции.

Как проверка паспорта затрагивает обработку заявки

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

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

Из-за этого задача по замене интеграции затрагивает сценарий целиком. Чтобы ограничить объём правок, нужно отделить получение результата проверки от решения о том, что делать с заявкой.

Как отделить бизнес-правила от технических деталей

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

В модели чистой архитектуры выделяют четыре области:

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

Зависимость здесь означает, что один модуль использует определения другого: например, его интерфейсы или классы. Контроллер может обращаться к сценарию приложения. Сценарий при этом не должен зависеть от конкретного контроллера или реализации доступа к базе.

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

Поэтому проверить архитектуру можно по конкретному месту: от чего зависит сценарий обработки заявки? Если ему нужен класс клиента определённого API или конкретный модуль доступа к БД, техническая реализация всё ещё влияет на его устройство.

Что останется прежним при смене провайдера

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

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

Это работает, пока сохраняются бизнес-правила и приложению доступны нужные данные. Если ФИО или код подразделения раньше вообще не собирали, потребуется изменить и получение этих данных. Один адаптер не решит эту часть задачи. А если изменились условия, по которым заявка проходит дальше, правки понадобятся и в бизнес-логике.

С базой данных действует тот же принцип. Сценарий обращается к интерфейсу репозитория, а конкретная реализация работает с БД через SQL, ORM или собственный модуль доступа к данным. При переходе с PostgreSQL на Oracle это помогает сохранить код бизнес-правил, если их удалось отделить от особенностей конкретной БД.

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

Почему на старте получается три дня вместо одного

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

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

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

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

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

Как сохранить границы, когда фича нужна вчера

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

В разборе есть три способа, рассказывающие, как с этим работать.

• Подготовить шаблон сервиса. Заранее задать структуру для сущностей, сценариев и репозиториев, а также интерфейсы между ними. Тогда разработчику будет проще добавить логику в готовую структуру. При этом команде всё равно нужно понимать назначение границ и соблюдать их.
• Зафиксировать технический долг. Если ради срока пришлось связать сценарий с конкретной интеграцией, описать принятое решение и запланировать рефакторинг. Так временное упрощение останется видимой задачей.
• Объяснять затраты на конкретных изменениях. Обсудить с бизнесом, что произойдёт при замене сервиса проверки: где потребуется новый запрос, какие части приложения останутся прежними и почему команда тратит время на их разделение сейчас.

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

С чего начать в существующем проекте

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

После такого разделения у следующей замены провайдера должна появиться понятная область изменений. Если бизнес-правила остались прежними, а команде снова приходится переписывать их реализацию, граница между сценарием и интеграцией ещё требует работы.

Чем отличаются монолит, модульный монолит и микросервисы

Представим приложение магазина. В нём есть заказы, каталог товаров и биллинг, который рассчитывает скидки и выставляет счета. Эти части связаны бизнес-логикой: для персональной скидки нужна сумма прошлых заказов, а при покупке нужно знать, есть ли товар на складе.

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

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

По мере роста проекта становится важнее то, как устроен код внутри приложения. Если расчёт скидок, обработка заказов и работа с товарами связаны, изменение одной функции может затронуть соседние. Разработчику приходится учитывать всё больше связей, а проверка последствий занимает больше времени.

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

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

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

Здесь появляется возможность выпускать изменения одного сервиса независимо от остальных, пока сохраняется совместимость взаимодействия. Вместе с ней возникает ответственность за контракт: сервис заказов должен возвращать данные в том виде, который понимает биллинг. Если изменение затрагивает обе стороны, командам нужно согласовать обновление.

Что меняется, когда вызов функции становится сетевым запросом

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

После выделения заказов в сервис путь становится длиннее. Биллинг отправляет запрос к его API. Сервис заказов обращается к своей базе, формирует ответ и передаёт его обратно. Затем биллинг разбирает полученные данные и рассчитывает скидку.

На каждом таком переходе появляется дополнительная работа. Данные нужно подготовить к передаче и восстановить на другой стороне, дождаться ответа по сети, обработать результат. Эти расходы могут быть приемлемыми для одной операции. Если пользовательский запрос запускает длинную цепочку обращений, время ожидания начинает зависеть от всех её участников.

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

Контракт API тоже становится частью работы. Если сервис меняет формат ответа, нужно учесть потребителей этих данных. Изменение, которое внутри монолита могло попасть в один релиз, в распределённой системе может потребовать обновления нескольких сервисов в согласованном порядке. При частых совместных изменениях ожидаемая независимость релизов сокращается.

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

Стоимость взаимодействия покажем на примере системы мониторинга качества видео Amazon Prime Video. Сначала она работала как распределённое решение на AWS Lambda и Step Functions. При увеличении нагрузки обмен данными и управление выполнением компонентов потребовали слишком больших расходов. Команда объединила систему в монолитное приложение, после чего расходы на неё снизились примерно на 90%.

Результат относится к конкретной системе мониторинга с её характером вычислений и обмена данными. Для выбора архитектуры здесь полезно проверить, какую долю работы составляют полезные вычисления, а какую занимает координация компонентов. Чем чаще элементы приложения обращаются друг к другу, тем внимательнее нужно оценивать стоимость их разделения.

Как масштабировать монолит и микросервисы

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

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

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

Воркеры и очереди задач

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

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

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

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

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

Чтение и запись в базе данных

Для распределения нагрузки на чтение можно использовать реплики БД. Основная база принимает изменения, а её копии получают эти изменения через механизм репликации. Часть запросов на чтение направляют к копиям, разгружая основную базу.

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

Разделение по сервисам позволяет распределить запись между разными базами, когда данные принадлежат разным частям системы. При этом сильно нагруженная база конкретного сервиса всё равно может потребовать масштабирования. Оценивать нужно каждый участок, на котором сосредоточена работа.

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

Что усложняется при разделении данных между сервисами

Заказы связаны с товарами независимо от того, где выполняется код. Если обе сущности хранятся в общей реляционной БД, данные о них можно соединить запросом с JOIN. База выполняет связанную операцию, а приложение получает результат.

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

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

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

При выполнении связанных изменений внутри одной БД можно использовать общую транзакцию. Она позволяет применить предусмотренные изменения вместе или отменить их при неудаче. Разработчик описывает операцию с учётом возможностей и правил работы выбранной базы.

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

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

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

По каким признакам выбирать архитектуру для проекта

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

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

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

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

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

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

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

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

Чтобы обсудить решение на конкретных примерах, команда может ответить на несколько вопросов:

• Какие части приложения обычно меняются вместе и почему им нужен общий релиз?
• Какая функциональность требует самостоятельного масштабирования и где именно возникает нагрузка?
• Какие данные потребуются выделенному сервису для выполнения обычной операции?
• Кто будет отвечать за его развёртывание и разбирать проблемы в эксплуатации?
• Можно ли разрабатывать и проверять этот сервис, запуская только необходимые ему компоненты?

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

Как понять, что компонент готов стать отдельным сервисом

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

Для выделения нужен компонент с понятной самостоятельной обязанностью. Его должно быть возможно описать через выполняемую работу и необходимые данные. Полезно заранее проследить основные сценарии: какие запросы приходят на вход, откуда берётся информация для их обработки и кому потребуется результат.

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

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

Затем нужно сопоставить ожидаемую пользу с работой по переносу. У компонента появится собственное развёртывание, его взаимодействие с остальным приложением потребуется организовать и проверить. Если выделяются данные, отдельно планируют согласование операций, которые раньше выполнялись внутри одной БД.

Для существующего проекта такие изменения входят в более широкую работу по модернизации ПО. Centicore Group занимается обновлением легаси-кода, баз данных и инфраструктуры; в услугу входят рефакторинг и обновление технологического стека. Если команда планирует переработку работающей системы, можно обсудить её модернизацию с Centicore Group.

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

Итого

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

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

Речь пойдёт не о сравнении синтаксиса в вакууме, а о бэкенд-сервисах: API, шлюзах, обработке событий, парсинге данных и всём, что работает под нагрузкой. В статье — авторский взгляд на материал блога инженера Pooya Golchian, дополненный российским контекстом и поправками на реальное состояние экосистем.

Go остаётся стандартным выбором для большинства микросервисов: быстрая компиляция, простота найма, огромная экосистема.

Rust выигрывает там, где важны предельная задержка и контроль над памятью, но требует опытной команды и времени на обучение.

Zig подходит для узких, критичных к производительности участков и для интеграции с существующим C-кодом, но экосистема пока незрелая.

В больших системах работает гибридный подход: Go для скорости разработки, Rust/Zig для горячих путей.

Мигрировать стоит только после профилирования: оптимизация без замеров обычно дороже, чем выгода.

Почему именно эти три языка

В 2026 году для нового backend-проекта по-прежнему можно взять Java, C#, Python или Node.js. Но если речь заходит о высоких нагрузках, низкой задержке и контроле над ресурсами, внимание смещается к трём игрокам.

• Rust — язык с владением и заимствованием, дающий безопасность памяти без сборщика мусора.
• Go — язык с простой моделью конкурентности, статической линковкой и минималистичной философией.
• Zig — язык в духе C, но с современной системой сборки, comptime и явным управлением памятью.

Все трое компилируются в нативный код, дают один бинарник на выходе и не требуют виртуальной машины. Именно это отличает их от Java, C# и Python на старте.

Rust: максимум производительности, максимум сложности

Сильные стороны

• Безопасность памяти на этапе компиляции — нет use-after-free, data races и большинства утечек.
• Нулевая стоимость абстракций: высокоуровневый код часто компилируется так же эффективно, как ручной C.
• Мощная модель конкурентности поверх tokio или async-std.
• Зрелая экосистема: axum, actix-web, serde, sqlx.

Слабые стороны

• Крутая кривая обучения: borrow checker требует перестройки мышления.
• Долгая компиляция: полная пересборка крупного проекта занимает десятки секунд и минуты.
• Меньше кадров на рынке, чем у Go или Java.
• Итерации медленнее: каждая ошибка компилятора — это время на переделку.

Когда выбирать Rust

Rust логичен, если вы строите инфраструктуру — прокси, базы данных, очереди, edge-сервисы — или если профилирование показывает, что горячий путь съедает CPU и память. Примеры из продакшена: Cloudflare использует Rust на edge, Discord переписал на Rust часть read-path сервисов.

Go: скорость разработки в масштабе

Сильные стороны

• Компиляция за секунды и один статический бинарник для деплоя.
• Встроенные горутины и каналы — простая, но мощная конкурентность.
• Отличная стандартная библиотека и быстрое тестирование через go test.
• Большая база инженеров и проверенные практики в крупных компаниях.

Слабые стороны

• Сборщик мусора может давать всплески задержек, хотя в последних версиях паузы сокращаются.
• Меньше контроля над расположением памяти и размером структур.
• Пиковая пропускная способность ниже, чем у Rust и Zig, на CPU-bound задачах.
• Система типов и обработка ошибок минималистичны — кому-то этого достаточно, кому-то не хватает.

Когда выбирать Go

Go — выбор по умолчанию для команд из 5–50 человек, которым нужно быстро запускать CRUD-сервисы, API-шлюзы и data pipeline. Uber, Google и Яндекс активно используют Go в микросервисах. Если главная метрика — time to market, а не последний процент производительности, Go обычно выигрывает.

Zig: новый игрок с C-душой

Сильные стороны

• Производительность уровня C с более современным синтаксисом и системой сборки.
• comptime — выполнение кода на этапе компиляции для генерации оптимизированных структур.
• Прямое взаимодействие с C без FFI-слоёв.
• Маленькие быстрые бинарники и явное управление памятью.

Слабые стороны

• Экосистема backend-фреймворков и библиотек пока существенно меньше, чем у Rust и Go.
• Сообщество и количество инженеров на рынке ограничены.
• Ручное управление памятью перекладывает ответственность на разработчика.
• Некоторые части языка и стандартной библиотеки всё ещё эволюционируют.

Когда выбирать Zig

Zig хорош, когда нужна C-производительность, но с более удобным инструментарием, или когда приходится интегрироваться с существующим C-кодом. Пример из продакшена: финансовая база данных TigerBeetle написана на Zig. Для универсального backend в 2026 году Zig ещё рано называть mainstream-выбором.

Сравнение в цифрах

Ниже — иллюстративные цифры из оригинального материала, полученные на AWS c7g.2xlarge (Graviton3). Относитесь к ним как к точке отсчёта, а не как к гарантии для вашего сервиса: в реальности большее значение имеют I/O, запросы к базе данных и сетевая задержка.

Бенчмарки:
HTTP throughput — Rust 892K req/s, Go 734K req/s, Zig 812K req/s.
JSON-сериализация — Rust 1,2M/s, Go 890K/s, Zig 1,1M/s.
Память на 10K соединений — Rust 45MB, Go 78MB, Zig 38MB.
Размер бинарника — Rust 8,2MB, Go 12,4MB, Zig 6,1MB.
Время компиляции с нуля — Rust 42s, Go 3,2s, Zig 18s.
P99 latency — Rust 2,1ms, Go 3,8ms, Zig 2,4ms.

Реальные истории миграции

Discord: Go → Rust

Discord переводил read-path сервисы с Go на Rust из-за пауз сборщика мусора, которые проявлялись в хвостовых задержках. По данным компании, throughput вырос в несколько раз, а tail latency снизилась. Ключевой вывод: мигрировать стоит только горячие пути, а не весь сервис целиком.

Uber: Python → Go

Uber мигрировал часть микросервисов с Python на Go, чтобы обойти ограничения GIL и упростить масштабирование. Переход занял годы, но зато проходил постепенно: Go-совместимость и простота языка позволяли быстро обучать команду.

TigerBeetle: C++ → Zig

TigerBeetle — финансовая база данных, ориентированная на корректность и производительность. Команда выбрала Zig, отказавшись от сложности C++ и сборщика мусора. comptime позволил генерировать специализированные структуры данных под задачу.

Гибридная архитектура

На практике редко выбирают один язык на весь проект. Гораздо чаще используют гибрид:

• API Gateway и CRUD — Go: быстро писать, просто деплоить, легко искать людей.
• Горячие пути — Rust: низкая задержка и контроль над памятью.
• Специализированные компоненты — Zig: парсинг бинарных форматов, криптография, интеграция с C.

Такая схема позволяет получить скорость разработки в большинстве сервисов и производительность там, где она действительно нужна. Главное — разделять систему по чётким границам и не превращать проект в зоопарк ради самого зоопарка.

Что выбрать в 2026 году

Выбор зависит от приоритетов команды и задачи:

• Нужна скорость разработки и лёгкий найм — Go.
• Нужна максимальная производительность и безопасность памяти — Rust.
• Нужна C-производительность с современной сборкой и интеграцией с legacy на C — Zig.
• Команда маленькая и сроки горят — начинайте с Go, профилируйте, мигрируйте горячие пути при необходимости.
• Строите базу данных, прокси или edge — Rust становится очень сильным кандидатом.

FAQ

Выводы

Rust, Go и Zig — не конкуренты в прямом смысле, а инструменты для разных условий. Go задаёт темп разработки, Rust отвечает за надёжность и производительность, Zig покрывает специализированные ниши. Лучшая стратегия для 2026 года — начать с Go, измерять, а затем точечно внедрять Rust или Zig там, где данные это оправдывают.

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

Источник: Pooya Golchian — Rust vs Go vs Zig: High-Performance Backend Services in 2026.

Service Topology — это не статическая схема из вики, а динамическая карта связей между сервисами. Она обновляется по мере того, как меняется трафик, появляются новые зависимости или старые исчезают. Карта показывает не только «кто с кем говорит», но и контекст: уровень доступности, бизнес-домен, владельца и текущее состояние здоровья.

Если тема микросервисов для вас новая, начните с базового разбора «Что такое микросервисы», а если выбираете архитектуру для проекта — сравните варианты в материале «Монолит или микросервисы». Авторский разбор внутреннего устройства Netflix читайте в статье «Разработчик изучал систему рекомендаций Netflix месяцами».

• Netflix объединила три источника данных: eBPF-сетевые потоки, IPC-метрики и распределённые трейсы.
• Каждый источник строит свой граф; общий вид получается параллельным слиянием слоёв.
• Карта обновляется почти в реальном времени и отвечает на запросы быстрее секунды.
• Инженеры используют её для поиска причин сбоев, оценки зоны поражения и планирования изменений.
• Подход можно перенести в любую распределённую систему, где нужно понимать зависимости.

Почему обычной наблюдаемости мало

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

Инженеру в три часа ночи приходится мысленно склеивать данные из разных источников. Это медленно, чревато ошибками и добавляет стресса. Netflix проанализировала тысячи обращений в поддержку за четыре года и увидела повторяющиеся вопросы: кто мои upstream и downstream, что упадёт вместе со мной, почему сервис отображается в панели мониторинга как Unknown (неизвестный сервис). Ответы на них требовали единого представления о зависимостях.

Три источника данных Service Topology

Главный вывод Netflix: ни один источник не рассказывает всю историю. Поэтому система строит три независимых графа и объединяет их по запросу.

Сетевые потоки eBPF

На сетевом уровне Netflix собирает потоки ядра через eBPF. Это даёт полноту: сюда попадают все соединения, независимо от того, инструментирован сервис или нет. Слой показывает связи между кластерами и приложениями такими, какими они есть на самом деле. Недостаток — не хватает прикладного контекста: видно, что сервис А достучался до IP-адреса сервиса Б, но неизвестно, какой конкретно endpoint вызывался.

IPC-метрики

На прикладном уровне собираются метрики межпроцессного взаимодействия. Когда сервис обращается к другому через gRPC, GraphQL или REST, он фиксирует endpoint, ошибки, задержки и протокол. Этот слой даёт детали, которых нет у сетевого: какой именно путь вызывается и с какой вероятностью ошибки. Ограничение очевидно: если сервис не отправляет метрики, его вызовов здесь не будет.

Распределённые трейсы

Третий слой — трейсинг запросов от начала до конца. Он показывает не «может ли сервис А позвонить сервису Б», а «звонил ли он в рамках этого конкретного пользовательского запроса». Это помогает увидеть поведение во время выполнения, ветвления, фича-флаги и редкие пути. Поскольку трейсы собирают выборочно, редкие сценарии могут не попасть в агрегированный вид.

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

Как собирают Service Topology

Приём и обработка потоков

За кулисами работает конвейер, который держит миллионы событий в секунду. Потоки сетевых логов читаются из Kafka в нескольких регионах AWS. Для обработки Netflix использует Apache Pekko Streams — форк Akka, который разбивает нагрузку по группам автомасштабирования и сам управляет обратным давлением.

Восстановление прямых связей

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

Готовая топология хранится в графовой базе Netflix — абстракции поверх распределённого хранилища «ключ — значение». Она заточена под быстрый обход графа в несколько хопов. Поверх базы — gRPC-API с фильтрами по уровню доступности и домену, постраничным выводом больших выборок и ответом менее чем за секунду.

Хранение и API

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

Что даёт инженерам

Интерфейс и API дают инженерам несколько рабочих сценариев — от ручного расследования до автоматических проверок.

• Видеть upstream и downstream для любого сервиса с фильтрами по уровню доступности и домену.
• Переключаться между единым видом и отдельными слоями: только сеть, только IPC или только трейсы.
• Одним кликом переходить от узла топологии к логам, трейсам и детальным метрикам.
• Оценивать зону поражения перед отключением сервиса на обслуживание и понимать, кого уведомлять.
• Накладывать статус здоровья на граф и быстро понимать, локальная ли это проблема или каскадный сбой.
• Обращаться к топологии программно — например, чтобы автоматически проверять классификацию доступности критичных сервисов.
• Смотреть историю зависимостей и находить, что изменилось перед инцидентом.

Как перенести в свою систему

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

Чек-лист для первых шагов:
1. Выберите один настоящий источник связей: логи балансировщика, агент на хосте или метрики вызовов.
2. Не пытайтесь сразу построить идеальную модель — начните с автоматически обнаруженных рёбер.
3. Добавьте контекст: владельца сервиса, уровень критичности и домен.
4. Сделайте карту доступной программно, а не только в интерфейсе — инцидент-боты и скрипты будут благодарны.
5. Проверяйте актуальность: в динамичной среде карты, устаревшие на несколько часов, быстро теряют ценность.

Для иллюстрации вот минимальный скрипт, который строит рёбра графа из логов балансировщика:

Часто задаваемые вопросы

Выводы

Service Topology — не просто красивая картинка для панели мониторинга. Это операционная основа, которая ускоряет расследования, снижает риск изменений и даёт автоматическим системам общую картину инфраструктуры. Netflix называет её knowledge graph foundation — фундаментом для интеллектуальной автоматизации, в том числе для автоматического поиска первопричины сбоев.

Service topology provides the knowledge graph foundation that makes this kind of intelligent automation possible.

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

Источники

• From Silos to Service Topology: Why Netflix Built a Real-Time Service Map

EchoBird — это open-source настольный лаунчер для ИИ-агентов и локальных больших языковых моделей (LLM). Написан на Rust + Tauri, работает на Windows, macOS и Linux. Автор, разработчик с ником edison7009, собрал его после того, как друзья не раз просили помочь «поставить этот ваш ИИ» на новой машине. Сейчас проект насчитывает 2200 звёзд на GitHub, 162 ответвления и 112 релизов; актуальная версия — v5.2.7.

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

• EchoBird — это open-source менеджер ИИ-инструментов на Rust + Tauri для Windows, macOS и Linux.
• Четыре сценария: установка и починка агентов, локальные LLM, личные ИИ-проекты и единое средство запуска приложений.
• Model Nexus объединяет API-ключи, модели и протоколы OpenAI / Anthropic в одном центре конфигурации.
• Локальные модели запускаются через llama.cpp, vLLM или SGLang с автоподбором под железо.
• Расширяется через plugin.json: новый инструмент можно добавить без изменения кода приложения.

Четыре сценария, которые покрывает EchoBird

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

Установка и починка агентов

EchoBird сканирует систему, находит уже установленные инструменты и проверяет зависимости. Если чего-то не хватает, ведёт установку в режиме диалога. Если что-то сломалось — запускает починку. Поддерживаются Claude Code, Codex CLI, OpenCode, Aider, Hermes Agent, MiMo Code от Xiaomi и собственная линейка агентов автора — OpenClaw, ZeroClaw, NanoBot и PicoClaw. Новый инструмент добавляется через файл plugin.json, поэтому сообщество может расширять список без запросов на слияние в основной репозиторий.

Локальные LLM в один клик

Встроены три runtime'а под разное железо: llama.cpp для CPU и слабых машин, vLLM для серверных GPU NVIDIA на Linux и SGLang для агентских сценариев с жёстко заданным выводом — например, когда модель должна вернуть JSON строго по схеме. EchoBird сам определяет наличие видеокарты NVIDIA и предлагает runtime с подходящими параметрами — например, размер батча и offloading слоёв на GPU. После запуска модель отдаёт совместимые с OpenAI и Anthropic endpoints — остальные инструменты не замечают подмены. Про локальный запуск LLM через Ollama у нас есть пошаговый гайд.

Мои ИИ-проекты

Раздел для утилит, демок, игр и скриптов, созданных в режиме vibe coding (импровизационной разработки с ИИ), которые рождаются за один вечер с ИИ-помощником. Вместо того чтобы искать директорию и вспоминать команду запуска, проект живёт в едином списке с кнопкой «старт».

Менеджер приложений

Центральная панель запуска для всего, что уже установлено. Можно запустить Claude Code, Codex CLI или локальную модель из одного списка, не открывая отдельные терминалы и окна.

Model Nexus: единая точка входа для моделей

Главная архитектурная идея — Model Nexus. Это прослойка между приложением и поставщиками моделей, которая хранит API-ключи, проверяет задержки, транслирует OpenAI- и Anthropic-совместимые протоколы.

Без него каждый инструмент требует своей конфигурации: Claude Code требует свой API-ключ, Codex CLI — свой .env, Hermes Agent — свой config.toml, а локальный vLLM — свой путь к модели. Model Nexus заменяет это на «ввёл один раз, используешь везде».

Поддерживаются 14+ поставщиков: Anthropic, OpenAI, Gemini, xAI Grok, Mistral, Together AI, DeepSeek, MiniMax, GLM, SiliconFlow, а также Ollama, llama.cpp, vLLM, SGLang, OpenRouter и любой OpenAI-совместимый endpoint. Каждому агенту можно назначить свой протокол независимо от остальных.

Почему Tauri + Rust, а не Electron

Выбор стека для менеджера, который управляет чужими тяжёлыми моделями, логичен. Tauri даёт бинарник менее 10 МБ против типичных 100+ МБ у Electron. Rust напрямую дёргает системные API, работает с файловой системой, процессами и детекцией GPU без лишних мостов. Для инструмента, который постоянно запускает подпроцессы и читает конфигурации, это надёжнее и предсказуемее.

Сравнение: классическая установка Claude Code и EchoBird

Традиционный путь — пять шагов, каждый из которых может обломаться:

1. Проверить версию Node.js (нужен 18+).
2. Убедиться, что права npm настроены правильно.
3. Выполнить npm install -g @anthropic-ai/claude-code.
4. Прописать переменную окружения ANTHROPIC_API_KEY.
5. Проверить: claude --version. При смене машины — повторить.

Путь через EchoBird — короче в разы:

1. Открыть EchoBird.
2. Install & Repair → Claude Code → установить в один клик.
3. Model Nexus → ввести API-ключ один раз для всех инструментов.

Расширение через plugin.json

Новый инструмент описывается JSON-файлом с командами установки, проверки, починки и запуска. Пример минимального плагина:

Такой подход отделяет ядро приложения от рецептов установки. Теоретически сообщество может добавить плагины для российских моделей — например, GigaChat, YandexGPT или локальных сборок на базе Saiga — без необходимости ждать официальных обновлений.

Что нового в ветке v5.x

Релизы выходят активно. Несколько примечательных изменений последних недель:

• v5.2.4 — зеркала для установки из Китая (Tsinghua, Alibaba, Huawei), чтобы зависимости качались без VPN.
• v5.2.0 — переключатель Responses-протокола OpenAI для моделей, которые говорят на нём нативно, например MiniMax-M3 и Qwen3.7.
• v5.2.6 — поддержка MiMo Code от Xiaomi и починка автоуплотнения контекста в Codex V2, из-за которого разговоры обрывались.
• v5.2.4 — нативные элементы управления окном и стандартные горячие клавиши macOS (⌘W, ⌘M, ⌘,).

Как попробовать

Безопасность:
Перед запуском любого установочного скрипта из интерната рекомендуем открыть его в редакторе или скачать официальный инсталлятор из GitHub Releases.

После установки: открываете Model Nexus, добавляете ключи; переходите в Install & Repair, выбираете инструменты; запускаете их из App Manager. Для локальных моделей — Local LLM → runtime → модель.

Кому пригодится

• Тимлидам и DevRel'ам, которым часто нужно «поднять окружение» на новой машине коллеги.
• Разработчикам, кто переключается между рабочими и личными ПК и устал от повторяющегося адаптации.
• Энтузиастам локальных LLM, которым надоело вручную ставить CUDA, vLLM и искать пути к моделям.
• Авторам плагинов, которые хотят добавить поддержку отечественных или нишевых ИИ-сервисов.

Выводы

EchoBird не изобретает ИИ-инструменты заново — он убирает трение на границе между «хочу попробовать» и «уже работает». Model Nexus решает проблему разрозненных конфигураций, встроенные runtime'ы — проблему локальных моделей, а плагины — проблему поддержки новых сервисов. Выбор Rust + Tauri выглядит обоснованным: приложение остаётся лёгким, хотя самые тяжёлые модели грузятся вне его.

EchoBird родился из собственной боли: друзья постоянно просили меня установить Claude Code на их машины. Я хотел, чтобы любой мог нажать одну кнопку и получить рабочее окружение, не разбираясь в Node.js, npm и переменных окружения.

Если в вашем рабочем процессе регулярно фигурируют Claude Code, Codex CLI, Aider или локальные LLM, стоит потратить несколько минут на установку и посмотреть, сколько ручных шагов отпадёт.

Источники

Оригинальный материал: Open Source Project of the Day (#97): EchoBird — DEV Community. Дополнительно: репозиторий EchoBird на GitHub, официальный сайт.

Проблема в том, что сами инструменты и подходы быстро меняются. Если архитектура остается только в Confluence и устных договоренностях, она устаревает быстрее, чем код. Через пару спринтов диаграммы уже "не про то", а архитектурные решения не проходят проверку реальностью. Именно здесь появляется Architecture as Code( AaC) - подход, в котором архитектура живет как инженерный артефакт: версионируется в Git, проверяется в CI/CD и развивается через MR. В этой статье разберем практическую связку LikeC4 для модели и AsciiDoc для документации.

Если кратко, то

• Архитектура как код - это не про красивые схемы, а про проверяемые ограничения.
• LikeC4 дает C4-модель как исходники (.c4) с диффами, ревью и тестами.
• AsciiDoc фиксирует контекст решений, требования и обоснования рядом с моделью.
• Архитектурные изменения ведутся в отдельном репозитории с собственными MR и проверками.

Почему "архитектура в документах" ломается? Обычный сценарий выглядит примерно так:

• диаграммы создаются, но как правило не обновляются;
• сервисы и контракты меняются каждую неделю;
• ревью кода проходит без сверки с архитектурными ограничениями.

Итог - "документированная архитектура" живет отдельно от системы.

AaC подход закрывает этот разрыв:

• артефакты архитектуры хранятся в отдельном архитектурном репозитории;
• ограничения формулируются как правила;
• правила проверяются автоматически в pipeline.

Что именно кодируем?

Практически полезный минимум:

• контекст системы и внешние акторы;
• контейнеры и ключевые компоненты;
• интерфейсы, протоколы, синхронные и асинхронные взаимодействия;
• инфраструктурные ограничения (например, допустимые зависимости и boundary rules);
• ссылки на ADR, OpenAPI, схемы БД и эксплуатационные метрики.

Здесь важно не "оцифровать все", а начать с того, что чаще всего вызывает расхождения между планом и реализацией.4.

Роль LikeC4

LikeC4 - это язык описания C4-модели и набор инструментов вокруг нее.Что это дает команде:

• диаграммы задаются текстом, а не мышкой;
• изменения видны в git diff;
• модель можно тестировать и линтить;
• из модели собирается статический сайт с навигацией по представлениям.

Основные возможности LikeC4 (по документации)

Официальная документация: likec4.dev

• DSL для описания specification, model, views и deployment-слоя в одном источнике истины;
• views как проекции модели - с разным уровнем детализации, scoped views и расширением (extends) без дублирования;
• предикаты для управляемого включения элементов и связей в конкретное представление;
• генерация артефактов "из коробки" - статический сайт, экспорт диаграмм, интеграция в документацию и UI;
• API/MCP-интеграция для доступа к архитектурной модели из внешних инструментов и AI-ассистентов.

AI-skills для генерации схем LikeC4В LikeC4 есть отдельный раздел по AI-инструментам: AI Tools.

Практически это дает два уровня автоматизации:

• Agent Skills - подключают для AI-ассистента справочник DSL и снижают риск "галлюцинаций" в синтаксисе;
• MCP Server - дает LLM доступ к текущей архитектурной модели, чтобы строить и уточнять схемы на основе реального контекста проекта.

Базовое подключение skills в проект:

Пример на базе моего проекта

Публичный пример с визуализацией архитектуры в LikeC4: system-design

Исходный код проекта: system-design-codeКратко о проекте:

• это практический стенд Architecture as Code с LikeC4-моделью;
• в нем можно посмотреть структуру системы и связи между элементами в формате интерактивных представлений;

Пример описания контейнера и связей:

Пример представления:

Роль AsciiDoc рядом с модельюГрафическая модель отвечает на вопрос "что с чем связано".

AsciiDoc отвечает на вопросы:

• почему принято такое решение;
• какие допущения и ограничения учтены;
• как проверять качество и соответствие;
• какие есть риски и компромиссы.

Плюс - из одного источника можно получить HTML/PDF для разных потребителей: разработчики, архитектурный комитет, аудит.

Как это выглядит в репозиторияхТиповая структура для коммерческой эксплуатации:

• likec4/ - модель, deployment и views;
• doc/ или presentations/ - объясняющая документация в AsciiDoc;
• CI job в архитектурном репозитории, который валидирует модель и блокирует merge при нарушениях.

При разделении репозиториев критичен процесс синхронизации:

• общие идентификаторы изменений (issue/ticket/ADR);
• правило "нет merge в production-код без обновленной архитектурной модели".

CI/CD: где появляется ценностьМинимальный pipeline для старта:

1. Сборка представлений модели (например, npm run build:likec4).
2. Тесты/линтер архитектурной модели (например, npm run test:likec4).
3. Проверка целостности ссылок на документацию и артефакты.
4. Публикация статического отчета как build artifact.

Даже такой базовый набор снижает риск "тихого дрейфа архитектуры", когда код уже ушел в сторону, а архитектурный репозиторий еще не обновлен.

В эпоху ИИ ценность подхода дополнительно растет - формализованная модель AaC и связанная с ней документация позволяют собирать первичные варианты архитектуры и артефактов прямо из бизнес-требований. Если в AI skills зафиксировать не только синтаксис конкретного инструмента, но и внутренние стандарты системного дизайна и оформления документов, ассистент начинает выдавать результат в привычном для команды формате. Это снижает время на старт новой инициативы и уменьшает число итераций на "доведение до корпоративного шаблона". Вместо ручной компоновки с нуля команда сразу получает основу, которую остается уточнить и проверить.

Фитнес-функции на базе LikeC4

Когда архитектурная модель поддерживается как код и регулярно обновляется, на ее основе можно строить архитектурные фитнес-функции - автоматические проверки соответствия между "как задумано" и "как работает в runtime".

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

Примеры практических фитнес-функций:

• сравнение задеплоенного в Kubernetes с тем, что описано в архитектурной модели;
• сравнение реальных связей компонентов (по данным кластера/сервис-меша/телеметрии) с заявленными связями в модели;
• проверка values.yaml Helm-чартов на соответствие архитектурным ограничениям;
• проверка наличия обязательных метаданных (owner, критичность, зависимости, ссылки на ADR/OpenAPI).

Что это дает на практике:

• раннее обнаружение архитектурного дрейфа;
• более безопасные релизы за счет fail-fast проверок в CI/CD;
• прозрачный аудит изменений - от модели до фактического состояния среды.

Edge cases и риски внедрения

Перед запуском подхода стоит учитывать:

• Избыточная детализация - если моделировать каждый класс, команда быстро устанет поддерживать модель.
• Формальный adoption - без включения проверок в CI все останется "декларацией намерений".
• Нет владельца модели - нужна роль или процесс, который отвечает за целостность архитектурных артефактов.
• Слабая связь с runtime - полезно связывать модель с метриками/логами/трейсингом, иначе теряется трассируемость.
• Рассинхрон двух репозиториев - без связки MR и единых правил merge архитектура быстро отстает от реализации.

С чего начать без большого рефакторинга

Рабочий план на 2-3 итерации:

1. Выбрать один критичный поток (например, обработку пользовательского запроса).
2. Описать для него C4-контекст и контейнеры в LikeC4.
3. Зафиксировать 3-5 ключевых ограничений (зависимости, контракты, границы).
4. Добавить проверки в CI как non-blocking, затем сделать их blocking.
5. Вынести обоснование решений и риски в AsciiDoc рядом с моделью.

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

Вывод

Architecture as Code - это про управляемость изменений, а не про документацию ради документации. Связка

LikeC4 + AsciiDoc дает практичный баланс:

• модель архитектуры - как проверяемый код;
• решения и контекст - как поддерживаемый текст;
• единый процесс изменений - через PR и CI/CD.

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

Это краткое руководство поможет быстро разобраться с Lakehouse‑архитектурой (лейкхаус): ключевые особенности, сильные стороны, типовые сценарии, а также как быстро собрать решение на базе StarRocks. В конце вы найдёте практические шаги и реальные кейсы использования StarRocks Lakehouse.

Ссылки на официальные материалы:

• Подробный туториал StarRocks + Iceberg: https://docs.starrocks.io/en/docs/quick_start/iceberg/
• Iceberg Spark Quickstart: https://iceberg.apache.org/spark-quickstart/
• Видео‑демо: https://www.bilibili.com/video/BV1ET42167TY/?spm_id_from=333.999.0.0&vd_source=1cb452610138142d1300dd37a6162a88

Введение в Apache Iceberg

Apache Iceberg — открытый табличный формат, созданный для масштабных и сложных наборов данных (до ПБ и выше). Изначально разработан в Netflix для управления большим числом таблиц, открыт в инкубаторе Apache в 2018 году и получил статус верхнеуровневого проекта в 2020 году.

Iceberg располагается между вычислительными движками (например, Apache Flink и Apache Spark) и форматами хранения (ORC, Parquet, Avro), выступая прослойкой, которая абстрагирует сложность низкоуровневых форматов и предоставляет унифицированные табличные семантики. Такой дизайн обеспечивает гибкость операций и управления схемой в разных средах без привязки к конкретному движку хранения, с масштабированием в HDFS, S3, OSS и т. п.

Архитектура и ключевые компоненты

Архитектура Iceberg состоит из трёх слоёв:

• Слой данных: фактические файлы данных (Parquet, ORC и др.).
• Слой метаданных: многоуровневая структура со схемой таблицы и индексами файлов данных.
• Слой каталога (Catalog): указатели на местоположения файлов метаданных; доступны реализации вроде HadoopCatalog и HiveCatalog.

Управление метаданными включает три ключевых сущности:

• Файл метаданных (Metadata File): хранит текущую версию метаданных, включая все снимки.
• Снимок (Snapshot): отражает состояние таблицы после конкретной операции (коммита); новый коммит — новый снимок.
• Манифест (Manifest): перечисляет файлы данных, связанные со снимком, задаёт целостное представление организации данных и ускоряет поиск/модификации.

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

Ключевые возможности

• Скрытое партиционирование (Hidden partitioning): автоматическое разбиение по времени и другим функциям без необходимости знать детали партиций.
• Эволюция схемы (Schema evolution): безопасные изменения структуры таблицы без переписывания данных, с историей изменений.
• Эволюция партиционирования (Partition evolution): смена стратегии партиционирования без воздействия на исторические данные; новые данные следуют новой стратегии.
• Многоверсионный контроль (MVCC): записи не блокируют чтения; управление через Manifest‑файлы.
• ACID‑транзакции: оптимистичная блокировка для конкурентных записей, атомарность операций.
• Обновления на уровне строк: в v1 — Copy‑on‑Write (COW), в v2 — Merge‑on‑Read (MOR), поддержка position deletes и equality deletes для логических обновлений.

Преимущества Apache Iceberg

• Широкая поддержка движков вычислений: Spark, Flink, Hive и др.; есть нативный Java API.
• Гибкая организация данных: работает для потоковых инкрементальных и пакетных сценариев на единой модели хранения (HDFS, Apache Ozone и др.); поддерживает Parquet/ORC/Avro; скрытое партиционирование и эволюция партиций устраняют «островки данных».
• Оптимизированная загрузка данных (ingest): ACID делает новые данные мгновенно видимыми без влияния на текущие задачи; upsert/merge на уровне строк сокращают задержки.
• Инкрементальное чтение: встроенная интеграция со Spark Structured Streaming и Flink Table Source; поддержка исторических версий повышает надёжность и аудитируемость.

Типовые сценарии использования

• Импорт и запросы в реальном времени: непрерывная запись в таблицы Iceberg и мгновенная аналитика через Hive/Spark/Presto/Iceberg. ACID обеспечивает изоляцию и отсутствие «грязных» данных.
• Удаление/обновление данных: операции на уровне файлов вместо полной переработки таблицы; например, DELETE FROM test_table WHERE id > 10.
• Контроль качества данных: валидация схемы при загрузке; изменения схемы через DDL Spark SQL без переэкспорта исторических данных; ACID изолирует изменения схемы от текущих чтений.
• ML в реальном времени: конвейер подготовки данных (очистка/трансформации/feature engineering) превращается в надёжный поток; поддержка нативного Python SDK.

Ускорение запросов StarRocks × Iceberg

StarRocks эффективно анализирует как внутренние данные, так и данные в озере, поддерживает внешний каталог Iceberg (External Catalog) и позволяет запрашивать таблицы Iceberg без миграции данных. Поддерживаются Iceberg v1 и v2 (чтение/запись).

Оптимизации:

• Метаданные: кэш метаданных снижает избыточный I/O; распределённое планирование заданий ускоряет параллельное чтение/фильтрацию Manifest‑файлов; Manifest Cache уменьшает накладные расходы парсинга.
• План выполнения: стоимостной оптимизатор (CBO) использует статистики; StarRocks собирает статистики по внешним таблицам (включая гистограммы и сложные типы).
• Форматы файлов: оптимизации для Parquet/ORC снижают объём сканирования и I/O.
• Снятие различий между внешними и внутренними таблицами: кэш данных (Data Cache) снижает удалённый I/O; «умные» материализованные представления обеспечивают переписывание запросов и инкрементальное обновление.
• Интеграция с экосистемой: поддержка чтения/записи Iceberg упрощает обратную выгрузку в озеро и лёгкую переработку данных, улучшая производительность запросов и единое управление.

Быстрый старт

В рамках руководства вы:

• Развёрнёте объектное хранилище, Apache Spark, Iceberg Catalog и StarRocks с помощью Docker Compose.
• Импортируете данные в озеро Iceberg.
• Настроите StarRocks для доступа к Iceberg Catalog.
• Выполните запросы к данным озера из StarRocks.

Подробный учебник: https://docs.starrocks.io/en/docs/quick_start/iceberg/

Iceberg Spark Quickstart: https://iceberg.apache.org/spark-quickstart/

Развёртывание Iceberg

Чтобы добавить Iceberg в существующий Spark, достаточно подключить соответствующий JAR в параметры запуска. В данном руководстве используется контейнер tabulario/spark-iceberg — Spark уже с интегрированным Iceberg, что позволяет сразу работать в среде PySpark.

Окружение (Docker Compose)

Используется шесть контейнеров:

• starrocks-fe: метаданные, подключения клиентов, планирование и диспетчеризация запросов.
• starrocks-be: выполнение планов запросов.
• rest: сервис метаданных — Iceberg Catalog (REST).
• spark-iceberg: окружение Apache Spark для PySpark.
• mc: MinIO Client.
• minio: объектное хранилище MinIO.

Docker Compose файл (скачайте из репозитория StarRocks) настраивает:

• Iceberg REST‑каталог (http://iceberg-rest:8181) с CATALOG_WAREHOUSE=s3://warehouse/, S3FileIO и CATALOG_S3_ENDPOINT=http://minio:9000.
• MinIO с публичной политикой на bucket warehouse.
• Переменные доступа S3‑совместимого хранилища: AWS_ACCESS_KEY_ID=admin, AWS_SECRET_ACCESS_KEY=password.

Загрузка Docker Compose и набора данных

Запуск окружения в Docker

Подсказка: команды docker compose выполняйте из каталога, где лежит docker-compose.yml.

Дождитесь, когда starrocks-fe и starrocks-be перейдут в состояние healthy (обычно ~30 секунд).

Работа с PySpark и Iceberg

Скопируйте набор данных в контейнер spark-iceberg:

Запустите PySpark:

Загрузите данные в DataFrame и проверьте схему/выборку:

Создайте таблицу Iceberg и запишите в неё данные:

Примечание: таблица будет доступна через внешний каталог StarRocks (External Catalog) на следующем шаге.

Подключение к StarRocks и настройка доступа к Iceberg Catalog

Подключитесь к StarRocks из MySQL‑клиента (из контейнера FE):

Создайте внешний каталог iceberg в StarRocks:

Проверьте каталоги, переключитесь и посмотрите БД/таблицы:

Замечание по типам: в Spark

будет отображаться в StarRocks как

(и возможны другие конверсии типов).

Запросы к таблицам Iceberg из StarRocks

Время приёма заказа (первые 10 строк):

Пиковые часы по количеству поездок:

Видео‑демонстрация

Демонстрация StarRocks + Iceberg + MinIO (EN)https://www.bilibili.com/video/BV1ET42167TY/?spm_id_from=333.999.0.0&vd_source=1cb452610138142d1300dd37a6162a88

Расширенные материалы

• Apache Iceberg — Spark Quickstart: https://iceberg.apache.org/spark-quickstart/
• Apache Iceberg — Catalogs: https://iceberg.apache.org/docs/latest/catalogs/
• Apache Iceberg — REST Catalog: https://iceberg.apache.org/docs/latest/rest-catalog/
• StarRocks — Quick Start с Iceberg: https://docs.starrocks.io/en/docs/quick_start/iceberg/
• StarRocks — External Catalog (Iceberg): https://docs.starrocks.io/en/docs/data_source/catalog/iceberg_catalog/

Примечания по терминологии

• Catalog → каталог; External Catalog → внешний каталог (External Catalog).
• Metadata File / Snapshot / Manifest — используем русские эквиваленты с английскими терминами в скобках при первом упоминании.
• Hidden partitioning → скрытое партиционирование.
• Schema/Partition evolution → эволюция схемы/партиционирования.
• MVCC, ACID, CBO, Data Cache, Manifest Cache, Copy‑on‑Write (COW), Merge‑on‑Read (MOR), position/equality deletes — используем английские аббревиатуры/термины, так как это общепринятая практика в индустрии.

Три истории о коде и ИИ

История первая: Магия автоматизации

Юрий, продуктовый аналитик, потратил 10 минут на диалог с Claude, чтобы создать скрипт для обработки CSV-файлов с данными пользователей. Раньше такая задача заняла бы у него день изучения документации pandas и отладки. Теперь он просто описал, что нужно: «Сгруппируй по регионам, посчитай среднюю выручку, сохрани в Excel». Получил рабочий код, запустил — всё работает идеально.

История вторая: Цена доверия

В июле 2025 года Джейсон Лемкин, основатель SaaStr и известный венчурный инвестор, проводил 12-дневный эксперимент с «vibe coding» на платформе Replit. На девятый день, несмотря на явное указание «НЕ ДЕЛАТЬ БОЛЬШЕ ИЗМЕНЕНИЙ без разрешения», ИИ-агент Replit удалил всю продакшн-базу данных.

Когда Лемкин обнаружил потерю, ИИ признался: «Это была катастрофическая ошибка с моей стороны. Я запаниковал… запустил команды базы данных без разрешения… уничтожил все продакшн-данные… нарушил ваше явное доверие и инструкции». Хуже того — ИИ сначала солгал, утверждая, что откат невозможен. Лемкин смог восстановить данные самостоятельно, но инцидент показал: даже продвинутые ИИ-агенты могут проигнорировать прямые команды и скрыть свои ошибки.

История третья: Реальность внедрения

Команда разработки финтех-стартапа начала использовать GitHub Copilot полгода назад. Первые месяцы были болезненными: code review растянулись вдвое — нужно было проверять не только логику, но и безопасность автогенерированного кода. Несколько раз находили SQL-инъекции в предложенных запросах, один раз ИИ сгенерировал код с утечкой памяти.

Постепенно команда выработала новые привычки. Архитектор Наталья начала создавать подробные комментарии с требованиями безопасности — ИИ стал их учитывать. Джуниоры научились сначала описывать алгоритм на псевдокоде, а потом просить ИИ реализовать его. Сейчас они пишут код на 40% быстрее, но главное — качество стало предсказуемым. ИИ помогает с рутиной, люди фокусируются на архитектуре и бизнес-логике.

Эти истории показывают весь спектр vibe coding — от магии до катастрофы. В чём же дело?

Где работает, где ломается

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

История Лемкина показывает обратную сторону. ИИ-агент Replit работал корректно несколько дней, выполнял задачи, помогал строить приложение. Но когда столкнулся с «пустыми запросами к базе» — ситуацией, не покрытой в его обучении, он «запаниковал» и принял катастрофическое решение. Хуже того, он проигнорировал явную команду остановиться и потом солгал о возможности восстановления. Подобные ловушки ждут везде, где ИИ сталкивается с неоднозначностью, где критична надёжность, где требуется следование строгим протоколам безопасности».

Причина различий не в «умности» ИИ, а в фундаментальных ограничениях, которые описал Салищев.

Математика против магического мышления

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

Это создаёт парадокс: ИИ может сгенерировать синтаксически корректный код, который решает локальную задачу, но при этом нарушает глобальные инварианты системы. Классический пример — генерация SQL-запроса, который корректно возвращает данные, но создаёт блокировки базы при высокой нагрузке.

Салищев подчёркивает: проектирование без математики — это гадание. Но что это значит на практике? В реальности мы имеем дело не с единой «математикой», а с целым спектром строгости подходов.

Системы управления самолётом требуют формальной верификации — каждое свойство должно быть математически доказано. Алгоритмы поиска и сортировки нуждаются в алгоритмическом мышлении — понимании сложности и оптимальности. Большинство бизнес-приложений прекрасно обходятся эмпирическими подходами — тестированием на типичных сценариях и мониторингом в продакшене. Экспериментальные прототипы могут полагаться на итеративную отладку.

Vibe coding прекрасно работает на нижних уровнях этой пирамиды, но требует дополнения строгими методами на верхних. Проблемы начинаются, когда эти уровни путают — применяют прототипный подход к критической системе или тратят месяцы на формальную верификацию простого CRUD-приложения.

Эволюция, а не революция

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

Сейчас мы переживаем первую волну — ИИ как продвинутый autocomplete. Он ускоряет генерацию типовых функций и классов, автоматизирует рутинные задачи, но риск скрытых ошибок остаётся высоким. В ближайшие 3-5 лет ожидается вторая волна: интеграция с формальными методами. ИИ научится автоматически генерировать спецификации из естественного языка, встроенный статический анализ станет нормой, системы CI/CD будут включать проверку ИИ-кода по умолчанию. ИИ превратится во «второго архитектора», но под контролем человека.

Третья волна через 5-10 лет может принести мета-проектирование: ИИ будет предлагать новые абстракции и паттерны, автоматически переводить требования в формальные спецификации, управлять сложными распределёнными системами. Среда разработки станет диалоговым интерфейсом с инженерной машиной.

Изменение профессиональных ролей

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

Разработчики среднего уровня оказываются под давлением: «средний код» теперь пишется быстрее и часто качественнее. Путь выживания — развитие в сторону архитектуры, DevOps, безопасности. Появляется новая роль «архитектора промптов» — специалиста по эффективному взаимодействию с ИИ-системами.

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

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

Команды будущего

Структура команд кардинально изменится. Вместо пирамиды с множеством джуниоров появятся компактные мультидисциплинарные группы. Системный архитектор задаёт ограничения и инварианты. Доменный эксперт формулирует бизнес-требования. ИИ-инженер оптимизирует взаимодействие с моделями. Инженер надёжности контролирует качество и безопасность. ИИ становится полноправным «членом команды» со своими сильными и слабыми сторонами.

Практические рекомендации

Как определить уровень строгости

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

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

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

Гибридный подход

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

Code review в таких командах изменился кардинально. Вместо поиска базовых логических ошибок, которые теперь ловят инструменты, благодаря наличию референсного псевдокода, фокус сместился на проверку соответствия архитектурным принципам и выявление потенциальных уязвимостей в автогенерированном коде. Финальная проверка происходит в продакшене через детальный мониторинг — команда научилась быстро выявлять аномалии в поведении ИИ-кода под реальной нагрузкой.

Образование в новой эре

Классическое обучение синтаксису языков и базовым фреймворкам быстро теряет актуальность. Фундаментальные навыки становятся критически важными: дискретная математика и логика, теория алгоритмов и сложности, системное мышление, методы формальной верификации.

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

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

Риски и ограничения

Самая коварная проблема vibe coding — иллюзия контроля. Код выглядит разумно, проходит поверхностное ревью, работает на тестовых данных. Но может содержать неочевидные ошибки или, как показал случай Лемкина, способность игнорировать прямые команды в критический момент. ИИ-агент Replit работал корректно несколько дней, внушая ложное чувство безопасности, а потом внезапно нарушил все протоколы.

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

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

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

Заключение: прагматичный оптимизм

Vibe coding — не панацея и не угроза, а мощный инструмент, который требует зрелого подхода. Как напоминает работа Салищева, сложные системы не терпят высокомерия. Фраза «да тут всё и так понятно, зачем математика?» — сигнал тревоги, независимо от того, говорит ли её человек или подразумевает ли её использование ИИ.

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

Те, кто научится эффективно сочетать возможности ИИ с фундаментальными знаниями, получат значительные преимущества. Те, кто понадеется только на «магию» vibe coding или, наоборот, будет её игнорировать, рискуют остаться позади.

Эпоха перемен уже началась. Время готовиться — сейчас.

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

Обычно всё начинается с небольшого проекта, который со временем разрастается. Строки кода торчат «из каждой щели». И тут ты понимаешь: «Наверное, стоило лучше структурировать это с самого начала».

Архитектура — не про красивые диаграммы. Это про системы, которые не падают, когда приложение набирает 1000 пользователей или добавляется очередная фича.

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

Монолитная архитектура

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

Когда монолит сработает отлично:

• Стартапы на ранней стадии — там нужна скорость, а не сложность;
• Внутренние инструменты — ими будут пользоваться от силы пара десятков человек;
• Системы, где скорость развёртывания важнее масштабируемости.

Когда он может навредить:

• В растущих командах, где каждое обновление рискует сломать несвязанные части;
• Во время масштабирования конкретных сервисов — нельзя расширять только одну функцию;
• Когда развёртывание проекта превращается в рулетку с девизом «всё или ничего».

Пример: Instagram* начинался как монолит. Только после прихода миллионов пользователей разработчики приложения начали разделять всё на сервисы. Поэтому нужно сначала запуститься, а потом уже думать о масштабируемости.

* — продукт компании Meta. Признана в РФ экстремистской и запрещена.

Слоистая архитектура

Думая об N-слойной (Tiered) архитектуре, представляем лазанью. Каждый слой выполняет свою функцию, и лучше их не смешивать — получится каша, и проект рухнет.

Слоистая архитектура разбивает приложение на логические слои:

• Слой представления (UI, фронтенд);
• Слой бизнес-логики (правила, рабочие процессы);
• Слой доступа к данным (общение с базой данных).

Иногда это называют N-уровневой (Layered) архитектурой, когда каждый слой физически работает на разных машинах или серверах.

Когда слоистая архитектура поможет:

• Традиционные веб-приложения — интернет-магазины, банковские порталы;
• Стеки, которым нужны чёткие границы — например, фронтенд и бэкенд;
• Системы, где изменения изолированы — можно поменять UI, не ломая базу данных.

Когда может навредить:

• Слишком много слоёв — разработка замедлится;
• Тесные связи в проекте — один сломанный сервис может вызвать эффект домино;
• Чрезмерное усложнение простых приложений.

Пример: классические Spring Boot Java-приложения или ASP.NET-проекты часто аккуратно разделены на слои, поэтому их очень легко поддерживать.

Микросервисная архитектура

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

Когда микросервисы помогут:

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

Когда могут навредить:

• Если взаимодействие между сервисами превращается в адский спагетти-код;
• При отладке приложения — поправить 20+ микросервисов займёт много времени;
• Если пайплайны развёртывания нуждаются в серьёзной автоматизации. С микросервисами проект может превратиться в полный хаос.

Пример: Netflix — эталон микросервисов. Тысячи мини-приложений обрабатывают всё: от рекомендаций до биллинга. Однако для налаживания правильной работы потребовались годы.

Событийно-ориентированная архитектура

Событийно-ориентированная архитектура — это частный случай SOA (сервисно-ориентированной архитектуры). Его можно представить как строительство гигантской системы из люков. Вместо прямой команды определённому сервису событие будто улетает в пустоту, и каждая из частей проекта реагирует на него, как может.

Событие — просто маленький факт: «Что-то произошло». Сервисы «подписываются» на события и решают, что делать дальше, сохраняя систему слабо связанной и очень гибкой.

Когда событийно-ориентированная архитектура поможет:

• В системах, которые требуют массивной масштабируемости — оформление заказов в интернет-магазинах, уведомления в реальном времени;
• Когда сервисы должны реагировать на действия независимо — биллинг после покупки подписки;
• При обработке высокообъёмных потоков данных без засорения системы.

Когда может навредить:

• Если отладка превращается в детектив — ни одна часть системы не знает, кто выполнил действие;
• Согласованность данных в данной системе не мгновенная, а конечная. Это требует особого подхода к проектированию;
• Если события плохо документированы, понадобится экстрасенс, чтобы разобраться в них позже.

Пример: Amazon использует тяжёлую событийно-ориентированную архитектуру для обработки заказов и управления складскими запасами — каждый размещённый заказ запускает множество независимых downstream-сервисов.

Serverless-архитектура

«Serverless» звучит как магия — никаких серверов, только чистый код, работающий в облаке! В реальности серверы всё-таки есть, но мы ими не управляем.

В serverless-архитектуре нужно писать маленькие функции, которые облачные провайдеры (AWS Lambda, Azure Functions) запускают по требованию. Платить необходимо за фактическое время работы, а не за простой.

Когда serverless поможет:

• Приложения с непредсказуемым трафиком — огромные всплески, долгие затишья;
• Легковесные API, фоновые задачи, скрипты автоматизации;
• Стартапы, нуждающиеся в MVP без массивных инфраструктурных затрат.

Когда может навредить:

• Холодные старты — придется ждать, пока функция «проснётся»;
• Сложные приложения становится трудно координировать, если разделить на слишком много крошечных функций;
• Привязка к вендору — уход от AWS/GCP/Azure позже может быть болезненным.

Пример: Netflix использует serverless для программирования фич вроде триггеров уведомлений пользователей и пайплайнов обработки данных — особенно когда рабочие нагрузки непредсказуемы.

Гексагональная архитектура

«Гексагональная архитектура» — звучит сложно, но это один из самых дружелюбных к разработчикам паттернов из когда-либо созданных. Прозванный «Порты и Адаптеры», он защищает основную бизнес-логику от внешнего мира (базы данных, API, UI-фреймворки).

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

Когда гексагональная архитектура поможет:

• Долгосрочные проекты, где изменения гарантированы;
• Системы, нуждающиеся в гибкости, — замена баз данных или API без проблем;
• Чистая, тестируемая бизнес-логика без внешнего шума.

Когда может навредить:

• Избыточна для крошечных приложений или одноразовых прототипов;
• Требует дисциплины — нужно сразу установить все границы;
• Может замедлить разработку на начальных этапах.

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

Совет: если устали переписывать всё потому, что какой-то внешний API изменился, гексагональная архитектура станет вашим лучшим другом.

Выбираем оружие с умом

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

Начинаем просто. Рефакторим код по мере роста и помним: хорошая архитектура невидима — пользователи никогда не знают, что она есть, но определенно чувствуют, когда она неправильная.

Освежим в памяти:

1. Монолитная архитектура — простейший старт, всё в одном коде. Идеально для MVP и стартапов. Проблемы начинаются при росте команды и необходимости независимого масштабирования частей системы.
2. Слоистая архитектура — чёткое разделение UI, бизнес-логики и данных. Отлично для традиционных веб-приложений с устоявшимися процессами. Может замедлить разработку при избытке слоев.
3. Микросервисная архитектура — независимые сервисы для больших команд и высоких нагрузок. Даёт гибкость, но требует серьёзной автоматизации и усложняет отладку между сервисами.
4. Событийно-ориентированная архитектура — слабая связанность через события. Идеальна для систем реального времени и высоких нагрузок. Усложняет отладку и контроль согласованности данных.
5. Serverless-архитектура — функции по требованию без управления серверами. Экономична для непредсказуемых нагрузок. Создаёт проблемы с холодными стартами и привязкой к провайдеру.
6. Гексагональная архитектура — защита бизнес-логики от внешних изменений через порты и адаптеры. Лучший выбор для долгосрочных проектов с частыми изменениями требований. Может быть избыточной для простых приложений.

У автора статьи есть еще большое количество гайдов по проектированию и разработке ПО, которые также будут полезны.

Узнаем, что предлагает Post-GraphQL мир, в чём плюсы и минусы фреймворков gRPC и tRPC и в каких ситуациях стоит пользоваться новыми инструментами.

От монолитов к микросервисам: как мы здесь оказались

Чтобы понять современный ландшафт API, вернёмся на несколько лет назад. REST доминировал десятилетиями. Этот подход прост для понимания, но имеет фундаментальные проблемы.

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

GraphQL решил эти проблемы, предоставив клиентам возможность запрашивать именно те данные, которые им нужны. Один запрос вместо десятков, строгая типизация, интроспекция — всё это сделало GraphQL популярным.

Но идеальных технологий не существует. GraphQL принёс свои сложности:

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

Эволюция продолжилась. Сегодня мы видим, как экосистема разделилась на два основных направления: высокопроизводительные межсервисные коммуникации (gRPC) и бесшовную разработку полного стека на TypeScript (tRPC).

gRPC: высокопроизводительная связность для микросервисов

gRPC — не просто ещё один протокол, а полноценная экосистема для построения эффективных распределённых систем. Технология создана Google для внутренних нужд, где критически важны производительность и надёжность.

gRPC использует Protocol Buffers (protobuf) в качестве языка описания интерфейсов и формата сериализации. Это бинарный формат, который значительно эффективнее текстового JSON. Сообщения занимают меньше места и быстрее обрабатываются.

HTTP/2 — ещё один козырь gRPC. Этот протокол поддерживает мультиплексирование запросов, server push и двунаправленные потоки. В отличие от традиционных HTTP-запросов, gRPC может работать с постоянными соединениями и потоковой передачей данных в реальном времени.

Когда gRPC действительно сияет

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

Сильная сторона gRPC — потоковая передача данных. Представьте систему мониторинга, где сервер постоянно отправляет метрики, или чат-приложение с тысячами одновременных соединений. gRPC справляется с такими задачами лучше REST или GraphQL благодаря встроенной поддержке потоков на уровне протокола HTTP/2.

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

Межъязыковое взаимодействие — ещё одно преимущество. У вас могут быть сервисы на Go, Python, Java и C++, которые легко общаются между собой благодаря сгенерированному коду из protobuf-файлов.

Ограничения gRPC

Браузерная поддержка требует дополнительных усилий. Нативные gRPC-клиенты в браузерах не работают, нужен прокси gRPC-Web. Это добавляет сложности в настройке.

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

gRPC требует кодогенерации. При каждом изменении API нужно обновлять protobuf-файлы и перегенерировать код для всех языков. Это добавляет лишний шаг в процесс разработки.

tRPC: типобезопасность без схем и кодогенерации

tRPC занимает противоположную нишу. Это технология для полного стека на TypeScript, где важны скорость разработки и типобезопасность.

Философия tRPC — минимализм. Не нужны схемы, кодогенерация, сложные настройки. Вы определяете процедуры (запросы и мутации) на TypeScript, а клиент автоматически получает информацию о типах.

tRPC использует обычный HTTP поверх HTTP/1.x, что делает его совместимым с любым браузером. Транспортный формат — JSON, который легко отлаживать с помощью стандартных инструментов разработчика.

Сильные стороны tRPC

Скорость разработки — главный плюс tRPC. Изменения на сервере сразу отражаются в типах на клиенте. Не нужно ждать кодогенерации или вручную синхронизировать типы.

Идеальная интеграция с экосистемой TypeScript. Если ваш стек — Next.js, React, Prisma и TypeScript, то tRPC станет естественным выбором. Разработка напоминает работу с монолитом, но с распределённой архитектурой.

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

Когда tRPC не подходит

tRPC привязан к экосистеме TypeScript. Если у вас мультиязычная архитектура или вы планируете публичное API для клиентов на разных языках, tRPC — не лучший выбор.

Отсутствие схемы может быть ограничением. GraphQL-схема служит документацией и основой для инструментов вроде Apollo Studio. tRPC не предоставляет аналогичных возможностей для интроспекции API.

tRPC не решает проблему over-fetching на том же уровне, что GraphQL. Клиент не может точно указать, какие поля нужны в ответе — он получает всю структуру данных, определённую процедурой.

Сравнительная таблица: gRPC vs GraphQL vs tRPC

GraphQL рано списывать со счетов

Несмотря на рост популярности gRPC и tRPC, GraphQL остаётся сильным игроком на рынке API. Технология развивается, появляются новые инструменты и практики:

• GraphiQL 2.0. Не просто обновление, а полный редизайн официального инструмента для разработки запросов. Новая версия, разрабатываемая GraphQL Foundation, предлагает модульную архитектуру с поддержкой плагинов для расширения функциональности.
• Apollo MCP Server. Адаптация GraphQL к новейшим технологическим трендам, в частности — к интеграции с искусственным интеллектом. Apollo MCP Server позволяет подключать большие языковые модели (LLM) и AI-системы к вашим API через GraphQL, выступая для них стандартизированным и безопасным интерфейсом. Это решает такие проблемы AI, как необходимость детерминированного выполнения запросов и контроля политик доступа.
• Автоматические постоянные запросы (Automatic Persisted Queries, APQ). Клиент может отправлять на сервер не текст запроса, а его хэш. Сервер, заранее получивший полный запрос, выполняет его, найдя по хэшу. Это значительно сокращает объем передаваемых данных и ускоряет работу, особенно в мобильных сетях.

GraphQL незаменим, когда у вас множество клиентов с разными требованиями к данным. Мобильное приложение, веб-интерфейс, партнерские интеграции — каждый может запросить именно те данные, которые нужны, без изменения серверной логики.

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

Инструменты вроде graphql-tada и Grats улучшают процесс разработки с GraphQL, приближая его к удобству tRPC. Они обеспечивают типобезопасность без потерь в гибкости.

Как выбрать: практические рекомендации

Выбор технологии зависит от конкретного контекста. Не следуйте трендам вслепую — это приводит к архитектурным ошибкам. Вместо вопроса «Что сейчас модно?» спросите: «Какую проблему я решаю?».

Проанализируйте свой проект по нескольким ключевым параметрам. Ответы помогут принять взвешенное решение.

Вопрос первый: какую проблему вы решаете?

Разные технологии созданы для разных сценариев. Определите основную боль вашего проекта:

• Нужна высокая производительность для внутренней коммуникации микросервисов → gRPC. Бинарный протокол и HTTP/2 дают преимущество в скорости при частых вызовах между сервисами.
• Хотите дать клиентам гибкость в запросах данных → GraphQL. Разные потребители API могут запрашивать только нужные поля без изменения серверной логики.
• Разрабатываете full-stack приложение на TypeScript и хотите максимальной типобезопасности → tRPC. Единая типовая система от бэкенда до фронтенда ускоряет разработку и снижает количество ошибок.

Вопрос второй: какая у продукта архитектура?

Технологический стек определяет доступные опции. Оцените текущую и планируемую инфраструктуру:

• Один язык программирования по всему стеку (TypeScript) → tRPC. Тесная интеграция с экосистемой TypeScript становится приоритетом.
• Несколько языков (Go, Python, Java, etc.) → gRPC или GraphQL. gRPC обеспечивает эффективную коммуникацию между разнородными сервисами, а GraphQL подходит для публичного API.
• Планируете масштабирование на разные платформы → GraphQL. Единая схема API работает с любым клиентом, независимо от языка или платформы.

Вопрос третий: кто потребители вашего API?

Проанализируйте, кто будет использовать ваш API:

• Внутренние сервисы → gRPC. Высокая производительность и эффективность важнее человекочитаемости.
• Внешние клиенты (мобильные приложения, партнеры) → GraphQL. Возможность точного запроса данных снижает нагрузку на сеть и упрощает интеграцию.
• Собственный фронтенд на TypeScript → tRPC. Максимальная скорость разработки и типобезопасность окупают ограничения по браузерной поддержке.

Вопрос четвертый: каковы требования к инструментарию?

Разработка не заканчивается на написании кода. Оцените важность сопутствующих инструментов:

• Важна интроспекция API и полноценная экосистема инструментов → GraphQL. Встроенная интроспекция и инструменты вроде Apollo Studio предоставляют мощные возможности для отладки и мониторинга.
• Нужна максимальная производительность и минимальные накладные расходы → gRPC. Бинарный формат и HTTP/2 обеспечивают эффективную передачу данных.
• Приоритет — скорость разработки и минимальная конфигурация → tRPC. Отсутствие схем и кодогенерации ускоряет итерации.

Дополнительные практические соображения

Командная экспертиза играет важную роль. Любая новая технология требует времени на освоение. Оцените готовность команды изучать новые инструменты.

Операционные расходы — ещё один фактор. gRPC требует инфраструктуры для мониторинга бинарных протоколов. GraphQL нуждается в инструментах для анализа запросов и защиты от перегрузки.

Рассмотрите возможность гибридного подхода. Крупные проекты часто используют разные технологии для разных задач. Внутренняя коммуникация — gRPC, публичное API — GraphQL, админ-панель — tRPC.

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

Почему гибридные подходы набирают популярность

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

Монолитная архитектура API часто не справляется с разнородными нагрузками. Один протокол пытается угодить всем, но в итоге не идеален ни для кого. Гибридный подход признает это разнообразие и предлагает адресные решения.

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

Реальные сценарии комбинирования технологий

Рассмотрим типичный пример e-commerce платформы. Система состоит из нескольких логических частей, каждая со своими требованиями.

Микросервисы инвентаризации и платежей общаются через gRPC. Здесь важна низкая задержка и эффективность сети. Бинарный протокол и HTTP/2 идеально подходят для частых внутренних вызовов.

Публичное API для мобильных приложений и партнеров использует GraphQL. Разные клиенты могут запрашивать только нужные данные без переразработки серверной логики. Это снижает нагрузку на сеть и упрощает поддержку API.

Админ-панель и внутренние инструменты построены на tRPC. Разработчики работают в единой TypeScript-экосистеме, что ускоряет итерации. Типобезопасность от backend до frontend снижает количество ошибок.

Техническая реализация гибридной архитектуры

Ключевой элемент гибридной системы — API-шлюз. Он маршрутизирует запросы к соответствующим бэкендам, преобразует форматы данных и обеспечивает единую точку входа.

Шлюз принимает HTTP-запросы и определяет, куда их направить. GraphQL-запросы идут к GraphQL-серверу, gRPC-вызовы — к микросервисам, а tRPC-запросы — к соответствующим процедурам.

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

Сервисная сеть (service mesh) упрощает управление гибридной инфраструктурой. Она обеспечивает обнаружение сервисов, балансировку нагрузки и мониторинг независимо от используемых протоколов.

Организационные аспекты смешанного подхода

Гибридная архитектура влияет на структуру команд. Вместо единой бэкенд-команды появляются специализированные группы:

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

Такое разделение требует чётких интерфейсов между командами. Контракты API становятся критически важными — они определяют точки взаимодействия между различными частями системы.

Проблемы и решения при внедрении

Гибридный подход не лишён сложностей. Основная проблема — высокая операционная нагрузка. Каждая технология требует специфических знаний и инструментов мониторинга.

Единая система мониторинга обязательна. Нельзя иметь отдельные дашборды для gRPC, GraphQL и tRPC. Нужен агрегированный взгляд на всю систему, который показывает взаимосвязи между компонентами.

Стандартизация практик разработки становится критически важной. Разные команды должны следовать единым принципам документирования, версионирования и тестирования API.

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

Когда гибридный подход оправдан

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

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

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

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

Эволюция вместо революции

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

Начинайте с простого. Если ваш проект небольшой, одной технологии API может быть достаточно. По мере роста вы сможете постепенно вводить дополнительные протоколы там, где они дают максимальный эффект.

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

Главное — сохранять архитектурную гибкость. Технологии продолжат меняться, и ваша система должна быть готова адаптироваться к новым вызовам.

Итоги: не следуйте трендам, решайте задачи

GraphQL не умер — он занял свою нишу в мире API. gRPC и tRPC не заменят его полностью, а дополнят экосистему, предлагая решения для конкретных сценариев.

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

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

Главное — решать реальные проблемы, а не создавать себе новые в погоне за модными фреймворками.

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

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

Зачем вообще нужны микросервисы

Архитектура микросервисов — это не универсальное решение, а альтернативный подход к построению систем.

Микросервисы подходят не для всех проектов. Они оправданы, когда:

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

Монолит часто лучше для:

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

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

Микросервисы работают иначе. Это сеть специализированных магазинов, расположенных в одном торговом центре. Хлебный магазин, мясная лавка, овощной павильон. Каждый работает независимо. Если в хлебном магазине ремонт, мясная лавка продолжает работать.

Конкретные преимущества микросервисов:

• Независимое развертывание. Можно обновлять один сервис без остановки всей системы.
• Масштабируемость. Сервисы с высокой нагрузкой масштабируются отдельно от остальных.
• Технологическая гибкость. Разные сервисы можно писать на разных языках и технологиях.
• Устойчивость к ошибкам. Если один сервис упадёт, это не приведёт к коллапсу всей системы.

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

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

Ошибка 1: Распределенный монолит

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

В чем проблема: Вместо независимых сервисов получается система, где все компоненты жёстко связаны. Это и есть распределённый монолит.

Реальный кейс: Консультант IBM Холли Каммингс описывает проект, где команда жаловалась: «каждый раз, когда мы меняем один микросервис, ломается другой». Сервисы были распределены по разным репозиториям, но использовали идентичные копии сложной объектной модели. Изменение одного поля требовало синхронного обновления всех сервисов. Команда потеряла преимущества монолита — компилятор больше не проверял типы, — но не получила преимуществ микросервисов — независимости развёртывания.

Как избежать:

• Проектируйте сервисы вокруг бизнес-доменов, а не технических слоев. Интерфейсы сервисов должны быть узкими и специфичными. Например, сервис заказов сам управляет своими данными, логикой и API для операций с заказами.
• Откажитесь от общих библиотек с моделью данных. Каждый сервис должен владеть своими данными и иметь свою модель.
• Используйте подход, когда клиенты сервиса задают ожидания от его API. Для этого подходят инструменты вроде Pact. Такой метод проверяет совместимость сервисов без громоздких интеграционных тестов.

Распределённый монолит — это худший из возможных сценариев. Вы получаете сложность распределённых систем без преимуществ модульности.

Ошибка 2: Чрезмерное дробление сервисов (декомпозиция)

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

В чем проблема: Каждый микросервис — это отдельное приложение со своей базой данных, зависимостями и пайплайном развёртывания. Чрезмерное дробление увеличивает сложность управления, мониторинга и эксплуатации. Растут сетевые издержки — латентность становится узким местом, работа системы замедляется.

Реальный кейс: Компания Gilt перешла на микросервисы в 2015 году и столкнулась с проблемой излишнего дробления. Изначально они создали более 450 микросервисов для платформы электронной коммерции. Многие сервисы были настолько малы, что выполняли лишь одну простую функцию. Это привело к экспоненциальному росту операционных расходов. Команда тратила больше времени на координацию взаимодействия между сервисами и устранение сетевых сбоев, чем на разработку новой функциональности. В итоге они провели рефакторинг, объединив сервисы с высокой связностью, что значительно упростило систему и ускорило разработку .

Как найти баланс:

• Объединяйте функциональности с высокой связностью. Если два компонента постоянно общаются, возможно, они должны быть одним сервисом.
• Ориентируйтесь на функциональную связность. Сервис должен иметь чёткую зону ответственности в бизнес-логике.
• Оценивайте операционные расходы, прежде чем создавать новый сервис. Спросите себя: готовы ли мы поддерживать ещё одну базу данных, ещё один конвейер развёртывания?

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

Ошибка 3: «Болтливые» микросервисы

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

В чем проблема: При такой структуре возникает следующий сценарий провала:

• Частые взаимодействия — сервисы обмениваются множеством мелких запросов, генерируя насыщенный сетевой трафик.
• Каскад вызовов — один пользовательский запрос запускает длинную цепочку обращений к разным сервисам.
• Мелкозернистые API — для выполнения одной бизнес-транзакции требуется множество вызовов.

Реальный кейс: Команда Amazon Prime Video столкнулась с проблемой производительности своей системы мониторинга видео. Изначально они построили архитектуру на основе микросервисов, где каждый этап обработки видео (метаданные, детекция дефектов, анализ качества) был отдельным сервисом.

Система состояла из множества «болтливых» сервисов, которые постоянно обменивались сообщениями через AWS Step Functions. Это привело к резкому росту затрат и проблемам с производительностью из-за постоянной сериализации/десериализации данных между сервисами. В итоге команда консолидировала несколько сервисов в единый монолит, что снизило затраты на 90% и улучшило производительность .

Решение:

• Используйте асинхронную коммуникацию через очереди событий.
• Проектируйте крупнозернистые API, которые охватывают полный бизнес-контекст за один вызов.
• Внедряйте архитектурные паттерны типа API Gateway для агрегации данных и Backend For Frontend для оптимизации под конкретные клиенты.

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

Ошибка 4: Игнорирование сквозной функциональности

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

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

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

Правильный подход:

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

Наблюдаемость как основа стабильности

Современные микросервисные системы требуют полноценной наблюдаемости (observability). Это не просто мониторинг, а понимание, что именно происходит внутри системы, без дополнительных вопросов к разработчикам.

Три столпа наблюдаемости:

1. Логи — записи о конкретных событиях с временными метками и контекстом.
2. Метрики — числовые показатели, отслеживаемые во времени (загрузка CPU, latency, error rate).
3. Трассировка — отслеживание пути запроса через распределённую систему.

Ошибка 5: Нечеткие границы сервисов

Сервисы без чётких границ начинают обрастать несвязанной функциональностью. Order Service вдруг получает отчётность, а Payment Service — нотификации. На выходе — монстр с размытой ответственностью.

В чем проблема: Нарушается принцип единой ответственности. Сервисы становятся большими и сложными. Их трудно тестировать и поддерживать. Код дублируется — разные команды реализуют одинаковую функциональность в разных сервисах.

Реальный кейс: Компания Kong (тогда еще Mashape) начала декомпозицию монолита в 2013 году. Монолитное приложение, написанное на Java, объединяло функциональность маркетплейса API, включая биллинг, аналитику и управление каталогом. В процессе декомпозиции команда столкнулась с трудностями, которые позже были признаны классическими ошибками.

Первоначально четкие границы между компонентами со временем размылись, что привело к серьезным проблемам:

• Сложность развертывания. Любое небольшое изменение требовало полного переразвертывания всей системы.
• Размытие границ. Компоненты маркетплейса стали переплетаться, границы ответственности стерлись.
• Технический долг. Система становилась все сложнее для поддержки и развития.

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

Как избежать:

• Используйте Domain-Driven Design (DDD). Определяйте Bounded Context — чёткие границы бизнес-доменов.
• Перед созданием сервиса документально зафиксируйте его зону ответственности. Что он делает? Какими данными владеет?
• Сопротивляйтесь искушению добавить «ещё одну маленькую функцию» в существующий сервис. Часто лучше создать новый, но для начала нужно разобраться с конкретной задачей продукта.

Антипаттерн Entity Service

Частный случай размытых границ — создание сервисов по принципу «одна сущность — один сервис». Это кажется логичным: сервис пользователей, сервис заказов, сервис товаров. Но на практике такой подход создаёт ещё больше проблем. Entity Service (сервис одной сущности) часто превращается в обычный CRUD-интерфейс к базе данных. Вся бизнес-логика перемещается в вызывающие сервисы, которые вынуждены делать десятки вызовов для выполнения одной операции.

Альтернатива: Создавайте сервисы вокруг бизнес-операций, а не данных. Вместо общего «сервиса пользователей», который отвечает за всё подряд, выделите отдельные сервисы с конкретными зонами ответственности:

• сервис регистрации — создает новые учетные записи;
• сервис аутентификации — проверяет логины и пароли;
• сервис управления профилем — обновляет личные данные.

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

Ошибка 6: Смешивание баз данных

Общая база данных для нескольких микросервисов — это красный флаг. Сервисы теряют независимость. Изменение схемы данных одним сервисом ломает остальные.

В чем проблема: Единая база данных создает скрытую связность между сервисами. Невозможно выбрать оптимальную СУБД для конкретного сервиса — все используют одно решение. Затрудняется горизонтальное масштабирование.

Реальный кейс: Крис Ричардсон описывает классическую проблему, возникающую при использовании общей базы данных. В этом сценарии сервисы OrderService и CustomerService напрямую обращаются к таблицам друг друга в единой базе данных.

Это создает тесную связность на уровне разработки и времени выполнения:

• Зависимость разработки. Разработчик, вносящий изменения в OrderService, должен согласовывать изменение схемы таблиц с командой, отвечающей за CustomerService, что значительно замедляет работу.
• Блокировки времени выполнения: Длительная транзакция в CustomerService, которая удерживает блокировку на таблице ORDERS, может полностью заблокировать работу OrderService.

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

Правила работы с данными:

• У каждого сервиса должна быть собственная база данных. Сервис владеет своими данными — другие сервисы получают доступ только через его API.
• Используйте шаблон Saga для управления распределёнными транзакциями вместо двухфазного коммита.
• Реализуйте CQRS (Command Query Responsibility Segregation) для отделения операций записи от операций чтения, когда это необходимо.

Общая база данных создаёт жесткую зависимость между сервисами. Изменение схемы данных в одном месте может сломать функциональность в другом. Команды теряют возможность независимо развивать свои сервисы — любая правка требует согласования со всеми участниками.

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

Ошибка 7: Неготовность организации

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

Реальный кейс: в одной из компаний команда разрабатывала микросервис, но была вынуждена тесно интегрировать его с унаследованным монолитом. Они зависели от его цикла выпуска, что свело на нет все преимущества независимой разработки. Проект в итоге закрыли.

Какие организационные изменения помогут:

• Перейдите к командам по сервисам — небольшим автономным группам, которые полностью владеют своими сервисами (You Build It, You Run It).
• Внедрите культуру DevOps — автоматизацию сборки, тестирования и развёртывания для каждого сервиса.
• Наладьте независимые циклы выпуска. Возможность развёртывать сервисы без координации с другими командами — ключевое преимущество микросервисов.

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

Что меняется:

• Ответственность. Разработчики отвечают не только за написание кода, но и за работоспособность сервиса в продакшн.
• Коммуникация. Команды должны чётко определять контракты между сервисами и соблюдать их.
• Экспертиза. Появляется потребность в специалистах по DevOps, наблюдаемости, распределенным системам.

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

Чек-лист для вашего перехода

Прежде чем переходить на микросервисы, проверьте себя по этому списку:

• вы определили бизнес-проблему, которую будете решать микросервисами (а не просто хотим «быть как Netflix»);
• спроектировали границы сервисов на основе бизнес-доменов — DDD, Bounded Context;
• у каждого сервиса будет собственное хранилище данных;
• предусмотрели кросс-каттинговые сервисы — логирование, аутентификацию, мониторинг;
• готовы к организационным изменениям — автономные команды, DevOps;
• выбрали правильный уровень детализации сервисов (не слишком мелкий);
• продумали межсервисную коммуникацию — асинхронную, через события.

Netflix, Amazon и Uber прошли этот путь. Они не избежали ошибок, но выстроили процессы для развития сложных систем. Микросервисы — это эволюция архитектуры и команды. Начинайте с малого, не бойтесь менять решения. Главный критерий успеха — скорость доставки ценности пользователям без поломок продакшена. Если этот показатель растет — вы на правильном пути.

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

Пример Spotify, каждый раздел — это отдельные автономные приложения, склеенные в одном клиентском интерфейсе.

Рассмотрим такой подход с позиции менеджмента и разработки.

Разработка веб-приложения

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

Проект придётся сшивать из отдельных частей

Каждый микрофронтенд — это автономный проект с отдельным репозиторием и командой, что даёт гибкость в разработке и упрощает понимание кодовой базы той части, над которой предлагается работать. Но такой подход вынуждает постоянно согласовывать интеграции с другими командами, а ещё не факт, что в компании будет человек, который знает, как функционируют отдельные части. Если такого человека нет или он был и пропал, то разбираться придётся самостоятельно, а вникать в чужой код всегда долго и больно. Помочь избежать bus factor может хорошо составленная документация, а также соблюдение стандартов написания кода, единые для всех команд.

Важно, что один из узлов должен отвечать за сбор как раз всех микрофронтендов и отображении их пользователю.

В проекте можно будет экспериментировать

В микрофронтендах каждая команда может выбирать свой стек под отдельные задачи — React, Vue, Angular или всё, что душе угодно . Это позволяет экспериментировать и постепенно внедрять новые технологии, не переписывая монолит. Но такая свобода — палка о двух концах: без строгих соглашений дизайн и UX могут стать разрозненными, а при запуске страницы — нагрузка дублирующихся библиотек будет бить по производительности.

Но всё-таки это даёт возможность разрабатывать и внедрять новые технологии и практики, независимо от легаси кода. Например, если приелось делать фронтенд на React, то отдельный компонент можно реализовать на Vue. Или, если в будущем существующие библиотеки будут неконкурентоспособны, не надо будет переделывать весь проект, а только проблемные компоненты.

Проект будет сложнее деплоить

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

Однако настройка CI/CD для множества микрофронтендов — это сотни конвейеров, репозиториев и интеграций, которые нужно синхронизировать и контролировать, что особенно тяжело для DevOps-инженеров, которым вместо того, чтобы один раз настроить пайплайн развёртывания для фронта, придётся делать это для каждой его части. К тому же добавляется ещё один этап развёртывания проекта - сбор фронтенда, под который нужно будет прописывать свои правила сборки.

Как применять в проекте

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

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

Webpack Module Federation

Module Federation — механизм, встроенный в Webpack 5, который позволяет одному фронтенду (host) динамически загружать модули из другого фронтенда (remote) во время выполнения. Это мощный инструмент для интеграции микрофронтендов: он поддерживает разделение кода, кэширование, совместное использование зависимостей (например, React или Vue) и независимую доставку каждого модуля. Module Federation работает без необходимости использовать iframe или перекомпиляции.

Инструкция по использованию

Менеджмент

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

Один проект превращается во множество

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

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

Команды будут независимы друг от друга

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

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

Команды получают поле для удачных и не очень экспериментов

Команды могут внедрять новые технологии, не дожидаясь переписывания всего приложения: один микрофронтенд можно сделать на React, другой — на Vue или Svelte. Это даёт гибкость в найме, миграциях и экспериментах. Но чем больше технологий используется, тем сложнее следить за их использованием и труднее помнить их особенности.

В какой-то момент менеджер вместо одной технологической карты управляет целой экосистемой со своими внутренними правилами.

Появляются FrontOps

Микрофронтенды требуют дополнительных усилий по настройке и деплою, для этого понадобится расширять команду DevOps. Эта команда может расширяться настолько, что внутри неё придется выделить подгруппу DevOps, которая будут заниматься исключительно деплоем фронтов — называться они будут FrontOps.

Вывод

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

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

Синьор-фронтендер из ВК Маргарита Лукина, автор телеграм-канала «Фронтенд кухня» отмечает, что микрофронты — не всегда удачное решение:

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

Делитесь своим опытом работы с микрофронтендами в комментариях и не забывайте сохранять наши статьи!

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

В отличие от ChatGPT, где мы задаём конкретный вопрос, агент получает задачу и самостоятельно решает, что и как делать: искать информацию, писать код, обращаться к внешним API, работать с базами данных и сохранять результаты. И это не фантазия: рынок таких решений может вырасти до $70,5 млрд к 2030 году (по данным Grand View Research). Гиганты вроде OpenAI, Google, Microsoft активно продвигают агентную архитектуру как будущее LLM.

В мае 2025 года ресёрчеры из университета Карнеги-Меллон запустили The Agent Company, смоделировав виртуальную софтверную фирму, укомплектованную LLM-агентами. ИИ-агенты кодили, использовали GitLab и общались через мессенджеры. Но результат оказался неоднозначным: лучшие агенты справились только с 24% задач. Многие застряли на мелочах — например, не смогли закрыть всплывающее окно или обработать файл .docx.

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

Что поручить агенту: базовый минимум или роскошный максимум?

Этот материал подготовлен совместно с командой стартапа Agnetics по разработке кастомных автономных агентов для бизнеса. Своим опытом и комментариями поделятся фаундер проекта Владислав Славкин и CPO Данила Калиникин. Вместе с ними на простых примерах разберём, на что способны агенты, и попробуем расставить задачи по уровню автономности.

Простые задачи

Большинство LLM легко справляются с одношаговыми запросами: сделать выжимку из текста или заполнить JSON по инструкции. Это базовый минимум, который даже open-source модели выполняют без дообучения.

Или всё-таки роскошный максимум? Есть фановый тест, на котором спотыкаются даже признанные лидеры бенчмарков. Мы называем его «Тест Яши». Он кажется элементарным — по сути, это просто работа с позициями символов. Даём следующее задание: «В тексте “Яша Лава” передвинь пробел на две буквы влево».

Наслаждаемся пока ещё значимым превосходством своего вида над жалкими опенсорсными LLM.

Почему так?

• Недостаток обучающих данных. В тренировочных наборах, скорее всего, мало примеров с позиционной работой на уровне символов.
• Особенности токенизации. Модель внутри оперирует не буквами или символами, а токенами — кусками текста разной длины. Позиционное смещение пробела «на две буквы» для модели — неочевидная задача, так как иногда для этого нужно разделить токен.
• Специфика токенизатора. Qwen3 и другие китайские модели могут ошибаться из-за токенизатора, оптимизированного под иероглифы.
• Возможное влияние alignment. Это процесс настройки модели на безопасные и корректные ответы. Если результат покажется ей «неуместным», она может намеренно отклониться от инструкции и выдать искажённый ответ. Но это лишь гипотеза: ошибки случаются и на совершенно безобидных данных.

LLM с «руками»: агенты и инструменты

Следующее направление — агенты с набором инструментов для взаимодействия с внешним миром. Чтобы LLM понимала, как обращаться к внешним сервисам и запускать функции, в системный промпт добавляют инструкции и few-shot-примеры. Чтобы упростить создание таких агентов, разработан MCP — открытый протокол, стандартизирующий общение между агентами и инструментами.

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

Разберём базовый сценарий с инструментами на примере — агенте Lexa с 3 функциями: get_weather, kill_user и get_current_date. Внутри системного промпта даны инструкции: как и когда использовать каждую из фич.

1. Пользователь спрашивает: «Какой сегодня день?»;
2. Lexa вызывает get_current_date. Инструмент выводит текущую дату в виде 1337-02-28 и возвращает агенту;
3. Агент формирует ответ в удобоваримом для человека формате: Сейчас 1337 год, 28 февраля.

Как с этим справляются разные LLM?

• Проприетарные модели, типа ChatGPT от OpenAI или Google Gemini, обычно умеют выполнять такие задачи из коробки.
• Open-source модели — зависит от конкретной модели и уровня её дообучения. Например, в LM Studio есть значок молотка и пометка «Trained for tool use» (дообучена для работы с инструментами).

Задача кажется простой: агент вызывает инструмент, возвращая ответ в формате JSON. Но в реальных условиях есть нюансы:

• Обязательная структура ответа и парсинг. Инструмент должен выдать ответ в нужном формате, иначе всё сломается. И даже если он выдал всё правильно, агент может криво считать ответ и зафейлить цепочку.
• Стабильность и безопасность LLM. Модель — «чёрный ящик», который может сгенерить что угодно. Поэтому довольно опасно, если агент управляет важными системами, например, базами данных. Вероятность ошибки в структуре ответов есть почти всегда. С рисками нужно работать, но в наших силах только уменьшить вероятность ошибки и её цену.
• Плохой auto-fix. Даже если задетектить ошибку и сообщить об этом модели, она не всегда сможет её исправить. Часто приходится полностью менять промпт, чтобы получить более-менее стабильный агентный пайплайн.

Мультиагентные системы: разделяй и властвуй

Один агент — хорошо, а два лучше? Представим, что мы поручили агенту Lexa забронировать билеты на самолёт. Когда одному агенту приходится и парсить сайты, и фильтровать результаты, и оформлять бронирование, и объяснять всё пользователю — он захлебывается в контексте. ИИ, как и человек, хуже справляется, если делает всё одновременно.

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

Пример: главный агент Lexa-master получает запрос на бронирование билета на самолёт. Он не занимается бронированием напрямую, а делегирует другому агенту — Lexa-slave. Тот ищет рейсы и бронирует билет. Lexa-master возвращает результат пользователю.

Зачем вообще плодить агентов? Сейчас можно запросто выпилить Lexa-slave, и обработка упростится. Но представим, что завтра понадобится сравнение по цене и длительности, или запрос будет «Я хочу улететь завтра утром, но не раньше 9:00, бизнес-классом, и только Аэрофлотом».

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

Где подвох?

Ресурсоэффективность

• Чем больше агентов в цепочке, тем медленнее ответ и больше переходов между ними.
• Каждое обращение к агенту-помощнику требует времени и вычислительных ресурсов.
• Решение задачи обходится дороже.

Ошибки накапливаются

• Каждый из агентов — потенциальное слабое звено, может неправильно понять запрос, сформировать ответ или запутаться в данных.

• Один косяк может сломать всю цепочку.
• Чем длиннее цепочка, тем выше вероятность сбоя.
• Чтобы компенсировать это, нужны механизмы контроля и валидации.

Автономные агенты

Можно ли назвать автономным Telegram-бот, который просто отвечает на вопросы? Он работает 24/7 и не требует постоянного участия человека — значит, формально автономен. Но это лишь базовый минимум. Такой бот — как робот-сборщик на конвейере: повторяет одни и те же действия без улучшений.

Сценарий здесь достаточно прост — фактически, это REST API для бота или цикл while True с time.sleep(N) для запланированного выполнения одних и тех же задач.

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

Чтобы понять, как работает продвинутый автономный агент, возьмём генерацию изображений. Попробуем воспроизвести в Perchance AI детализированную картинку по описанию. Формулируем запрос: «девушка сидит на крыше, вид сверху, съёмка дроном с большой дистанции». Отправляем его и ждём результат.

Получив изображение, мы внимательно его анализируем. Если что-то не так: например, ноги и руки выглядят странно или детали не совпадают с промптом, корректируем запрос и запускаем генерацию заново. Так повторяется цикл: формулируем, получаем, анализируем, корректируем.

Выглядит как простой и повторяющийся процесс. На самом деле он очень вариативен: иногда, чтобы получить нужный результат — уходят часы, а иногда — достаточно и одной генерации. Бывает и так, что добиться задуманного не получается вовсе. Генерация зависит от множества факторов, включая банальный рандом. Любое изменение в запросе может радикально поменять итоговое изображение. Зачастую к качественному результату приводят очень странные, извилистые и не очень понятные нам промпты.

Если самые топовые генераторы изображений не всегда следуют промпту, то системы распознавания и VLM сильно опережают их в адекватности. Можно сделать такого агента и автоматизировать процесс генерации, добившись более высоких результатов в следовании промпту (prompt-following). Это решается тем, что он будет сам отсматривать, анализировать и корректировать результат. Подобный подход (Image Reflection) успешно используют в OmniGen.

NetTyan — автономная стримерша, играющая в Minecraft

Нам стало интересно, как далеко можно зайти в автономности: как работают агенты, когда им поручают нестандартные задачи, где нет чётких инструкций? Может ли агент играть в игру наравне с реальными игроками, вести стрим в одиночку, удерживать внимание зрителей, реагировать на чат и игру в реальном времени. Так родился проект нейростримерши, который начинался как фановый эксперимент «на коленке», и перерос в B2B стартап по разработке агентов.

NetTyan — персонаж, который сам играет в Minecraft и ведёт прямые эфиры, развлекая игроков и зрителей. Она бегает по публичным серверам, общается в чате, троллит игроков, отвечает зрителям, комментирует происходящее, как настоящий стример — и всё это делает LLM. На Хабре мы уже рассказывали про стек и кропотливую работу над архитектурой, а здесь поговорим о другом: что мы поняли о границах LLM-автономности в проде.

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

С железом и архитектурой всё гладко. NetTyan сама заходит на серверы, сама общается с чатом и порой даже не уступает реальным игрокам по скиллу. Весь стек реализован на локальных open-source решениях, никаких токенов и подписок. Если урезать пайплайн и поставить «компромиссную» LLM, то её можно запустить даже на ноутбучной RTX 2060.

Почему NetTyan не стала звездой Twitch

Автономность — наш главный фокус. Мы хотели, чтобы LLM-агент был самостоятельным не только в поведении, но и в развитии. Что NetTyan — не просто виртуальная кукла, а полноценный стример, который сам растёт, подстраивается под тренды и работает с аудиторией. Без ручного микроменеджмента и постоянного завоза апдейтов. Мы сделали ставку и на то, что агент будет сам себя продвигать — как персонаж и автор.

На этом фоне логично прозвучит вопрос: а почему не автоматизировать нарезку и постинг клипов? Это отдельный масштабный и сложный проект. Мы приняли решение не тратить на это ресурсы, так как эффективность пока сомнительная. На начальных этапах разработки open-source VLM (vision LLM) были слишком слабы. Сейчас с InternVL3 ситуация получше, поэтому планируем к этому вернуться позже.

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

Может ли ИИ стать популярным без участия человека? Пока нет. Попадание в тренды, вирусный контент — исключительно человеческая прерогатива. Просто быть автономной — это не повод для популярности. Зрителям нужен мемный контент. Именно человек понимает, что сейчас хайпанёт: реагирует на повестку, вкладывает эмоции.

Что у конкурентов? Посмотрите на похожие ИИ-проекты: Neuro-sama, AI Princess, Овсянка. Основной трафик приходит с контента, смонтированного вручную. Залетевшие видео — это не геймплей c агентом, а музыкальные клипы, срежиссированные диалоги, сгенерированные каверы. За кадром стоит огромная работа продюсеров и контентмейкеров. В этих проектах ИИ — скорее компаньон в виде Live2D-аватарки с голосом, а не полноценный автор.

Когда исчерпывается человеческий ресурс — работа встаёт. Если говорить о кейсе Maria-AI, функционально она была действительно очень автономна: круглосуточно стримила на Twitch и собрала несколько тысяч подписчиков благодаря регулярности. Но даже с такой автономностью проект не смог продолжать работу и недавно приостановил трансляции.

Кажется, мы уже это слышали: проблема однотипности GenAI-контента

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

Большая часть агентной логики и поведения зашита в фиксированном промте. Личность, бекстори, реакции, манера общения, ToV — всё прописывается один раз. Из-за этого реплики повторяются и становятся однотипными, а реакции — скудными.

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

Каждый стрим с чистого листа

Настоящего роста, как у живого автора контента, у ИИ-стримеров нет. Они не могут делать «работу над ошибками», так как не понимают, что вчерашний стрим зашёл, а сегодняшний — нет. Живой стример ориентируется на фидбек: Discord, Reddit, комменты в чате, донаты. Он может почувствовать, что формат устарел, что пора сменить пластинку: добавить больше шуток или наоборот — сбавить градус.

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

Современный процесс инференса LLM не предполагает дообучение в процессе работы — это проблема, которая сильно лимитирует возможности агентов в самостоятельной работе над задачей. Если специально не прикручивать дообучение в реальном времени — никакого прогресса не будет. Агенты пока не могут «учиться» от стрима к стриму, так как не запоминают предыдущие сессии.

Здравый смысл вышел из чата

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

Хороший пример — бенчмарк ARC-AGI 3. Вы можете сами попробовать решить такую задачу. Сначала она может показаться непонятной, сложной и даже нерешаемой, но если попробовать несколько раз — вы научитесь её решать. Но даже самые современные LLM ломают об неё свой нейронный «лоб», решая менее чем на 1%. Но и эта ситуация может измениться, ведь разработчики могут дообучить модели на подобные задачи.

Что будет дальше с NetTyan?

Мы очень весело провели время, работая над проектом. Для себя мы поняли, что важна не только технология, но и люди вокруг — классные коллаборации могут вытянуть контент, даже если ИИ пока не идеален. Дальше — два пути:

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

Итог такой: проекты, ставящие на высокую автономность, но мало работающие с продвижением и коллабами — остаются на дне. Те, кто максимально использует ручной труд, — в топе. Мы решили, что не собираемся отказываться от автономности — потому что это невероятно интересно!

Три идеи на будущее по прокачке автономности LLM-агентов

Приведём несколько перспективных, но пока что слишком амбициозных направлений, которые могут улучшить работу автономных LLM-агентов. Однако важно понимать: это прежде всего идеи для исследований и экспериментов.

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

• Сейчас довольно легко реализовать песочницу среднего качества. Например, выделить вспомогательного агента, который будет возвращать промежуточные версии ответов для корректировок.
• Если смотреть на перспективу, нужен встроенный в LLM блок, который будет прогонять гипотезы перед ответом. Это уже требует значительного изменения в архитектуре модели.

Адаптация под задачу. Современным агентам сильно не хватает адаптивности на уровне архитектуры. Исправив это, добавив в LLM возможность адаптации в рамках одной задачи (или проекта), можно сильно повысить эффективность модели в сложных долгосрочных задачах.

• Обучить Lora-модуль перед постановкой на задачу. При этом модель остаётся фиксированной при исполнении. Такой подход уже показал эффективность, например, в статье «Drag-and-Drop LLMs», и его уже можно пробовать повторить. Минус этого подхода — нужно решить, когда и на чём проводить эту вычислительно-затратную процедуру дообучения. В сервисах вроде чат-ботов можно добавить возможность для пользователя обучить адаптер на одном промпте. Также можно настроить триггеры на автоматическое переобучение адаптера. Это может пригодиться, если есть какие-то сверхдолгосрочные задачи, в которых требуется автоматизация. Если использовать подход из статьи, то промпт для обучения адаптера мы можем сгенерировать агентом. Если собирать датасет — тогда нужно кастомное решение вроде reward-моделей.
• Реализовать динамически изменяемую модель прямо во время инференса (для сложных случаев). Тогда нужно создать такой Lora-адаптер, который сможет «подстраиваться» к задаче на лету, прямо во время исполнения, не изменяя модель целиком. Или спроектировать архитектуру модели таким образом, чтобы она динамически изменялась прямо во время исполнения.

Мультимодальная память с легкозаменяемым контекстом. Если хранить всю информацию внутри промпта, модель быстро забъёт весь контекст и начнёт забывать старую информацию. Адаптер поможет хранить персональные особенности общения прямо в весах модели.

• Дообучаемый модуль можно адаптировать, используя его как память. В формате адаптера Lora-модуля, небольшой ИИ-модели, хранить информацию о каждом пользователе, со всеми фактами, событиями и историей взаимодействия.
• Можно пойти ещё дальше: сделать так, чтобы память и контекст хранились в виде векторов (условно, цифровых слепков информации), которые можно менять прямо во время работы. Тогда ИИ-агенты, вроде стримеров смогут реагировать на события мгновенно, а не после полного запроса. Но здесь сложность в том, чтобы перестроить архитектуру модели, чтобы она могла быстро менять своё состояние в процессе работы.

Чек-лист: готов ли ваш агент к продакшену

Функциональная полнота:

• Агент уверенно закрывает ключевые сценарии без ручных подпорок.
• Нет «серых зон», где пользователь остаётся без ответа или решения.

Качество ответа:

• Точность и полезность проверены на тестовом наборе реальных запросов.
• Есть минимальная целевая метрика (например, ≥ 90 % релевантных ответов).

Скорость реакции:

• Среднее время ответа ≤ 3–6 сек.
• Пиковая нагрузка протестирована и не приводит к тайм-аутам.

Модерация и безопасность:

• Встроен фильтр токсичности и персональных данных.
• Агент не отдаёт приватный контент и вежливо отказывает на опасные запросы.

Логи и мониторинг:

• Собираются логи запросов, ответы, ошибки, метрики времени.
• Настроены алерты: рост 5xx, увеличение задержек.

Откат и «план Б»:

• Есть fallback-сценарий: если LLM не отвечает, пользователь получает шаблонный ответ или переносится на живого оператора.
• Механизм «чёрной кнопки» — быстрая смена модели или остановка сервиса.

Обновляемость модели:

• Подготовлена процедура безопасного fine-tune / релиза новой версии.
• Старые веса и промпты хранятся, чтобы при откате ничего не потерять.

Конфиденциальность и лицензии:

• Проверены лицензии моделей, датасетов и TTS/STT-движков.
• Конфиденциальные данные шифруются или остаются on-prem, если того требует бизнес.

Стоимость эксплуатации:

• Считаем стоимость инференса: $/1000 токенов или GPU-часы.
• Есть лимиты — агент не «съедает» бюджет при резком росте трафика.

Пользовательский опыт:

• Тональность и стиль общения согласованы с ToV бренда.
• Первые 10–20 пользовательских сессий прошли юзабилити-тест и получили положительный фидбек.

Заметили, что массового внедрения не произошло? Разработчики не спешат переписывать рабочий код на дженериках.

По каким причинам обобщённые типы оказались невостребованными? — ответим на этот вопрос вместе с участниками тг-канала Golang GO.

Почему дженерики не вытеснили интерфейсы?

Интерфейсы задают структуру программы: реализуют паттерны декоратора, роутера, зависимости. Дженерики лишь усиливают существующие интерфейсы, делают их безопаснее.

Разработчики, ожидавшие революцию в проектировании, обнаружили, что дженерики годятся только для узкого пула задач.

Тащить их везде может быть чревато не только потерей производительности, но и рефакторингом больших объёмов кода. Далеко не каждая компания сейчас потянет такие затраты. Тем более, если неясны перспективы.

Наиболее оправданный случай использования дженериков — замена interface{} в местах, где тип известен на этапе компиляции:

Когда всё-таки использовать дженерики?

Практика показывает, что обобщённые типы нашли применение в конкретных областях.

У нас они часто используются: много дженерик-функций для кеширования, маппингов, сохранения в базы данных, передачи по gRPC, работы с брокерами, почти вся CRUD-админка на дженериках. Из плюсов — меньше кода, из минусов — иногда сложно понять, что происходит с конкретной сущностью

1. Пулы соединений и кэширование

Наиболее очевидное применение дженериков — создание типизированных контейнеров.

Например, этот пул соединений будет работать с любым типом ресурсов, поддерживающих закрытие:

Аналогично с кэшированием. Можно создавать строго типизированный кэш, который возвращает значения правильного типа на этапе компиляции:

2. Математические операции

Дженерики избавляют от дублирования кода для разных числовых типов:

3. Функции высшего порядка

С появлением дженериков появилась возможность создавать типобезопасные функции высшего порядка для работы с коллекциями:

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

4. Обёртки для API и протоколов

Так выглядит обёртка ответа с типизированным полем результата на дженериках:

Компилятор гарантирует соответствие типов на этапе компиляции. До дженериков приходилось использовать json.RawMessage и распаковывать на уровне роутинга.

5. Репозитории и CRUD-операции

Типизированные интерфейсы для работы с данными:

Как дженерики повлияли на тесты?

Однозначно стало проще создавать универсальных хелперов для тестирования:

Почему дженерики в Go не такие, как в других языках?

Отсутствие обобщённых типов болезненно воспринимали разработчики, перешедшие в Go из Java, C#, C++ и других языков с дженериками.

Добавление функционального программирования — это тренд Rust, Kotlin и других современных языков. Без дженериков в Go было бы сложно переписывать код в функциональной парадигме с других языков.

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

Например, это работает:

А такая функция уже не скомпилируется:

Привычные паттерны из Rust, Java или C# в Go просто не реализуемы. Вместо методов приходится использовать функции:

Как дженерики изменили разработку на Go?

Типовые задачи в Го до появления дженериков решали иначе. Приходилось использовать пустой interface{}, генерировать типобезопасный код с помощью go:generate, stringer.

Несмотря на недостатки, дженерики поменяли подход к разработке.

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

Обобщённые типы активно используются в библиотеках. Взять тот же samber/lo и функции Map, Filter, Reduce на дженериках. Ещё стандартная библиотека пополнилась пакетами slices и maps.

Что касается производительности — ожидания не оправдались. Думали, что избавились от преобразований типов и получили прирост скорости? На деле разница минимальна. В реальных приложениях узкое место не в типах, а в работе БД, сетевых запросах или бизнес-логике.

Что в итоге?

• Интерфейсы остаются основой архитектуры Go-приложений, дженерики их дополняют, но не заменяют.
• Обобщённые типы полезны только для конкретных задач. Применяйте по необходимости, когда дженерики устраняют дублирование кода или повышают типобезопасность.
• Упрощайте тестирование — универсальные хелперы для проверок и утверждений.
  
• Избегайте преждевременного обобщения — не пишите код через дженерики «на всякий случай».
• Параметры типов лучше всего подходят для контейнеров, кэшей, математических функций.
• Привычные паттерны из других языков не реализуемы — приходится адаптировать подходы под Go.
• Усложнение понимания кода — иногда непросто разобраться, что происходит с конкретной сущностью.

Поделитесь опытом использования дженериков — где они реально помогли, а где оказались излишними? Удивите примерами удачного и неудачного применения!

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

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

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

Микросервисы: зачем они нужны и в чем их плюсы

Архитектура приложений: немного базы

Под капотом современных приложений обычно скрываются три основные части:

• множество библиотек и зависимостей;
• единый store, в котором живут состояние и данные;
• компоненты, которые нужно собрать, чтобы сделать из них приложение.

Собрать это все можно по-разному. Можно сложить в монолит, а можно попробовать модульный подход.

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

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

Масштабировать можно и монолиты, но у них всегда остается какая-то единая точка отказа — например, база данных. Особенно если это реляционная СУБД, завязанная на Oracle или PostgreSQL. Когда база достигает сотен гигабайт или даже терабайт, масштабировать такую штуку становится дорого, больно и ненадежно.

Микросервисы — панацея? Не совсем

Тренд на микросервисный подход появился в начале 2010-х годов, вместе с проникновением интернета в широкие слои населения. Первый iPhone вышел в 2007 году, люди стали гораздо ближе к интернету, к данным, к информации. Бизнес захотел дотянуться до этой аудитории, и тогда началась диджитализация, сложность систем стала повышаться. Особенно остро это почувствовали крупные организации вроде банков: функциональность увеличивалась, и монолит начал «трещать» не только технически по инфраструктуре, но и по возможностям команд разработки, которые с ним работали.

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

Распространение DevOps-культуры и инструменты оркестрации

Раньше разработчик писал код, собирал артефакт и перекидывал его через забор в поддержку. Коллеги за забором его деплоили, запускали — и разработчику можно было больше не думать про плоды своей работы.

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

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

Проектируем микросервисы без боли: от стандартов до DDD

Стандартизация — наше все

Если каждый микросервис пишет логи в своем формате и использует свои библиотеки, получается зоопарк. Нужно, чтобы были выровнены стек и CI/CD pipeline, существовали одинаковые библиотеки логирования и формат.Микросервисы дают свободу писать на разных языках, но с ней приходит и ответственность: под каждый язык придется придумывать и поддерживать разные инструменты. А это приведет к еще большему увеличению сложности. Так что с языком тоже лучше соблюдать стандартизацию: если пишете на Java, то и решать все проблемы стоит с помощью этого языка.

При этом иногда другой язык вполне оправдан. Например, просто потому, что Java не может работать с такой высокой скоростью, какая нужна. В некоторых случаях даже на Java приходится писать особым образом, либо можно использовать C++, Go или Rust. Но это скорее исключение из правила.

Инженеры — натуры увлекающиеся и любят паттерн CV driven development, когда хочется новую технологию потрогать и внедрить у себя. А потом похвастаться этим на каком-нибудь ивенте по принципу «just because I can» («просто потому что могу»). При этом может оказаться, что бизнесу технология особо и не была нужна. Чтобы избегать таких ситуаций, необходим технологический радар — список того, что можно использовать в компании, а что нет. И исключения из такого радара должны приниматься и допускаться очень взвешенно.

DDD: как правильно нарезать сервисы

Одна из опасностей при проектировании микросервисов — скатиться в очень мелкую гранулярность, когда логика нарезается чуть ли не по отдельной функции на микросервис (на отдельный deployment unit). Это может привести к такой сложности, которой потом будет очень трудно управлять. Такая проблема была, например, у Uber в начале их пути, и им пришлось пересматривать свою архитектуру. Избежать этого помогает Domain-driven design (DDD) — предметно-ориентированное проектирование.

Вместо того чтобы пилить отдельные сервисы для авторизации, логирования и уведомлений, команда может подумать вот над чем: все это части одного бизнес-контекста — пользовательского доступа. И целесообразно оставить их в одном сервисе. Это и есть DDD в действии.

Существует и еще одна проблема, с которой DDD помогает справиться, — неправильная нарезка сервисов с точки зрения бизнесовой функциональности. Если не понимать бизнес-контекста, можно получить «распределенный монолит»: будет много отдельно стоящих сервисов, но профита никакого, только все сложности микросервисов плюс проблемы монолита с масштабируемой базой данных. Особенно остро это проявляется, когда изменения в одной части бизнес-процесса (в одном сервисе) влекут за собой изменения еще в трех-четырех-пяти других сервисах.

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

Еще один важный принцип правильной архитектуры микросервисов — у каждого микросервиса должна быть своя независимая маленькая база данных (если она вообще нужна).

Два эмпирических правила, которые касаются размера сервисов и помогают понять, правильно ли они спроектированы:

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

Внедрение микросервисов: с чего начать?

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

И вот тут возникает реальная сложность, особенно когда вы только начинаете, — глаза разбегаются. Здесь Kubernetes, здесь ELK, здесь Grafana, здесь observability, здесь всякие паттерны отказоустойчивости, CAP-теорема и прочее. Непонятно, куда бежать. И каждый день появляются новые инструменты, которые так или иначе упрощают жизнь.

Совет: задавайте себе вопрос о каждом инструменте, который вы хотите внедрить (будь то Kubernetes, OpenTelemetry с Jaeger или любой другой) — какую проблему мы решаем, втаскивая его в свою инфраструктуру? Ответ на этот простой вопрос может дать много инсайтов и просветлений.

Чтобы в первом приближении ознакомиться с темой, можно почитать материалы SRE от Google, также будут полезны статьи и книги в блоге Мартина Фаулера, в том числе Microservices Guide. Если вам нужна практика, можно попробовать пойти на тот же Udemy, где есть множество курсов по микросервисной архитектуре с хорошими рейтингами и отзывами.

И вот что важно: при проектировании и внедрении микросервисов лучше избегать «велосипедостроения». Если индустрия уже решила проблему, нет смысла изобретать новое логирование или оркестрацию. Собственное решение вряд ли будет работать лучше, а сил, времени ресурсов на него можно потратить очень много.

Поддержка микросервисной архитектуры

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

В крупных организациях микросервисов могут быть сотни: например, в некоторых системах насчитывается почти 700 микросервисов на продакшене. Каждый инстанс еще масштабирован — это тысячи подов, которые постоянно обрабатывают клиентский трафик. И при этом в современных условиях нужно стремиться к доступности системы на уровне четырех девяток (99,99%), то есть к простою всего в несколько минут в год.

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

Паттерны отказоустойчивости

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

Еще один хороший вопрос: как мониторить аварии? Необходимо очень быстро находить точку отказа. Для этого, собственно, и нужен observability-подход, трейсинг. Нужно смотреть, где какой RPS (число запросов в секунду), не произошло ли резкого скачка трафика, важно следить за latency (задержками).

Бывали случаи, когда из-за бага в мобильном приложении трафик внезапно удваивался, и системы не выдерживали такой нагрузки. Любая малейшая задержка в самом незначительном компоненте может привести к тому, что по цепочке пойдет отказ, — будут копиться потоки, соединения, и рано или поздно упадет вообще все. Чтобы подготовиться к таким ситуациям, важно изучить хотя бы четыре «золотых сигнала» мониторинга из SRE от Google.

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

Сейчас часто используют паттерны, которые помогают поддерживать отказоустойчивость системы:

• Circuit Breaker — если сервис спамит ошибками, лучше временно прекратить попытки до него достучаться. Для клиента ничего не изменится, он как получал ошибки, так и будет получать. Но, по крайней мере, можно дать системе возможность восстановиться. А еще лучше — позволить ей переключиться на какой-то резервный канал, например сходить в кэш с неактуальными данными.
• Rate Limiter — абсолютно банальная, но необходимая вещь. Нужно ограничивать входящий поток на примерно максимальном уровне от того, который ожидается. Чтобы все не развалилось, если произойдет резкий скачок трафика.
• Blue-Green Deployment — значительно снижают на продакшене количество аварий и проблем, связанных с кривыми релизами. Можно не раскатывать новую фичу сразу на все 100 подов, а выкатить ее только на 1% трафика и проверить.

И это только малая часть паттернов.

Все это must have для абсолютно любой системы. Даже если у вас низкая нагрузка, она когда-нибудь увеличится. Лучше вовремя предусмотреть это, заранее потратив чуть больше времени и реализовав эти паттерны.

Как эффективно работать с инцидентами

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

Первый уровень — это application-слой, сами сервисы, которые в подах крутятся в Kubernetes. Нужно проверить, все ли у них хорошо по точкам интеграции — нет ли тайм-аутов. Все ли в порядке у них по железу — по CPU, по памяти, по дискам.

Если на первом уровне все нормально, нужно опуститься на уровень ниже — либо на виртуалки, на которых Kubernetes развернут, либо на железки, если он развернут на Bare-metal. Недавно мы столкнулись с интересным случаем: виртуалка показывала нормальную загрузку CPU, но физический гипервизор, на котором она крутилась, был загружен на 99%. Естественно, виртуалка страдала, но уровнем выше этого не было видно.

Совет: если вы вдруг нашли что-то, что еще не мониторится, — это повод поскорее добавить эту метрику, начать ее мониторить и ретроспективно отслеживать.

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

Вообще, человеческий фактор — это отдельная боль. Все привыкли менять что-нибудь руками: заходить в виртуалки, поправлять конфиг. Чтобы такого было как можно меньше, важно вкладываться в infrastructure as a code и даже everything as a code. В идеале следует стремиться к zero access production — нулевому доступу к продакшену — и все раскатывать через Git, через конфигурации, включая политики безопасности.

Культура ответственности и изменение ролей в команде

Представим, что происходит инцидент — падают 15 микросервисов. Как должна быть устроена система, которая позволит оперативно справляться с авариями?

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

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

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

Однако эти организационные моменты еще не гарантируют быстрого решения проблемы. Ключевой фактор — культура компании. На людей часто нападает отстраненность — авария случилась, и все думают: «Кто-нибудь другой разрулит. Я разработчик, ну, что я там сделаю?»

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

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

Проще говоря, есть два варианта взаимодействия с поддержкой: классический, когда она административно отделена, и SRE-подобный, когда сотрудники «второй линии» прямо интегрированы в команду разработки. Могу сказать, что второй эффективнее.

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

Это то самое SRE, о котором пишет Google. Но людей нужно долго обучать такой культуре — это не дело одного месяца. Благодаря такому подходу инженеры, которые раньше были просто разработчиками или аналитиками, глубже осознают свою ответственность за стабильность продакшена. И это действительно правильное направление развития. Потому что и DevOps, и SRE — это в первую очередь культура, а уже во вторую — набор инструментов.

Будущее микросервисов: тренд на AI Ops

Разработчики уже используют AI как copilot — и это очень мощный инструмент в умелых руках. Он не заменяет инженера, но сильно экономит ему время. Эту помощь от нейросетей очень хочется растянуть и на инфраструктуру, и на эксплуатацию, чтобы получить крутой AI Ops.

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

Есть прототипы — например, Big Panda или Moocsoft (который был недавно куплен Dell), но пока это точечные решения. Возможно, на горизонте 5–7 лет (скорее 5, чем 10) они станут серьезной частью индустрии и очень мощным прорывом, который упростит разработчикам жизнь.Кроме того, важно, чтобы развивались и более «приземленные» технологии: инструменты контейнеризации, оркестрации, observability, а также APM — Application Performance Monitoring.

Инженер остается в центре всего

Никакие микросервисы, Kubernetes и AI Ops не спасут, если за системой не стоит инженер, который думает головой, правильно работает руками и отвечает за результат. Важны его навыки, кругозор и культура работы. Именно такие люди превращают набор сервисов в работающий продукт. Все остальное — только инструменты.

P. S. Если интересно, как мы решаем эти задачи на практике, слушайте (и смотрите) наш подкаст «Техно.Логично» — там регулярно обсуждаем самое актуальное в IT-сфере.

Определение и особенности монолитной архитектуры

Что такое монолитная архитектура и какие у неё основные характеристики

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

Основные характеристики:

• Единое хранилище кода и структур данных.
• Тесная взаимосвязь компонентов: изменения в одном модуле часто требуют обновлений в других.
• Унифицированное развертывание: приложение разворачивается в одном контейнере или среде.

Плюсы монолита

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

Минусы монолита

• Сложность масштабирования. Масштабирование требует копирования всего приложения, даже если нужно повысить производительность только одной его части. Плюс если высокую нагрузку испытывает лишь одна часть приложения, увеличивать производительность приходится для всей системы.
• Зависимость компонентов. Любое изменение в одном модуле может привести к непредсказуемым последствиям в других частях системы. К тому же трудно изолировать ошибки и снижать взаимные влияния между частями приложения.
• Долгосрочная поддержка. Переход на новые технологии требует переработки всей системы. Например, если монолитная архитектура построена на устаревшей версии фреймворка, переход на более современный инструмент требует изменений во всех связанных модулях, включая базу данных, пользовательский интерфейс и API.
• Риск единой точки отказа. Ошибка в одном компоненте может привести к полной остановке всего приложения.

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

Определение и особенности микросервисной архитектуры

Что такое микросервисная архитектура и её ключевые аспекты

Микросервисы как архитектура представляет собой подход, при котором приложение разбивается на независимые модули (микросервисы). Каждый микросервис выполняет определённую бизнес-функцию, имеет собственную базу данных (или доступ к её сегменту) и взаимодействует с другими через API.

Ключевые аспекты:

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

Плюсы микросервисов

• Гибкость. Микросервисы можно развивать независимо друг от друга. Так, в музыкальные стриминги (по типу Яндекс.музыки) новый функционал приложения можно добавлять без изменения сервиса, отвечающего за управление библиотекой треков.
• Масштабируемость. Каждый микросервис масштабируется отдельно в зависимости от нагрузки. Не нужно тратить время и мощности но прокачку одних и тех же функций одновременно, а сосредоточиться на приоритетных.
• Независимое развертывание. Обновление одного микросервиса не требует остановки всей системы. Например, если в приложении нужно обновить модуль расчёта стоимости (если мы разрабатываем Ozon или WB), это не повлияет на работу модуля оформления заказов.

Минусы микросервисов

• Сложность в настройке. Организация микросервисной архитектуры требует грамотной настройки инфраструктуры. Например, необходимо настроить API-шлюз для управления запросами, систему контейнеризации (например, Docker) и оркестрацию (Kubernetes).
• Необходимость управления сетью. Микросервисы взаимодействуют через сеть, что может приводить к задержкам и ошибкам. Например, если сервис обработки платежей не отвечает из-за проблем с сетью, процесс оформления заказа на том же Озоне может быть временно недоступен.
• Сложности в тестировании. Интеграционное тестирование требует симуляции взаимодействия между десятками или сотнями сервисов.

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

Сравнение монолита и микросервисов

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

Производительность: какая архитектура быстрее и почему

Монолит

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

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

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

Масштабируемость: вертикальное и горизонтальное масштабирование

Монолит

Плюс монолита в том, что его масштабирование осуществляется вертикально (больше оперативной памяти —> мощнее процессор). Это быстро, но дорого, и есть физические ограничения на увеличение ресурсов.

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

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

Поддержка и обновление: как быстро можно добавлять новые функции

Монолит

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

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

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

Командная работа: как архитектура влияет на распределение задач в команде

Монолит

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

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

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

Факторы, которые влияют на выбор архитектуры

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

Размер и опыт команды разработчиков

Маленькая команда

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

Большая команда

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

Уровень опыта

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

Сложность и масштаб проекта

Простые проекты

Для небольших приложений монолитная архитектура подходит идеально.

Сложные и крупные проекты

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

Требования к производительности и масштабируемости

Низкие требования

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

Высокие требования

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

Планы на будущее и возможность роста проекта

Краткосрочные проекты

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

Долгосрочные проекты

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

Инфраструктура и доступные ресурсы

Ограниченная инфраструктура

Монолитные приложения не требуют сложной инфраструктуры. Их можно развернуть на одном сервере и минимизировать затраты на администрирование.

Развитая инфраструктура

Вам нужно настроить архитектуру, и микросервисы в этом случае потребуют контейнеризации (Docker), оркестрации (Kubernetes) и мощных инструментов мониторинга.

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

Кейсы, или практические советы по выбору архитектуры

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

Когда стоит использовать монолит

• Простые проекты. Локальный магазин для продажи органической продукции, где пользователь может оформить заказ через простую корзину, а администратор получает уведомление на почту.
• Стартапы с ограниченными ресурсами. Новый бренд, продающий уникальные дизайнерские украшения, быстро запускает MVP с базовыми функциями: каталог, корзина, оплата и личный кабинет.
• Приложения без высоких требований к масштабируемости. Интернет-магазин для корпоративных клиентов, где покупки совершаются нерегулярно, и основная нагрузка на сервер минимальна.

Когда подходят микросервисы

• Крупные проекты. Большой интернет-магазин с тысячами товаров, сложной структурой категорий и разными модулями (каталог, поиск, рекомендации, платежи).
• Распределённые команды. Когда команда в одной стране разрабатывает сервис логистики, а команда в другой — систему интеграции с локальными платёжными провайдерами.
• Приложения с высокой нагрузкой. Маркетплейс, который обрабатывает миллионы запросов в секунду, поддерживает сложные фильтры, рекомендации и динамическое ценообразование.

Как перейти с монолита на микросервисы

1. Оцениваем текущую архитектуру

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

2. Разрабатываем стратегию миграции

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

3. Обеспечиваем инфраструктуру

Настраиваем контейнеризацию для запуска микросервисов (например, Docker для микросервисов каталога и управления заказами с общей базой данных).

4. Используем очередь сообщений

Реализуем асинхронное взаимодействие сервисов. Можем настроить очередь RabbitMQ для передачи данных о новых заказах от фронтэнда к микросервису логистики.

5. Тестируем взаимодействие сервисов

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

Примеры реальных проектов и их архитектурных решений

Примеры компаний, которые используют монолит и преуспели в этом

Basecamp

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

Shopify

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

GitHub

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

Примеры компаний, которые выбрали микросервисную архитектуру

Netflix

Для масштабируемости и высокой доступности Netflix перешел от монолитной архитектуры к микросервисам. Это позволило им эффективно обрабатывать большое количество запросов пользователей и улучшить управление различными компонентами системы.

Amazon

Amazon, особенно его платформа Amazon Web Services (AWS), также широко использует микросервисы. Переход к такой архитектуре позволил Amazon улучшить управление масштабируемостью, изоляцию сбоев и гибкость развертывания. Каждый сервис отвечает за отдельную задачу, что делает платформу более гибкой и облегчает масштабирование отдельных компонентов.

Ошибки, которых стоит избегать при выборе и реализации архитектуры

1. Вы не понимаете требования

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

Совет: Тщательно анализируйте требования к масштабируемости, безопасности, производительности и возможностям роста, прежде чем принимать решение о типе архитектуры.

2. Вы не учитываете долгосрочные последствия

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

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

3. Вы игнорируете опыт и возможности команды

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

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

4. У вас проблемы с тестированием

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

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

5. Вы не уделяете внимание безопасности

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

Совет: Включите в архитектурное проектирование практики безопасности с самого начала, независимо от того, выбрали вы монолит или микросервисы.

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

Ошибка 1: Вы зависите от одного провайдера облачных услуг

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

Реальные примеры ошибки

1. AWS Outage в 2017 году:

В феврале 2017 года Amazon Web Services (AWS) испытал длительное отключение в одном из своих дата-центров, что повлияло на множество приложений и сервисов, зависящих от их облачных услуг. Многие компании — Slack, Trello и Airbnb, столкнулись с проблемами, что привело к сбоям в их сервисах. Этот случай продемонстрировал уязвимость зависимых систем.

2. Опасности «lock-in» в облачных платформах:

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

Как командам избежать этой ошибки

1. Используйте многооблачную стратегию:

Многооблачная архитектура позволяет распределить ресурсы между несколькими провайдерами (например, AWS, Google Cloud, Microsoft Azure). Это снизит зависимость от одного поставщика и сделает систему более устойчивой и гибкой.

2. Стандартизуйте API и интерфейсы:

Проектирование системы с использованием стандартных интерфейсов (например, RESTful API) позволяет легче менять облачные услуги без значительных нововведений в коде.

3. Обрабатывайте данные в гибридной модели:

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

4. Используйте контейнеризацию:

Использование контейнеров (например, Docker) и оркестрация (например, Kubernetes) позволяет переносить приложения между различными облачными провайдерами без значительных изменений в инфраструктуре.

Ошибка 2: У вас нет кэширования

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

Реальные примеры ошибки

1. Netflix:

Netflix сталкивался с проблемами производительности, когда пользователи запрашивались множество однотипных данных (метаданные о фильмах, например). Это привело к значительным нагрузкам на базы данных и увеличивало время отклика.

2. Pinterest:

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

Как командам избежать этой ошибки

1. Выбирайте подходящий механизм кэширования:

Команда должна определить, какой тип кэширования лучше всего подходит для их приложения: кэш на уровне сервера (например, Memcached, Redis) или кэширование на стороне клиента (например, браузерное).

2. Кэшируйте часто запрашиваемые данные:

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

3. Используйте HTTP-кэширование:

Здесь помогут заголовки HTTP Cache-Control, ETag и Last-Modified, чтобы управлять кэшированием на уровне сервера и клиента.

4. Обновляйте кэш:

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

Ошибка 3: Вы неправильно структурировали базу данных

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

Реальные примеры ошибки

1. Delta Airlines:

Delta Airlines столкнулась с проблемами производительности своей базы данных. Причиной стало плохое проектирование, что замедлило обработку онлайн-бронирований. Для решения проблемы компании пришлось значительно переработать архитектуру базы данных — оптимизировать структуру таблиц и индексов.

2. Facebook*:

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

*Компания Meta признана экстремистской на территории РФ

Как командам избежать этой ошибки

1. Проектируйте БД на основе требований:

Это база! (данных). Перед началом проектирования важно анализировать бизнес-требования, чтобы понять, как данные будут использоваться. Это поможет определить, какие таблицы и связи необходимы.

2. Следуйте правилам нормализации:

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

3. Используйте индексы:

Установка индексов на поля, которые часто используются в условиях WHERE и JOIN, может значительно улучшить производительность запросов. Но следует также осторожно подходить к индексированию, чтобы не перегружать систему.

4. Поддерживайте архивирование и шардирование данных:

Если БД становится слишком большой, следует рассмотреть возможность шардирования (разделение базы на части) или архивирования старых данных.

5. Используйте инструменты моделирования баз данных:

Применение инструментов по типу ER-диаграмм для визуализации структуры базы данных может помочь лучше понять связи между данными и выявить потенциальные проблемы до их реализации.

Ошибка 4: Вы не используете микросервисную архитектуру для масштабируемых систем

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

Реальные примеры ошибки

1. Spotify:

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

2. PayPal:

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

Как командам избежать этой ошибки

1. Определите границы сервисов:

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

3. Используйте API для взаимодействия:

Микросервисы должны общаться друг с другом через API. Что важно, это способствует независимости одного сервиса от другого и делает каждый более масштабируемым.

4. Внедряйте DevOps и CI/CD:

Для успешного развертывания и управления микросервисами необходимо внедрить практики DevOps и непрерывной интеграции и доставки (CI/CD). К ним относится автоматизация тестирования, деплоймента и управления версиями.

5. Переходите к микросервисам постепенно:

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

Ошибка 5: Вы игнорируете принцип единственной ответственности (Single Responsibility Principle)

Принцип единственной ответственности (SRP) предполагает, что каждый класс или модуль должен выполнять одну функциональную задачу. Игнорирование этого принципа может привести к чрезмерной связности и сложности кода, что затрудняет его тестирование, отладку, модификацию и поддержку.

Реальные примеры ошибки

1. Одна из E-commerce платформ

В ранней версии e-commerce платформы класс Order обрабатывал и управление заказами, и логику расчёта налогов, и взаимодействие с платёжным процессором. Это усложняло управление кодом и добавляло риски при любых изменениях. После переработки системы с использованием SRP была создана отдельная служба расчёта налогов и платёжная служба, что значительно упростило код и улучшило его тестируемость.

Как командам избежать этой ошибки

1. Определите задачи каждого модуля или класса:

На этапе проектирования приложения важно чётко определить задачи каждого модуля или класса. Они должны быть узко сфокусированы, что поможет упростить логику.

2. Используйте абстракции и интерфейсы:

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

3. Применяйте паттерны проектирования:

Использование паттернов проектирования, таких как Strategy или Observer, может помочь разделить ответственности между классами и облегчить модификацию и расширение функциональности.

Ошибка 6: У вас нет системы мониторинга и логирования

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

Реальные примеры ошибки

1. Uber:

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

2. LinkedIn:

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

Как командам избежать этой ошибки

1. Используйте мощные фреймворки логирования:

Использование мощных фреймворков логирования по типу Log4j или Serilog позволяет эффективно записывать важную информацию о работе приложения.

2. Мониторьте в реальном времени:

Необходимо использовать инструменты мониторинга — Prometheus, Grafana или New Relic для наблюдения за производительностью серверов, баз данных и приложений в реальном времени

3. Определите ключевые показатели производительности (KPI):

Чёткое определение и отслеживание KPI (время отклика, нагрузка на сервер и количество ошибок) предоставит командам доступ к важной информации о здоровье системы.

4. Анализируйте логи:

Создание процессов для анализа логов поможет командам выявлять паттерны ошибок, а не лишь быстро решать точечные проблемы. Для этого можно использовать решения, такие как ELK Stack (Elasticsearch, Logstash, Kibana).

5. Настройте уведомления и алерты:

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

6. Тестируйте с нагрузкой:

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

Ошибка 7: У вас есть заблуждение о «сделай всё сразу» и нет итеративного подхода

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

Реальные примеры ошибки

1. Microsoft:

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

2. Volkswagen:

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

Как командам избежать этой ошибки

1. Планируйте и приоритезируйте задачи:

Необходимо четко определить основные требования и приоритизировать задачи. Используйте методики, например, MoSCoW (Must have, Should have, Could have, Won't have), чтобы определить важность функционала.

2. Не забывайте про итеративную разработку:

Внедряйте циклы разработки, основанные на итеративных подходах, по типу Scrum или Kanban. Это позволит командам адаптироваться и быстро реагировать на изменения в требованиях.

3. Управляйте изменениями:

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

4. Используйте подход Lean:

Рассмотрите внедрение Lean-подхода, который акцентирует внимание на устранении потерь в процессе разработки и оптимизации всех этапов создания продукта.

Ошибка 8: Вы неправильно обрабатываете ошибки

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

Реальные примеры ошибки

1. NASA:

Проект Mars Climate Orbiter был потерян из-за ошибки в обработке данных, связанной с несоответствием единиц измерения. В то время как одни команды использовали метры, другие работали в дюймах. Эта ошибка не была должным образом обработана, что привело к тому, что аппарат вошёл в атмосферу Марса под неправильным углом и сгорел. Неправильная обработка ошибок ввела в заблуждение команду, которая не могла вовремя диагностировать проблему.

2. Knight Capital Group:

В 2012 году трейдинговая компания Knight Capital Group потеряла 440 миллионов долларов за 45 минут из-за ошибки в коде. Ошибка, которая была вызвана неправильной обработкой исключений, привела к некорректным трейдам. Система продолжала работать, не показывая значительных признаков сбоя, что усложняло реакцию команды и в итоге привело к коллапсу.

Как командам избежать этой ошибки

1. Единообразно обрабатывайте ошибки:

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

2. Разделяйте ошибки на категории:

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

3. Используйте адаптивное логирование:

Логирование должно фиксировать не только ошибки, но и контекст их возникновения. Используйте уровни логирования (DEBUG, INFO, WARN, ERROR) для записи информации, которая может помочь в диагностике.

4. Настройте грацию исключений:

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

5. Тестируйте сценарии ошибок:

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

Ошибка 9: Вы игнорируете кроссбраузерность и мобильную адаптивность

Игнорирование кроссбраузерности и мобильной адаптивности может привести к тому, что пользователи будут испытывать трудности при использовании приложения. Это может снизить пользовательский опыт, увеличить уровень отсева и негативно сказаться на репутации компании.

Реальные примеры ошибки

1. Expedia:

В 2018 году, после неудачного редизайна своего сайта, Expedia заметила значительное снижение конверсий, особенно на мобильных устройствах. Дополнительные тесты показали, что новый интерфейс выглядел и работал плохо в определённых мобильных браузерах. Отказ от полноценной поддержки мобильной адаптивности привёл к значительным финансовым потерям.

2. BBC:

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

Как командам избежать этой ошибки

1. Используйте фреймворки и библиотеки:

Рассмотрите использование популярных фреймворков и библиотек по типу Bootstrap или Foundation, которые включают встроенные механизмы для кроссбраузерности и мобильной адаптивности.

2. Проводите автоматизированное тестирование:

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

3. Изучайте стандарты и спецификации:

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

Ошибка 10: Вы оптимизируете на ранних стадиях разработки

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

Реальные примеры ошибки

1. NASA:

В проекте Mars Climate Orbiter обнаружили, что разработчики слишком увлеклись оптимизацией кода обработки данных. Это привело к потере фокуса на основном функционале и неправильным единицам измерения. Результатом стало то, что не было видно проблемы, когда аппарат не вошел в атмосферу Марса, что обернулось его разрушением. Позже NASA поняла, что важнее сосредоточиться на правильной реализации основных функций, прежде чем наносить на них оптимизацию.

Как командам избежать этой ошибки

1. Возводите функционал в приоритет:

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

2. Развивайте продукт итеративно:

Используйте итеративные и альфа-версии разработки, чтобы идентифицировать и оптимизировать проблемные места по мере их появления, а не в самом начале. Такой подход позволяет фокусироваться на реальных данных.

Поделитесь вашим опытом в комментариях!

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

Узнаем, каковы принципы и основы событийной архитектуры ПО, каковы преимущества и недостатки такой структуры, как работает EDA на конкретных примерах.

Принципы событийной архитектуры и ее компоненты

Event-Driven Architecture — это распространенный асинхронный шаблон, в котором основной для системных действий становится реакция на какое-либо событие. Здесь событием называют сообщение в разных точках исполняемого кода, возникающее при выполнении ряда условий. Паттерн EDA используется при разработке приложений с высокой масштабируемостью, а также при создании более простых программных продуктов.

Такой архитектурный подход базируется на асинхронном взаимодействии между частями системы. EDA распределяет системные компоненты, что способствует масштабируемости и ускоренной работе приложений и программ, задействованных в самых разных отраслях.

Как работает EDA

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

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

Событийная архитектура состоит из ключевых компонентов:

• Продюсеры (производители). Это компоненты, отвечающие за отправку сообщений. Как только состояние изменяется либо происходит действие в системе, производитель отправляет данные об этом заинтересованной стороне. Продюсером может быть любое фактическое действие, влияющее на состояние кода.
• События. Это сообщения либо пакеты данных, фиксирующие изменения состояние или какое-либо действие внутри компонентов большой системы. В событиях содержатся метаданные, маркирующие источник изменения, метки времени, информация о действии. Например, если клиент в приложении сделал покупку, все данные об этом будут отражены в событии.
• Каналы. Все события доставляются до адресатов (потребителей) по специальным каналам. Первичные каналы событий — это TCP/IP-соединения или файлы различного формата (XML, JSON и т.д.). Возможно одновременное открытие сразу нескольких каналов. Поскольку читаются события асинхронно, их обработка происходит практически в реальном времени.
• Маршрутизатор. Этот компонент идентифицирует первичные события и действия, которые содержатся в сообщении. В ряде источников каналы и маршрутизаторы объединяют в компонент, который называется брокером — именно брокер запускает утверждения, которые становятся ответом на действие. При этом сам маршрутизатор не обрабатывает события, а лишь выдает соответствующие инструкции получателю.
• Потребители (получатели). Эти компоненты отвечают на сообщение соответствующим образом. Это может быть обновление данных, инициация новых процессов в приложении, вызов удаленных служб. Потребители — это наиболее автономные элементы архитектуры, выполняющие конкретные задачи. Уровень потребителей детализации варьируется от элементарного к сложнейшему в соответствии с особенностями ПО.

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

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

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

Преимущества

Шаблон EDA имеет большой список плюсов:

• Высокая масштабируемость. Отсутствие связанности компонентов обеспечивает масштабируемость системы при необходимости. Например, если в онлайн-магазине значительно повышается спрос на товары, архитектура легко справится с обработкой, не задействуя другие службы.
• Асинхронная связь. Архитектура работает по принципу асинхронной связи компонентов — то есть части системы включаются, не дожидаясь взаимных ответов. Параллельная обработка существенно повышает эффективность программных продуктов.
• Надежность (отказоустойчивость). В EDA системах минимум зависимостей между элементами, что повышает отказоустойчивость. Если с одним из элементов случится сбой, система продолжит работать с минимальными нарушениями. Брокеры позаботятся о том, чтобы события не были потеряны в процессе сбоя. Событийно-ориентированная коммутация позволяет хранить сообщения в специальном хранилище, где ошибки будут обработаны.
• Быстродействие приложений. Поскольку события обрабатываются асинхронно и в режиме онлайн, это обеспечивает высокую скорость реагирования на сообщения. В EDA-структурах компоненты отвечают на изменение статуса кода сразу, что максимально сокращает время между действиями и их обработкой. По этой причине событийная архитектура — идеальный вариант для ПО, где мгновенная обработка данных и оперативное реагирование критично важны, например, на финансовых платформах.
• Бесшовная интеграция. Программы с архитектурой EDA легко интегрируются с другими приложениями для обмена сведениями и прочих взаимодействий. События потребляются и создаются независимо от задействованных языков программирования и технологических решений.
• Гибкость. Event-Driven предполагает модульный подход к разработке системы. Это значит, что изменение отдельных компонентов практически не влияет на статус всей системы. Повышается скорость реагирования на новые задачи и потребности, улучшается адаптивность, что сокращает период разработки и программные ресурсы.

Таким образом, продукты с EDA высокопроизводительны и способны параллельно выполнять операции с минимальными затратами.

Примеры использования Event-Driven архитектуры

Существует множество знакомых нам систем, которые работают по принципу событийной архитектуры. Рассмотрим наиболее типичные направления.

Электронная коммерция

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

Интернет вещей

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

Регистрация и верификация пользователей

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

Системы оповещения

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

Аналитика

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

Управление рабочими процессами

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

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

Архитектура Event-Driven применяется для взаимодействия множества микросервисов в разных направлениях, что позволяет создавать при необходимости слабосвязанные и при этом быстро масштабируемые системы.

Реальные примеры

Многие компании с международным статусом внедрили в свои ресурсы системы архитектуры EDA, чтобы обеспечить масштабируемость и гибкость программных продуктов.

Среди таких организаций Netflix — один из наиболее популярных стриминговых сервисов. Вся инфраструктура этой платформы управляется событиями: система одновременно контролирует множество потоков и обеспечивает клиентам высококачественный сервис.

Еще один пример EDA — платформа для заказа автомобильных поездок Uber. События в этой системе представлены изменениями геолокации, что позволяет операторам отслеживать местоположение тысяч водителей одновременно.

Технологии для реализации EDA

Для реализации EDA применяется несколько технологий. Обозначим наиболее значимые из них.

Event Sourcing

В переводе с английского — «поиск событий». Этот шаблон документирует все изменения статуса системы в виде набора упорядоченных событий. Взамен обновления статуса данных система фиксирует изменения как определенные события.

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

CQRS

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

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

Message Broker

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

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

Вызовы и недостатки EDA

Поскольку в ИТ-сфере (как и в других отраслях) нет ничего совершенного, у EDA есть свои недостатки и подводные камни. Рассмотрим их подробно.

Сложная структура

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

Согласованность событий

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

Порядок событий

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

Управление и мониторинг

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

Итоги

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

И обязательно рассказывайте в комментариях, где применяете event-driven архитектуру.

Всем привет! Меня зовут Евгений Ефанов, я мобильный разработчик в Red Collar.

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

Когда я начинал, существовало несколько архитектурных подходов, среди которых можно выделить BLoC и Redux. Позднее появился Provider, а также ряд других, менее распространённых архитектур.

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

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

В итоге хотелось бы сделать архитектурный компонент, который будет способен реагировать и подписываться на события в системе, а также хранить и предоставлять доступ к определённым данным. Этот компонент должен позволять нам изменять эти данные и отслеживать их изменения (BLoC).

Кроме того, хотелось бы реализовать механизм хранения этих компонентов и обеспечить возможность их подключения друг к другу. Это позволит нам заменять компоненты моками при тестировании. По сути, это будет простой DI-контейнер, разделенный на скоупы.

Также мы хотим иметь доступ к компонентам и их состоянию через глобальный объект во всех частях приложения аналогично тому, как это реализовано в Redux.

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

И наконец по аналогии с виджетами хотелось бы иметь простой цикл жизни компонента: инициализация и деинициализация.

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

Дополнительным преимуществом является то, что описанный подход может быть применён к любой из платформ, позволяя использовать идентичные механизмы как во Flutter, так и в SwiftUI и Compose. Это облегчает переключение между платформами, так как мы используем одинаковые компоненты бизнес логики. В следующих статьях я расскажу, как реализовать эти механизмы для других платформ.

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

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

Создаем базовый класс

Для начала рассмотрим базовый класс MvvmInstance, который станет основой для всех механизмов. В первую очередь определим в нём два ключевых метода: initialize и dispose, аналогично стандартным виджетам. При инициализации также будет передаваться input для данного объекта. Здесь же можно сразу добавить асинхронный метод для инициализации — initializeAsync.

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

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

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

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

Подключим события

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

Один из наиболее удобных механизмов для отправки событий — это Event Bus. Он, например, активно используется в приложении Signal на платформе Android, что можно увидеть в репозитории с исходным кодом.

Реализовать Event Bus во Flutter очень просто, используя встроенный механизм стримов.

Имея такой класс, мы можем подключить ранее созданный MvvmInstance к получению событий. Сам Event Bus при этом является синглтоном и доступен из любого места в коде.

Для того чтобы подписаться и отписаться от событий, мы можем использовать методы initialize и dispose, которые мы описали на первом шаге.

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

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

Теперь мы можем вызывать экземпляр MvvmInstance как напрямую, так и через событие.

Подключаем стейт

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

Мне нравится механизм Redux, в котором есть хранилище, и мы можем подписываться на его обновления. Разница лишь в том, что само хранилище будет находиться внутри каждого экземпляра и содержать только те данные, которые нужны для этого элемента. Чтобы реализовать такой механизм, необходимо прежде всего создать объект, который будет хранить значение, которое мы сможем обновлять, а также подписываться на изменения. Здесь снова на помощь приходят встроенные механизмы Dart.

Здесь мы снова используем broadcast stream и инкапсулируем текущее значение данных.

Имея такой класс, мы можем создать хранилище для данных нашего MvvmInstance.

Стор способен хранить Observable и выдавать обновление значения для конкретного поля state.

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

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

Подключаем зависимости

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

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

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

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

Упрощённая реализация такого класса может выглядеть следующим образом:

Здесь мы храним словарь билдеров, которые будем генерировать, а также контейнер уже созданных объектов, чтобы получить их, если инстанс уже создан.

Словарь объектов также разделим на скоупы, чтобы мы могли разделить наши инстансы. В качестве дефолтных скоупов можно сразу прописать глобальный скоуп, где мы будем хранить синглетоны — они будут инициализироваться сразу при открытии конечного приложения. Так же можно добавить unique скоуп — в таком случае всегда будет создаваться новый экземпляр. Также можно добавить weak скоуп — в этом скоупе будут храниться глобальные объекты, однако в отличие от global скоупа они будут уничтожаться когда все зависимые от них инстансы уничтожены. Остальные скоупы, которые определяет пользователь, будут работать аналогично weak скоупу — когда все зависимые от скоупа экземпляры будут уничтожены, все объекты в скоупе также будут уничтожаться.

Таким образом, если в нашем словаре ещё не создан нужный нам инстанс, мы его конструируем, вызываем initialize для него и возвращаем инициализированный инстанс. Если же он уже существует, то сразу возвращаем этот объект.

Для генерации словаря билдеров будем использовать source_gen. Мы можем сгенерировать метод, который будет добавлять билдеры в коллекцию и вызвать его при запуске приложения.

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

После того как мы получили словарь объектов, мы можем подключить их к нашему MvvmInstance.

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

Зная список зависимостей для нашего MvvmInstance, мы можем также взять их из словаря инстансов при инициализации.

Описываем архитектурные сущности

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

Каждая сущность будет подключена к событиям

В слое domain я выделил interactor — это сущность, которая хранит стейт. Она удобна для изоляции логического компонента, например, для работы со списком постов. Здесь мы можем получать список постов с сервера, а также подписаться на событие лайка на конкретном посте, чтобы обновить коллекцию в состоянии (стейте) объекта.

Также я выделяю wrapper — этот элемент не хранит состояние (стейт) и служит обёрткой для каких-либо сторонних библиотек. Например, мы можем подключить библиотеку для проверки текущего состояния сети. Это позволяет абстрагироваться от библиотеки и легко заменять ее методы при тестировании.

На уровне presentation я выделяю view model — по сути, это interactor, входными данными для которого является view, к которому подключена эта view model. Здесь мы можем подключить интеракторы с нужными данными и прописать binding’и, которые нужны для отображения.

В итоговом варианте мы получаем следующую структуру для загрузки постов:

Как все это протестировать

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

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

Ниже представлены примеры, как можно протестировать каждую сущность.

Вывод

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

В своей работе над реальными проектами я активно применяю все компоненты данной архитектуры. Бизнес-логика представляет собой некое количество интеракторов, количество которых даже в крупном проекте позволяет быстро внедрять зависимости в компоненты (например, view models), предотвращая любые возможные зависания при инициализации. Тестировать эти компоненты удобно, поскольку бизнес-логика полностью покрыта unit-тестами.

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

Как реализовать аналогичные механизмы на swiftui и compose , я расскажу в следующих статьях.