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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итого

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

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

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

Трассировка через eBPF снимает налог на ручное инструментирование, но требует ядра не ниже 5.8, несрезанной таблицы символов и знания устройства планировщика Go.

При 50 000 запросах в секунду и четырёх точках съёма на запрос получается 200 000 входов в ядро ежесекундно и потолок расхода в 200–600 мс процессорного времени на ядро.

Медленный запрос это не одна проблема, а пять разных: лишняя работа, борьба за ресурсы, давление среды, деградация плана и патологические шаблоны вроде N+1.

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

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

Слой первый наблюдаемости: собрать данные, не трогая код

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

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

Почему с Go это сложнее, чем с C

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

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

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

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

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

Главная нерешённая проблема: передача контекста между сервисами

Если нельзя вписать заголовок в коде приложения, как передать идентификатор трассы дальше по цепочке вызовов? Есть три подхода, и практически применим один.

• Писать заголовок прямо в пакет на уровне сетевого интерфейса. Требует расширенных привилегий и работает только для нешифрованного HTTP/1.1: шифрование выполняется выше уровня сокета, и программа видит уже зашифрованные байты.
• Пропускать исходящие вызовы через локальный вспомогательный прокси, который держит соответствие идентификатора горутины и контекста трассы и вставляет заголовки перед пересылкой. Добавляется сетевой переход, зато шифрование не ломается.
• Править карту заголовков прямо в памяти процесса. Соответствующая функция ядра помечена как опасная и действительно способна повредить память: каждая её загрузка пишет предупреждение в журнал ядра, работа требует широкой привилегии CAP_SYS_ADMIN, а в режиме блокировки ядра она запрещена совсем.

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

Что ломается в продакшене

• Идентификаторы горутин переиспользуются. При высокой конкурентности номер может уйти на новую горутину раньше, чем потребитель разобрал события старой.
• Обновление бинарника сдвигает смещения символов. Зонды старого отображения ядро снимает само, и новый бинарник какое-то время работает без трассировки. Слежение за изменением файла сокращает разрыв до секунд, но не убирает его.
• Требования к ядру. Кольцевые буферы нужны ядру от 5.8, а переносимая компиляция зондов требует 5.4 с включённой отладочной информацией о типах. Матрицу ядер стоит проверить до внедрения, а не после.
• Срезанные бинарники. Сборка без таблицы символов и отладочной информации лишает трассировщик возможности сопоставить имена функций со смещениями. Компромисс: оставить хотя бы таблицу символов, заплатив примерно 10–15% размера бинарника.

Сколько это стоит в процессорном времени

Зонды не бесплатны: каждое срабатывание это программное прерывание с входом в ядро. При 50 000 запросах в секунду и четырёх точках съёма на запрос получается 200 000 входов ежесекундно. Опубликованные замеры дают порядка 1–3 мкс на срабатывание на современном оборудовании, то есть верхняя оценка расхода составляет 200–600 мс процессорного времени в секунду на одно ядро.

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

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

Слой второй: превратить трассы в решения

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

«Медленный запрос» это пять разных диагнозов

Прежде чем что-то чинить, стоит понять, чем именно болен запрос. Разбор CNCF раскладывает медленные запросы к базе на пять непохожих причин:

• Лишняя работа. Обычно это полный перебор таблицы из-за отсутствующего или неприменимого индекса. Выборка по идентификатору клиента без индекса растёт с 20 мс на десяти тысячах строк до минут на десяти миллионах. Запрос не менялся, изменился объём данных.
• Борьба за ресурсы. Идеально оптимизированный запрос стоит в ожидании блокировок или свободного соединения. Запрос, проводящий 95% времени в ожидании блокировки, оптимизацией текста не лечится: ему нужна перекройка транзакций.
• Давление среды. Насыщение процессора, узкое место ввода-вывода и нехватка памяти замедляют любой запрос с любым планом: тот же текст запроса и тот же план на нагруженной машине отработает в разы дольше, чем на свободной, и оптимизировать тут нечего.
• Деградация плана. Данные и текст запроса те же, а план исполнения изменился. Устаревшая статистика после массовой загрузки заставляет планировщик выбрать заведомо плохую стратегию.
• Патологические шаблоны. Проблема N+1 выполняет сотню быстрых запросов по две миллисекунды последовательно, добавляя двести миллисекунд задержки на одно только выполнение, не считая сетевых издержек на каждый обмен с базой. Ни один запрос не является медленным, а шаблон катастрофичен и в журнал медленных запросов не попадает вовсе.

Чего не хватает встроенным инструментам базы

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

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

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

Слой третий: не принять смену измерения за изменение продукта

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

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

Общий тренд не объясняет вашу просадку

В июньском наборе данных о реальных пользователях Chrome, опубликованном в середине июля, доля источников с хорошей отрисовкой основного содержимого упала до 67,7%, с хорошей задержкой отклика на взаимодействие до 85,9%, а доля проходящих все три ключевых показателя до 55,3%. Исключением оказалась стабильность вёрстки, поднявшаяся до 81,4%.

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

Гарри Робертс формулирует критерий проверки прямо: если общая доля прошедших упала на 1,2 процентного пункта, а конкретный сайт просел на четыре, широкий тренд разницу не объяснил. Верно и обратное: если сайт почти идеально повторяет рынок по браузерам и устройствам, срочное расследование в коде потратит время всей команды впустую.

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

Изменение методики выглядит как изменение продукта

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

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

Компенсация это не исправление

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

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

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

Что забрать с собой

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

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

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

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

Идемпотентность — свойство операции, при котором повторное выполнение приводит к тому же состоянию, что и однократное. Сам ответ при этом может отличаться: повторный DELETE вернёт 404 вместо 200, и метод от этого идемпотентным быть не перестаёт. У HTTP это закреплено на уровне методов: RFC 9110 относит к идемпотентным PUT, DELETE и безопасные методы, а POST идемпотентным по своей природе не является. Бизнес-операции почти всегда отправляют именно через POST.

Клиент не может отличить «сервер не получил запрос» от «сервер выполнил операцию, но ответ потерялся», поэтому повтор придёт в любом случае.

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

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

Запись в базу и отправка в очередь в одну транзакцию не помещаются. Обёртывать сетевой вызов в BEGIN и COMMIT вредно вдвойне: корректности не даёт, а пул соединений выедает.

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

Почему повтор неизбежен

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

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

Для GET повтор безвреден. Для POST /payments это второе списание. Отсюда и правило: одна логическая операция должна приводить к одному записанному итоговому состоянию, сколько бы раз её ни отправили. Осознанно новая операция обязана прийти с новым ключом.

Два способа сделать ручку идемпотентной и один в довесок

Способ первый: ключ идемпотентности

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

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

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

Способ второй: сделать операцию идемпотентной по смыслу

Иногда ключ не нужен вовсе, потому что семантику можно спроектировать идемпотентной с самого начала. Классический пример — PUT /users/42, который задаёт полное представление ресурса: отправьте его дважды, и состояние будет одним и тем же.

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

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

Довесок: оптимистичная блокировка

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

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

Где наивная реализация ключа разваливается

Гонка в проверке

Последовательность «проверить наличие ключа, потом вставить» содержит зазор, в который помещаются оба одновременных повтора: обе стороны видят, что ключа нет, и обе выполняют работу. Резервировать ключ нужно атомарно, через уникальное ограничение базы, условную запись или транзакционный compare-and-set (атомарное сравнение с записью).

Это же относится и к примеру с платежом выше: замена словаря в памяти на Redis гонку не закрывает, пока проверка и вставка остаются двумя отдельными командами. Нужен атомарный примитив резервирования, вроде SET key value NX или INSERT ... ON CONFLICT DO NOTHING.

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

Слепок запроса, а не только ключ

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

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

Состояния и коды ответа

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

• 201 или 200 — первый успешно завершённый результат.
• 200 с явной пометкой о повторе — проигрывание сохранённого ответа.
• 202 со ссылкой на статус — работу уже выполняет другой обработчик, начинать вторую не нужно.
• 409 — ключ переиспользован с другим содержимым.
• Задокументированная финальная ошибка — обработка провалилась, и автоматическое продолжение небезопасно.

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

Вторая половина задачи: база и очередь

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

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

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

Почему обернуть это в транзакцию нельзя

Соблазнительный и заведомо неверный вариант выглядит так:

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

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

Outbox: событие как строка в той же транзакции

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

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

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

Этот SELECT и последующая простановка статуса выполняются в одной транзакции: блокировка живёт до фиксации. Благодаря SKIP LOCKED доставщик масштабируется горизонтально из коробки, каждый экземпляр берёт свой набор строк. А если он упадёт посреди пачки, вся пачка откатится и уйдёт повторно, что даёт ещё один довод в пользу идемпотентного потребителя.

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

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

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

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

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

Что добавить перед продакшеном

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

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

Что забрать с собой

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

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

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

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

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

Сначала понять, нужно ли трогать систему

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

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

Поэтому начинают с проблемы:

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

Всё это можно измерить, проверить и объяснить бизнесу. Дальше — варианты.

1. Оставить систему как есть

Иногда самое разумное решение состоит в том, чтобы ничего не менять.

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

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

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

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

Пока ничего из этого не случилось, систему оставляют в текущем виде.

2. Вывести ненужную часть из эксплуатации

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

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

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

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

3. Обновить стек без смены архитектуры

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

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

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

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

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

4. Перенести систему на другую платформу

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

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

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

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

5. Заменить готовым продуктом

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

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

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

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

6. Рефакторить по частям

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

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

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

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

7. Переписать систему постепенно

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

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

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

Как выбрать стратегию

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

Сначала каждую часть системы проверяют по нескольким критериям:

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

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

Что подготовить до начала работ

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

До начала изменений нужно:

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

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

Итого

Легаси необязательно переписывать целиком. Сначала стоит понять, какая именно часть системы мешает работать и почему.

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

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

Ручное тестирование как вход больше не работает

В 2021-м стратегия «вкатиться через мануальное тестирование» ещё работала. Рынок принимал новичков: знаешь, что такое чек-лист и тест-кейс — уже кандидат. Можно было прийти без кода, без понимания API, без SQL и получить оффер на функциональное тестирование, дальше доучиваясь по ходу.

Дальше рынок начал двигаться, и двигался он быстрее, чем кажется внутри компании. В 2022-м в вакансиях QA появились приписки: «желательно знание автоматизации», «опыт с API», «базовый SQL». Слово «желательно» сбивает с толку — звучит как бонус, а на деле это знак, куда поедут требования через пару лет. И они поехали: то, что в 2022-м было «желательно», к 2024-му стало обязательным условием.

К 2024 году ситуация выглядит уже так: смотришь вакансии и ни в одной не встречаешь формулировку «требуется ручной тестировщик». Вместо неё везде QA Engineer со знанием автоматизации, опыт в финтехе, CI/CD, Docker, Kubernetes, углублённое понимание API. К концу 2025-го добавляется ещё и опыт работы с ИИ и LLM.

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

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

Научиться понимать архитектуру

Проектировать системы вам не придётся, это работа архитектора. Задача тестировщика — представлять, как устроено то, что он тестирует, чтобы видеть всю цепочку, а не отдельную кнопку.

На практике это четыре вещи:

1. Как сервисы общаются между собой: синхронно через HTTP, когда один ждёт ответа другого, или асинхронно через очередь сообщений, когда событие кладётся в брокер и подбирается, когда получатель готов.
2. Где хранятся данные и как к ним обращаются разные компоненты.
3. Что произойдёт, если один из сервисов упадёт, и кто из соседних это заметит.
4. Как запрос трансформируется на каждом шаге пути от клиента до ответа.

Зачем это тестировщику. Пока вы тестируете поверхностно — нажал, посмотрел результат, — вы можете зафиксировать, что баг есть, но не объясните почему. На вопрос «где сломалось» ответа нет, потому что система для вас непонятная. Как только появляется понимание потоков данных, сразу становится лучше. Вместо «кнопка не работает» вы говорите: запрос пришёл в Gateway, прошёл в Core-сервис, событие легло в Kafka, консьюмер его прочитал, но в базе нужной записи нет — значит, ищем разрыв на участке между консьюмером и базой. Это уже баг, с которым можно идти к разработчику.

Лучший способ это уложить в голову — поднять микросервисное приложение локально и посмотреть, как сервисы взаимодействуют. Перед практикой имеет смысл прочитать «Designing Data-Intensive Applications» Мартина Клеппмана (на русском вышла как «Высоконагруженные приложения»). Кода там нет, зато подробно разобрано, как системы устроены изнутри, — для QA это полезнее, чем уметь самому писать сервисы.

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

• Microservice Kafka Sample — три сервиса (заказы, доставка, выставление счёта), между ними Kafka, у каждого своя база PostgreSQL, поднимается через docker-compose up. Создаёте заказ в одном сервисе, через какое-то время накладная и статус доставки появляются в других. Удобно трассировать запрос и искать, где он застрял.
• Microservices with Spring Boot and Kafka Demo Project — посложнее: заказы, платежи, склад, распределённые транзакции по паттерну SAGA, поддержка Docker Compose и Testcontainers. Хорошо показывает, что происходит с транзакцией, когда она идёт через несколько сервисов и один из них падает.

Если хочется теории вместе с практикой, на Stepik есть курс «Microservices — паттерны и практика построения микросервисов»: русскоязычный, разбирает паттерны взаимодействия, асинхронные системы, RabbitMQ. Он заточен под понимание концепций, а не под написание продакшн-кода, — то, что нужно.

Три технологии, которые спрашивают всегда

1. HTTP и REST API. REST — это договорённость между клиентом и сервером о том, как они общаются. Клиент просит: дай данные о пользователе с ID 42. Сервер отвечает JSON-ом и кодом: 200 — всё нашлось, 404 — такого пользователя нет, 403 — прав не хватает. Тестировщик, который умеет вызывать API через Postman, curl или код, проверяет логику системы мимо интерфейса — раньше и точнее, чем через клики по экрану. Базовый минимум: методы (GET, POST, PUT, DELETE), коды ответов (2xx, 4xx, 5xx), заголовки, структура JSON, аутентификация.
2. Базы данных и SQL. Почти каждый дефект оставляет след в базе: либо лежит некорректная запись, либо записи нет вообще. Написать SELECT с джойнами, проверить результат агрегации, отловить дубли — ежедневная работа QA-инженера. На собесе это спрашивают как данность, а не как редкий бонус.
3. Брокеры сообщений и Kafka. Kafka даёт сервисам общаться асинхронно: один кладёт событие в топик, другой забирает его, и никто не висит в ожидании. В распределённых системах это стандарт. Если данные не появились там, где их ждали, возможно, они застряли в очереди, а не пропали из базы. Это две разных ситуации, и путать их дорого для бизнеса.

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

Научиться читать логи

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

Выглядит типичная диагностика так:

• Прилетает алерт: сервис X начал возвращать 500-е ошибки.
• Открываете Kibana, фильтруете по временному интервалу и имени сервиса, чтобы отсечь лишний шум.
• Находите трейс конкретного запроса — от входящего HTTP-вызова до ответа базы данных.
• В трейсе видите stacktrace с исключением в определённом классе и конкретным сообщением.
• Дальше тянете за эту нитку до корневой причины: например, оказывается, что упал не сам сервис, а внешний, к которому он обращался, и причина — таймаут.

Помимо Kibana для разбора логов в работе пригодится связка Grafana и Prometheus для мониторинга метрик. Логи отвечают на вопрос «что именно сломалось в этом запросе», метрики показывают картину шире: когда началась деградация, какой сервис первым ушёл в красное, как менялась нагрузка перед инцидентом. Вместе они дают и точку отказа, и контекст вокруг неё.

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

Зачем QA язык программирования

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

Конкретно код у QA уходит на несколько вещей:

• Автотесты — заменяют ручной прогон регресса, гоняются хоть каждую ночь.
• Тестирование API — написать авторизацию, отправить запрос, проверить JSON-схему ответа.
• Генерация тестовых данных — создать тысячи записей с разными параметрами под нагрузочные и граничные сценарии.
• Верификация в базе — SQL-запросы, которые проверяют, что в данных лежит именно то, что должно.
• Shift-left — писать тесты параллельно с разработкой, ещё на этапе требований, чтобы дефекты ловились раньше.

С чего начинать. Java или Python — хорошие первые языки, оба распространены в автоматизации и под оба полно вакансий. Но учить язык лучше в контексте задач тестирования, а не абстрактно по учебнику: сразу написать первый UI-тест через Selenium, сделать HTTP-запрос через RestAssured или requests, дёрнуть SQL-запросом реальную базу.

Инженерное мышление вместо «кнопка не работает»

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

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

1. Спрашивать «почему», а не только «что». Не «кнопка не нажимается», а «почему запрос возвращает 403 именно для этой роли».
2. Держать в голове систему целиком: как правка в одном сервисе аукнется в соседних через Kafka-события, общую базу или контракты API.
3. Заранее прикидывать риски: что сломается первым под нагрузкой, какие граничные случаи опаснее остальных. Сюда же относится участие в проектировании: дефект, пойманный на этапе требований, обходится примерно в десять раз дешевле, чем тот же дефект, найденный в продакшене.
4. Оперировать цифрами: время прогона регресса, покрытие тестами, количество инцидентов.

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

Итого

Если собрать роадмап в один список, маршрут получается такой:

• Разбираться в архитектуре и поднимать демо-микросервисы локально;
• Знать HTTP с REST, SQL и брокеры вроде Kafka;
• Уметь читать логи, потому что в проде это ваш основной инструмент;
• Освоить язык под автоматизацию;
• И приучать себя думать потоками данных, а не кнопками.

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

И ещё одно наблюдение, ради которого статья была написана. Рынок QA за пять лет переписал требования дважды и продолжит переписывать. Гнаться за конкретной строчкой в вакансии бессмысленно — она устареет к следующему собесу. Работает другая установка: целиться не в «войти в IT через тестирование», а в «стать инженером, который умеет тестировать». Первое даёт оффер на год, второе — профессию, которая переживёт любую следующую волну требований.

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

Что такое Agentic SRE

Agentic SRE — это практика, в которой автономные ИИ-агенты помогают наблюдать за системами, анализировать телеметрию (метрики, логи, трейсы) и выполнять ограниченные операционные действия при заданных человеком guardrails (правил безопасности). Агент не заменяет SRE-инженера, а работает как цифровой напарник: собирает контекст, предлагает гипотезы и выполняет только те действия, которые одобрены политикой.

Ключевое отличие от классической автоматизации — способность к рассуждению. Традиционные скрипты реагируют на жёсткие триггеры («если CPU > 90%, то перезапустить»). Агент же может связать всплеск ошибок с недавним развёртыванием, проверить корреляцию по трейсам и предложить конкретный план действий — всё до того, как инженер откроет ноутбук.

Agentic SRE — это ИИ-агенты, которые помогают инженерам наблюдать, диагностировать и реагировать на инциденты.

Основная цель — сократить рутину и ускорить принятие решений, а не заменить человека.

Ключевые сценарии: триаж алертов, инцидент-копилот, автоматический RCA, безопасное исправление, обучение на инцидентах.

Безопасность превыше всего: агенты работают с allowlists, approval gates и полным аудитом.

Российские команды могут строить стек на OpenTelemetry, Prometheus/Grafana, собственных LLM и PagerDuty/Opsgenie.

Почему это важно именно сейчас

Сегодняшние системы стали слишком распределёнными, шумными и динамичными, чтобы человек успевал за ними вручную. Микросервисы, Kubernetes, feature flags и канареечные развёртывания создали ландшафт, где одно изменение может затронуть десятки сервисов, а сигналы о проблемах разбросаны по десяткам дашбордов.

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

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

Из чего строится стек

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

• Телеметрия: OpenTelemetry — стандарт сбора телеметрии — для сбора логов, метрик и трейсов в едином формате.
• Наблюдаемость: Prometheus, Grafana, Datadog, New Relic, Elastic или облачные системы — хранилище и визуализация.
• Оркестрация: MCP-серверы (Model Context Protocol от Anthropic), внутренние API или системы рабочих процессов, которые предоставляют агенту безопасные инструменты.
• Среда выполнения агента: LLM-фреймворки с function calling, планированием и работой с инструментами.
• Рабочий процесс при инцидентах: PagerDuty, Opsgenie, Slack, Jira, ServiceNow — куда агент пишет отчёты и запрашивает подтверждения.
• Safety Layer: RBAC, approval gates, audit logs, allowlists и пути отката — неотъемлемая часть, а не дополнение.

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

Пять сценариев, которые уже работают

1. Триаж алертов: от шума к сути за секунды

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

2. Инцидент-копилот: второй мозг в канале

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

3. Автоматический черновик RCA (Root Cause Analysis)

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

4. Безопасное исправление под контролем

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

5. Обучение на инцидентах: от пожаротушения к профилактике

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

Guardrails: почему доверие важнее интеллекта

Главный риск агентного SRE не в том, что агент слишком умен, а в том, что он может быть слишком уверен в себе. LLM способны генерировать правдоподобные, но неверные объяснения. Поэтому каждая рекомендация должна быть прослежена до реальной телеметрии, а каждое действие — ограничено явными правами.

• Action allowlists: агент может делать только то, что в белом списке.
• Approval gates: рискованные изменения требуют подтверждения.
• Полный audit log: каждое действие агента записывается.
• Read-only mode на этапе внедрения: сначала наблюдаем, потом действуем.
• Разграничение прав по сервисам и командам.
• Human override на каждом шаге: человек всегда может взять управление.

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

Выводы

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

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

Источник: Agentic SRE: The Next Frontier of Reliability — DevOps.com (Neel Shah, 2026).

Всё началось с безобидного, почти рутинного тикета в саппорт:

«У меня тут несколько одинаковых карт создалось. Я вроде один раз нажимал, а их штук пять висит в приложении».

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

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

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

Мы начали разбираться. Стандартный мониторинг показывал норму: дашборды зелёные, в логах тихо, метрики CPU и памяти без отклонений. При этом в базе обнаруживались дубликаты, которых быть не должно. И только тогда, когда мы внимательно посмотрели на коммунальный API Gateway, то поняли что одно изменение от другой команды поменяло идемпотентность работы endpoint-а.

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

Что произошло: хронология инцидента

Архитектура была классической: Клиент → API Gateway → микросервисы,.

Сценарий развивался почти незаметно для стандартных средств наблюдения:

1. Фронтенд: Пользователь нажимает кнопку «Выпустить карту».

2. Gateway: Запрос начинает обрабатываться в API Gateway.

3. Микросервис по созданию карт: честно выполняет работу: создаёт запись в БД и возвращает `200 OK` в Gateway.

4. Новый микросервис: API Gateway вызывает новый микросервис и получает HTTP 500 в ответ от него. Исключение возникает уже после успешного вызова нашего микросервиса, и это ключевая точка разрыва: Gateway считает весь запрос неудавшимся, а ответ нашего микросервиса теряется.

5. Клиент: получает HTTP 500

6. Реакция: Пользователь видит красную плашку ошибки и логично решает: «Не сработало, пробую снова». Более того, с точки зрения протокола HTTP - запросы, в ответ на которые пришла ошибка HTTP 500, можно пытаться отправлять опять.

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

Круг замкнулся. Эпидемия началась.

В компании такого уровня это не было предусмотрено. И это такая обидная ошибка.

Как так получилось?

Вскрылось ошибочное предположение:

«В API Gateway вызов микросервиса создания карт всегда идет последним».

Таким образом идемпотентность достигалась «формально» - ведь если создание карты завершалось с ошибкой - это точно означало что и вызов API Gateway тоже завершится с ошибкой. Сработало ложное чувство безопасности.

Ответ на вопрос “почему так было сделано?” очень простой - это было осознанное упрощение на старте. Все знали об этом, но задача на фикс потерялась в недрах бэклога на очень долгое время. Это классический пример того, как архитектурное допущение и отложенный рефакторинг годами живут в проде, пока их не вскрывает редкая последовательность отказов.-

Что потребовалось изменить

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

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

1. Почему нельзя просто заблокировать кнопку на фронте?

Блокировка кнопки решает проблему только при стабильной сети. Если запрос ушёл, сервер создал сущность, но ответ потерялся — кнопка разблокируется по таймауту, и пользователь нажмёт снова. Это не устраняет корневую причину, а лишь слегка снижает вероятность дубля.

2. Чем идемпотентность отличается от дедупликации в БД?

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

3. Как долго хранить ключи идемпотентности?

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

4. Что делать со старыми клиентами, которые не шлют request_id?

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

5. Обязательно ли делать идемпотентность для всех методов API?

Идемпотентность требуется только для методов, которые изменяют состояние системы — POST, PUT, PATCH и иногда DELETE. Методы чтения (GET, HEAD, OPTIONS) не изменяют данные, поэтому считаются идемпотентными по умолчанию.

6. Как понять, что в вашей системе уже есть скрытая проблема с дублями?

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

Если метрик ещё нет, вот три косвенных признака, которые помогут заподозрить неладное:

• В базе данных периодически появляются записи с одинаковым содержимым, созданные с разницей в несколько секунд.
• Пользователи жалуются на дубликаты карт, заказов или платежей, но вы не можете воспроизвести проблему локально, списываете на то, что пользователи что-то делают не так
• В логах API Gateway периодически всплывают HTTP 500 ошибки, но downstream-сервисы при этом отрабатывают успешно.

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

Итог

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

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

Практический чек-лист: что проверить в своей системе уже сегодня

• Убедитесь, что все критические мутирующие эндпоинты поддерживают ключ идемпотентности.
• Настройте алерты на аномальное количество запросов на создание сущностей от одного пользователя за короткий промежуток времени.
• Проверьте, как ваш API Gateway обрабатывает ошибки — не теряет ли он ответы downstream-сервисов.
• Убедитесь, что фронтенд корректно обрабатывает не только 200, но и 500, 502, 504, не провоцируя пользователя на повторные клики без необходимости.

Эксперты Centicore Group собрали чек-лист из 12 пунктов, которые реально работают при выборе интегратора, а когда у вас станет вопрос подрядчика – вы можете воспользоваться этим списком.

1. Опыт в вашей индустрии

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

Что проверять:

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

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

2. Что по техстеку и обновлениям

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

На что смотреть:

1. Соответствие вашему контуру. Если у вас закрытый on-premise, а подрядчик умеет деплоить только в публичные облака — вам не по пути.

2. Релевантные сертификаты и лицензии. Если делаете финтех — нужен опыт прохождения PCI DSS. Если работаете с госсектором или персональными данными — ищите подрядчика с лицензиями ФСТЭК и ФСБ.

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

4. Геополитические и санкционные риски. В 2026 году для российского рынка это один из ключевых рисков. Что здесь нужно проверять:

• Зависимость от иностранных облаков и компонентов.
• Отдельно open-source библиотек и фреймворков с высокой санкционной уязвимостью.
• Наличие у подрядчика плана «Б» на случай новых ограничений (альтернативные поставщики, российские облака, on-premise).
• Опыт работы с проектами, которые уже проходили через санкционные ограничения.

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

5. Отношение к ИИ-инструментам и low-code решениям. В 2026 году почти все интеграторы так или иначе используют ИИ (Cursor, GitHub Copilot, Claude, внутренние агенты). Важно понимать политику компании. Что проверять:

• Есть ли у подрядчика регламент использования ИИ-инструментов (что разрешено, что запрещено, как проверяется код, сгенерированный ИИ).
• Насколько активно они применяют low-code/no-code платформы и как это влияет на качество и поддержку решения.
• Готовы ли они комбинировать ИИ + ручную разработку или полностью полагаются на «ИИ всё сделает».
• Есть ли у них экспертиза по prompt engineering и проверке качества ИИ-генерируемого кода.

Красный флаг: Подрядчик либо полностью игнорирует ИИ («мы всё пишем руками»), либо говорит «мы всё делаем через ИИ и это в 10 раз быстрее» без упоминания проверок и рисков.

3. Насколько гибкие в разработке

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

Что важно:

1. Подход к кастомизации показывает философию компании. Если подрядчик сразу говорит о готовом решении и предлагает подстроить бизнес-процессы под него — это провал для специфичных задач. Подбор решения под клиента, а не наоборот — признак зрелого подхода.
2. Работа с изменениями — реальность любого проекта. Требования меняются в процессе, это нормально. Agile не на словах, а на деле означает готовность пересмотреть приоритеты, адаптировать бэклог, обсуждать изменения.
3. Понимание бизнес-задачи отличает хорошего интегратора от посредственного. Технари часто зацикливаются на том, как реализовать, забывая спросить, зачем это нужно. Вопрос о том, какую проблему решает функция, должен звучать чаще, чем обсуждение технологии.

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

4. Прозрачность процессов

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

Как оценить прозрачность:

1. Структура коммуникации определяет скорость решения вопросов. Кто ваш контакт — менеджер без технической экспертизы или техлид команды? Как быстро получаете ответы? Есть ли прямой доступ к разработчикам для обсуждения технических деталей?
2. Регулярная отчётность — это не бюрократия, а инструмент контроля. Демо каждый спринт, доступ к таск-трекеру вроде Jira, понимание прогресса в реальном времени. Компании с 24/7 поддержкой обычно имеют настроенные процессы коммуникации и реагирования.
3. Документация показывает зрелость процессов. Если подрядчик не может показать примеры технической документации, процессов разработки, архитектурных решений — это тревожный звонок.
4. Совпадение ценностей и корпоративной культуры. Технические навыки важны, но если ценности не совпадают — проект будет постоянным источником конфликтов. Попросите пообщаться не только с техлидом, но и с 1–2 разработчиками, которые будут работать над проектом. Задайте вопросы про их реальный опыт работы в компании. Что проверять:

• Отношение к удалённой работе и овертаймам (есть ли культура «гореть на проекте» или уважают work-life balance).
• Прозрачность внутри компании (как принимаются решения, насколько открыто руководство общается с командой).
• Отношение к качеству vs скорость (готовы ли отказываться от «быстрых костылей» ради долгосрочного результата).
• Корпоративные ценности: как компания относится к клиентам, к сотрудникам, к этике в разработке.

Красные флаги:

1. Вам говорят, что всё хорошо, но конкретики нет. Нет демо, доступа к репозиторию, промежуточных результатов. А потом в день дедлайна выясняется, что половины функционала нет. Нормальная практика — давать клиенту видимость работы: задачи, коммиты, тесты.
2. Проводите демо результатов каждые 1-2 недели. Так будете видеть рабочий код, сможете проверить функционал, задать вопросы напрямую техлиду. Ошибки дешевле исправлять на ранних этапах, чем в продакшене.
3. Команда говорит одно на собеседовании, а на деле — жёсткий overtime, токсичная культура и «мы просто кодим, а менеджеры решают».

5. Команда и культура разработки

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

Что проверять:

1. Квалификация разработчиков определяет скорость и качество работы. Соотношение мидлов и сеньоров в команде показывает, кто будет делать архитектурные решения, а кто — рутинные задачи. Если в команде только джуны под управлением одного сеньора — это риск.
2. Текучка кадров — критический показатель стабильности. Высокая текучка означает проблемы: либо с зарплатами, либо с управлением, либо с атмосферой. Всё это отразится на вашем проекте.
3. Практики разработки видны в деталях. Code review, автоматизированное тестирование, CI/CD — это страховка от багов в продакшене. Спросите, как организован процесс: делают ли ревью кода, какое покрытие тестами, как часто деплоят.

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

6. Пост-интеграционная поддержка

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

На что смотреть:

1. Гарантии и доработки. Что будет, когда система упадет из-за архитектурной ошибки вендора? Условия фикса багов и доработок после релиза должны быть зафиксированы в контракте.
2. Контроль ответственности. Должно быть четко расписано, где заканчивается зона ответственности интегратора и начинается зона ваших админов, девопсов или первой линии поддержки.
3. Документация и передача знаний. Подрядчик обязан выгрузить не только исходники, но и актуальную документацию: ADR (архитектурные решения), схемы инфраструктуры, регламенты развертывания.

Юридическая и договорная часть. Условия расторжения договора и стратегия. Кто владеет кодом и данными после завершения проекта. Штрафы за срыв сроков и SLA. Право на аудит кода и инфраструктуры.

7. Безопасность и комплаенс

1. Проверяйте сертификаты и стандарты: ISO 27001 по информационной безопасности, соответствие ФЗ-152 о персональных данных, отраслевые стандарты вроде PCI DSS для платёжных систем.
2. Пентесты, аудит кода на уязвимости, шифрование данных, управление доступами — всё это должно быть в процессе по умолчанию.
3. Убедитесь, что контракт чётко прописывает, кому принадлежит код, как защищаются ваши данные, какие санкции за утечку.

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

8. Реальные кейсы и рекомендации

Самый очевидный и простой способ проверить подрядчика — поискать в открытом доступе упоминания и кейсы в медиа или на специальных площадках. Вот на что смотреть:

1. Соблюдение сроков — классический больной вопрос IT-проектов. Уложились ли в первоначальные оценки? Если были задержки — как объясняли и решали?
2. Работа с изменениями — насколько гибко подрядчик реагировал на новые требования? Были ли конфликты по поводу доп.функционала?
3. Качество коммуникации — как быстро отвечали, насколько понятно объясняли технические вещи, был ли прямой контакт с командой?
4. Пост-поддержка — что происходило после запуска? Быстро ли реагировали на проблемы? Помогли ли с развитием продукта дальше?

9. Финансовая прозрачность

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

На что смотреть:

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

Красные флаги:

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

10. Масштабируемость решения

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

1. Проектирование под рост бизнеса отличает стратегическое мышление от тактического. Хороший интегратор спросит о ваших планах: сколько пользователей сейчас, сколько планируется через год, через три года. И заложит архитектуру с запасом.
2. Постепенное расширение функционала дешевле полной переделки. Модульная архитектура, микросервисы, API-first подход — всё это позволяет добавлять новые возможности без переписывания существующего кода.
3. Управление техническим долгом. Любая разработка накапливает технический долг: быстрые решения, костыли, устаревшие зависимости. Профессионалы планируют рефакторинг, выделяют время на улучшение кода, следят за обновлениями библиотек.
4. Vendor lock-in и технологическая независимость. Хороший интегратор не строит систему так, чтобы вы навсегда зависели от его экспертизы, конкретного облака или проприетарного инструмента. Проверяйте: на каких лицензиях работает стек, можно ли сменить подрядчика без переписывания системы, кто владеет кодом и есть ли возможность развивать продукт силами инхаус-команды.

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

11. Скорость и качество коммуникации

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

1. Время отклика на первый запрос — если на ваше обращение отвечают через неделю — представьте, как будет идти коммуникация в процессе проекта.
2. Интегратор должен задавать вопросы не только про технические требования, но и про то, какую проблему бизнеса решает система. Это показывает стратегическое мышление.
3. Хороший подрядчик не просто делает, что сказали, а предлагает улучшения: как сделать эффективнее, дешевле, быстрее. Это требует глубокого понимания вашего бизнеса.

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

12. Репутация на рынке и стабильность

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

Что оценивать:

1. Время на рынке — один из положительных сигналов, но не гарантия. Компании с опытом 8+ лет, как правило, пережили кризисы, накопили экспертизу и выстроили процессы. Но возраст сам по себе не означает качество: проверяйте кейсы, репутацию и стабильность команды, а не только дату основания. Стартапы могут быть инновационными — просто риски у них другие.
2. Финансовая устойчивость проверяется косвенно: по масштабу проектов, количеству офисов, размеру команды.
3. Участие в профессиональных мероприятиях показывает открытость. Компании, которые выступают на конференциях, пишут статьи, делятся опытом, обычно уверены в своей экспертизе. Это также помогает проверить репутацию через знакомых в индустрии.
4. Партнёрские отношения с крупными вендорами — ещё один индикатор.

Проверка на негатив:

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

Как использовать чек-лист

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

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

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

Что такое Kubernetes

Kubernetes (произносится «кубернетес», сокращённо K8s) — это система оркестрации контейнеров с открытым исходным кодом, которая автоматизирует развёртывание, масштабирование и управление контейнеризированными приложениями. Kubernetes был создан компанией Google на основе внутренней системы Borg и передан в открытый доступ в 2014 году. Сегодня он управляется фондом Cloud Native Computing Foundation (CNCF).

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

- Kubernetes автоматизирует развёртывание, масштабирование и управление контейнерами - Основные сущности: Pod, Node, Cluster, Deployment, Service, Namespace - Архитектура делится на Control Plane (управление) и Worker Nodes (исполнение) - K8s поддерживает самовосстановление: упавший Pod перезапускается автоматически - Kubernetes подходит для больших распределённых систем; для небольших проектов достаточно Docker Compose - Минимальный старт — Minikube или kind на локальной машине за 10 минут - Облачные решения GKE, EKS, AKS берут на себя управление Control Plane - По данным CNCF на 2024 год, Kubernetes используют или оценивают более 84% организаций (CNCF 2023)

Зачем нужен Kubernetes — проблема управления контейнерами в масштабе

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

• Высокая доступность. Если контейнер упал — его нужно перезапустить. Вручную это нереально при сотнях сервисов.
• Балансировка нагрузки. Трафик нужно распределять между несколькими экземплярами одного сервиса.
• Масштабирование. В час пик нужно быстро добавить экземпляры, ночью — убрать, чтобы сэкономить ресурсы.
• Обновления без даунтайма. Rolling update или blue-green деплой требуют координации.
• Управление конфигурацией и секретами. Переменные среды, токены, сертификаты — всё это нужно доставлять в контейнеры безопасно.
• Размещение на серверах. Решить, на каком из 50 серверов запустить очередной контейнер, учитывая доступные ресурсы CPU и памяти.

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

Основные концепции Kubernetes

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

Pod — минимальная единица развёртывания

Pod — это один или несколько контейнеров, которые всегда запускаются вместе на одном узле и разделяют сетевое пространство (один IP-адрес) и тома хранилища. Обычно один Pod = один контейнер с основным приложением. Второй контейнер в Pod используется как sidecar: например, для сбора логов или проксирования трафика.

Node — рабочий узел кластера

Node (узел) — это физическая или виртуальная машина, на которой запускаются Pod-ы. Каждый узел содержит kubelet (агент, который следит за Pod-ами), kube-proxy (сетевые правила) и container runtime (Docker, containerd или CRI-O). В кластере обычно несколько узлов — от 3 до тысяч в крупных системах.

Cluster — совокупность всех узлов

Cluster (кластер) — это набор узлов, управляемых единым Control Plane. Весь Kubernetes работает внутри кластера. Один кластер может объединять сотни серверов в разных датацентрах.

Deployment — управление жизненным циклом приложения

Deployment — это объект, который описывает желаемое состояние для набора Pod-ов: сколько реплик должно работать, какой образ использовать, как выполнять обновления. Deployment следит за тем, чтобы нужное количество Pod-ов всегда было запущено, и управляет rolling-обновлениями.

Service — стабильная точка доступа к Pod-ам

Service — это абстракция, которая предоставляет стабильный IP-адрес и DNS-имя для набора Pod-ов. Pod-ы могут создаваться и удаляться, их IP меняется — Service обеспечивает постоянную точку входа и балансирует нагрузку между ними. Основные типы: ClusterIP (внутри кластера), NodePort (снаружи по порту узла), LoadBalancer (облачный балансировщик).

Namespace — изоляция ресурсов внутри кластера

Namespace — это виртуальный раздел внутри кластера. Позволяет изолировать ресурсы разных команд, проектов или окружений (dev, staging, production) в рамках одного кластера. По умолчанию существуют namespace-ы: default, kube-system, kube-public.

Как работает Kubernetes — архитектура изнутри

Kubernetes состоит из двух уровней: Control Plane (управляющий слой) и Worker Nodes (рабочие узлы). Разберём каждый компонент.

Control Plane — мозг кластера

• API Server (kube-apiserver) — единственная точка входа для всех операций с кластером. Все компоненты общаются только через API Server. kubectl, CI/CD системы, внутренние контроллеры — всё идёт через него. Принимает REST-запросы, валидирует их и сохраняет состояние в etcd.
• etcd — распределённое хранилище типа «ключ-значение», где хранится всё состояние кластера: конфигурации, метаданные Pod-ов, секреты. Это единственное место с состоянием в Kubernetes — если etcd жив, кластер восстановим.
• Scheduler (kube-scheduler) — отвечает за размещение новых Pod-ов на узлах. Учитывает доступные ресурсы узлов, affinity-правила, ограничения и политики. Не запускает Pod-ы сам — только решает, на каком узле их запустить.
• Controller Manager (kube-controller-manager) — набор контроллеров, каждый из которых следит за определённым типом ресурсов. Deployment Controller следит, чтобы работало нужное число реплик. Node Controller реагирует на отказ узлов. ReplicaSet Controller поддерживает заданное количество Pod-ов.

Worker Nodes — исполнители

• kubelet — агент на каждом узле. Получает от API Server описание Pod-ов, которые должны работать на этом узле, запускает их через container runtime и сообщает статус.
• kube-proxy — управляет сетевыми правилами на узле (iptables или IPVS). Обеспечивает работу Service: трафик к виртуальному IP Service перенаправляется на реальные Pod-ы.
• Container Runtime — движок для запуска контейнеров. Kubernetes поддерживает containerd (рекомендован), CRI-O и Docker Engine через специальный shim.

Типичный жизненный цикл запроса: вы применяете YAML через kubectl apply → API Server сохраняет объект в etcd → Scheduler находит подходящий узел → kubelet на том узле получает задание и запускает контейнер → Controller Manager следит, что всё работает как описано.

Kubernetes vs Docker Compose vs Docker Swarm — когда что использовать

Выбор инструмента зависит от масштаба задачи. Не стоит использовать Kubernetes там, где достаточно Docker Compose — это избыточная сложность.

• Docker Compose — идеально для локальной разработки и небольших проектов на одном сервере. Простой синтаксис, быстрый старт, нет оверхеда. Не умеет автоматически восстанавливаться при отказе хоста, не масштабируется горизонтально.
• Docker Swarm — встроенная кластеризация Docker. Проще Kubernetes, подходит для небольших кластеров (2–10 серверов), когда не нужны продвинутые возможности. Экосистема значительно меньше, развитие заморожено.
• Kubernetes — для продакшен-систем с требованиями к высокой доступности, горизонтальному масштабированию, сложным сетевым политикам и богатой экосистеме. Оправдан при наличии хотя бы 3–5 сервисов и команды DevOps.

Если вы можете управлять системой через Docker Compose — используйте Docker Compose. Kubernetes стоит выбирать, когда боль от ручного управления стала больше, чем сложность K8s.

Ключевые отличия в цифрах: Docker Compose запускается за секунды, Kubernetes требует минимум 3 узла для продакшена и несколько часов на начальную настройку. Зато Kubernetes поддерживает до 5000 узлов и 150 000 Pod-ов в одном кластере.

Как начать работу с Kubernetes

Для изучения и разработки не нужен облачный кластер. Есть несколько способов запустить Kubernetes локально.

Minikube — классический локальный кластер

Minikube запускает однонодовый кластер Kubernetes в виртуальной машине или контейнере. Поддерживает macOS, Linux и Windows. Встроен dashboard, поддержка нескольких профилей и дополнений.

kind — Kubernetes в Docker

kind (Kubernetes IN Docker) запускает узлы кластера как Docker-контейнеры. Быстрее Minikube, идеален для CI/CD и тестирования, поддерживает многонодовые кластеры.

Облачные управляемые сервисы

Для продакшена большинство команд выбирает управляемый Kubernetes — облачный провайдер берёт на себя Control Plane, обновления и резервирование etcd.

• GKE (Google Kubernetes Engine) — оригинальный управляемый K8s от Google. Лучшая интеграция с экосистемой Google Cloud, автопилот-режим для полностью управляемой инфраструктуры.
• EKS (Amazon Elastic Kubernetes Service) — Kubernetes на AWS. Глубокая интеграция с сервисами AWS: IAM, ALB, EBS. Самый популярный выбор среди enterprise-компаний.
• AKS (Azure Kubernetes Service) — K8s на Microsoft Azure. Хорошая интеграция с Azure Active Directory, бесплатный Control Plane.
• Yandex Managed Service for Kubernetes — российский вариант с серверами в РФ, интеграция с Yandex Cloud.

Помимо самого кластера, при работе с REST API сервисов внутри Kubernetes понадобится настроить Ingress-контроллер (nginx, Traefik) для маршрутизации внешних HTTP-запросов к нужным Service-ам.

Выводы

Kubernetes — это де-факто стандарт оркестрации контейнеров в 2024–2025 годах. По данным CNCF Annual Survey, более 84% компаний используют или оценивают K8s, а рынок контейнерной оркестрации продолжает расти двузначными темпами.

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

Путь в Kubernetes начинается с понимания контейнеров, затем — знакомство с kubectl и Minikube, первые Deployment-ы и Service-ы, потом — изучение Ingress, ConfigMap, Secret, HorizontalPodAutoscaler. Это путь в несколько месяцев, но он открывает доступ к одной из самых востребованных технологий в DevOps.

Изучаете облачные технологии? Прочитайте наши статьи о микросервисной архитектуре и Docker — они помогут выстроить полную картину современной облачной разработки. Автоматизировать деплой в Kubernetes поможет CI/CD: пайплайн собирает образ, прогоняет тесты и автоматически деплоит в кластер.

Если хотите собрать Kubernetes не как отдельный страшный инструмент, а как часть цельного пути, посмотрите план обучения DevOps-инженера. Там видно, почему Kubernetes появляется после Docker, CI/CD и инфраструктуры, а не вместо них.

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

— Микросервисы — это архитектура из независимых сервисов, каждый из которых решает одну задачу и развёртывается отдельно

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

— Главные недостатки: сложность отладки, сетевые задержки, необходимость оркестрации

— Переходить с монолита стоит при команде от 5-8 разработчиков и понятных границах доменов

— Ключевые технологии: Docker, Kubernetes, API Gateway, брокеры сообщений (Kafka, RabbitMQ)

Монолит vs микросервисы — в чём разница

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

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

Основные различия:

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

По данным O'Reilly, к 2020 году 61% компаний, внедривших микросервисы, использовали их больше года, а 28% — больше трёх лет.

Преимущества микросервисной архитектуры

1. Независимый деплой. Каждая команда деплоит свой сервис без координации с другими. По данным отчёта DORA, это один из ключевых факторов высокой частоты релизов — лидеры индустрии деплоят изменения несколько раз в день
2. Точечное масштабирование. Нагрузка на каталог товаров выросла в 10 раз? Масштабируем только его, не трогая сервис аналитики
3. Технологическая свобода. Сервис рекомендаций можно написать на Python с ML-библиотеками, а высоконагруженный API — на Go или Rust
4. Изоляция сбоев. Если сервис уведомлений упал, пользователь всё ещё может оформить заказ. Паттерн Circuit Breaker (автоматический выключатель) предотвращает каскадные отказы
5. Гибкость команд. Каждый сервис — зона ответственности одной команды (2-8 человек). Это соответствует «правилу двух пицц» Джеффа Безоса
6. Упрощённый рефакторинг. Переписать один сервис на 2000 строк проще и безопаснее, чем рефакторить монолит на 200 000 строк

Недостатки и когда НЕ стоит использовать микросервисы

Микросервисы — не серебряная пуля. Вот реальные проблемы, с которыми сталкиваются команды:

• Сетевая сложность. Вместо вызовов функций — HTTP-запросы и очереди сообщений. Это добавляет задержки (latency), а сеть может быть ненадёжной
• Распределённые транзакции. Обеспечить атомарность операции, затрагивающей 3 сервиса, — нетривиальная задача. Паттерн Saga решает это, но добавляет сложность
• Отладка и мониторинг. Баг, затрагивающий цепочку из 5 сервисов, искать сложнее, чем в одном процессе. Нужны распределённая трассировка (Jaeger, Zipkin) и централизованные логи
• Дупликация данных. Каждый сервис имеет свою БД — данные неизбежно дублируются, и обеспечивать их согласованность (eventual consistency) сложно
• Операционные затраты. Вместо одного сервера — десятки контейнеров, сетевые политики, секреты, CI/CD-пайплайны для каждого сервиса
• Порог входа. Команде нужно знать Docker, оркестрацию, паттерны распределённых систем — кривая обучения крутая

Когда НЕ стоит переходить на микросервисы:

• Команда меньше 5 человек — overhead превысит выгоду
• Проект на ранней стадии, когда границы доменов ещё не ясны
• Нет DevOps-культуры и опыта с контейнерами
• Монолит справляется с текущей и прогнозируемой нагрузкой

Если вы не можете построить хорошо структурированный монолит, что заставляет вас думать, что микросервисы — ответ?

Технологии микросервисной архитектуры

Микросервисы опираются на экосистему инструментов. Разберём ключевые.

Docker — контейнеризация

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

Kubernetes — оркестрация

Kubernetes (K8s) управляет кластером контейнеров: автоматически перезапускает упавшие сервисы, балансирует нагрузку, масштабирует реплики. Для небольших проектов можно обойтись Docker Compose, но для продакшена с десятками сервисов Kubernetes стал стандартом де-факто.

API Gateway — единая точка входа

API Gateway (например, Kong, NGINX или облачные решения) принимает все внешние запросы и маршрутизирует их к нужным сервисам. Он также берёт на себя авторизацию, rate limiting и агрегацию ответов от нескольких сервисов.

Брокеры сообщений — асинхронное взаимодействие

Apache Kafka и RabbitMQ обеспечивают асинхронную коммуникацию между сервисами. Вместо прямых HTTP-вызовов сервис публикует событие в очередь, а заинтересованные сервисы его обрабатывают. Это снижает связанность (coupling) и повышает отказоустойчивость.

Дополнительные инструменты, которые часто используются вместе:

• Service Mesh (Istio, Linkerd) — управление трафиком между сервисами, mTLS-шифрование
• Распределённая трассировка (Jaeger, Zipkin) — отслеживание запроса через цепочку сервисов
• Централизованные логи (ELK Stack, Grafana Loki) — сбор логов со всех сервисов в одном месте
• Feature Flags (Unleash, LaunchDarkly) — постепенное включение функций без передеплоя

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

Заключение

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

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

Для запуска микросервисов в продакшене нужно освоить всю связку инструментов: Docker обеспечивает упаковку и изоляцию каждого сервиса, Kubernetes — оркестрацию в кластере, а REST API определяет, как сервисы взаимодействуют между собой.

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

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

1. HTTP/1.1 (REST)

Передача изображений в виде текстовых чанков (например, base64) приводит к значительным накладным расходам: бинарные данные увеличиваются на ~33% при кодировании в Base64, а текстовый формат неэффективен для больших объёмов.

2. WebSocket

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

3. gRPC использует:

Protocol Buffers — строго типизированный, компактный бинарный формат,

HTTP/2 — мультиплексирование, потоки, сжатие заголовков,

Client-Streaming — идеально подходит для передачи одного большого файла (например, изображения) в одном вызове.

I. Постановка задачи

Сервис должен:

Принимать изображение и параметры (format, compress, watermark, width[], height[]),

Сохранять оригинал с уникальным путём (./download/YYYY/MM/DD/UUID/img/...),

Накладывать водяной знак,

Генерировать версии заданных размеров,

Сохранять полученные изображения,

Возвращать список путей.

Пример:

Запрос с width = [1920, 1280], height = [1080, 720], format = "webp", watermark = "logo.png"

→ Сервис вернёт два пути:

./download/2026/02/08/abc123/img/abc123_1920x1080.webp

./download/2026/02/08/abc124/img/abc124_1280x720.webp

II. Архитектура приложения

Обработка происходит в строгом порядке:

1.Приём → 2. Сохранение исходного файла→ 3. Сжатие → 4. Watermark → 5. Resize → 6. Конвертация → 7. Ответ.

Структура хранения:

./download/2026/02/08/a1b2c3d4-.../img/

├── a1b2c3d4-....jpg ← оригинал

├── a1b2c3d4-..._800x600.png

└── a1b2c3d4-..._1024x768.png

Необходимые инструменты:

Для работы с WebP мы используем библиотеку golang.org/x/image/webp , а исходные утилиты можно скачать на официальной странице Google.

Для генерации protobuff нам нужен protoc-gen-go

protoc-gen-go-grpc

Позволяет генерировать определения сервисов Go для буфера протокола, заданного нашим .proto файлом protoc-gen-go-grpc

Также для работы webp нам потребуется работа с CGO, которую мы рассмотрим отдельно.

III. Реализация proto файла

Для начала работы опишем наш proto файл. Это будет сервис с единственным rpc который будет обрабатывать картинки пользователей.

./proto/image.proto

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

V. Реализация основных функций

1. Создание сервера

1.1 Генерация go файлов из .proto: Сгенерируем файлы для реализации сервера с помощью protoc:

У нас должно получиться 2 файла image.pb.go и image_grpc.pb.go в директории proto

1.2 Реализуем конструктор сервера и interceptor (аналог middleware в grpc) восстановления после паники:

./internal/app/server.go

Теперь реализуем функцию запуска нашего grpc сервера:

Мы создали наш grpc сервер, но пока нет никакой реализации ImageServiceServer который сгенерировал нам protoc, это просто интерфейс который нам и нужно реализовать.

2. Реализация ImageServiceServer

Нам необходимо создать структуру ImageServer которая реализует интерфейс ImageServiceServer с его методом DownloadImage, также создадим конструктор для него :

./internal/app/image.go

Нам осталось реализовать ключевые функции для нашего сервиса, а именно: saveSourceFiles: отвечает за сохранение исходных файлов и их сжатие, watermark: наложение ватермарки , resizeAndSave: изменения размера картинки и его конвертация в нужный формат изображения.

3. Сохранение оригинала

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

./internal/app/save.go

Для ускорения нашего процесса обработки все этапы мы будем выполнять конкурентно с помощью горутин.

4. Водяной знак

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

./internal/app/watermark.go

Остаётся только изменить размер и сохранить в нужном формате наши обработанные изображения.

5. Resize и конвертация.

Теперь создадим файл resize.go и реализуем функцию изменения размера изображении и сохранения в нужном нам формате:

./internal/app/resize.go

Теперь реализуем main.go в котором создадим и вызовем наш сервис обработки изображений.

./internal/cmd/main.go

VI. CGO

Наше приложение полностью готово, но теперь нужно удостовериться, что у нас работает поддержка CGO. Для начала нужно убедиться что мы скачали и установили webp по ссылке [официальная страница Google](https://developers.google.com/speed/webp/download?hl=ru). Далее нам необходимо установить GCC, без него go не может распознать импортированные C файлы, скачиваем и устанавливаем [официальные зеркала GNU](https://gcc.gnu.org/mirrors.html). Теперь нужно проверить, что переменная CGO_ENABLED=1, для этого используем команду go env и проверяем, если она равна 0, то используем go set CGO_ENABLED=1 и проверяем ,что она применилась, если нет то перезагружаем нашу систему и проверяем. Теперь мы готовы собрать наше приложение и приступить к тестированию.

VII. Тестирование и оптимизация

Тестирование с Bruno

Здесь вы можете тестировать удобными для вас средствами такими как Postman, Bruno, Yaak, grpccurl и т.д., главное чтобы они поддерживали тестирование grpc методов. Рассмотрим пример с Bruno:

1.Конвертируйте изображение в Base64: Image to Base64 Converter

2.Откройте Bruno создайте новый grpc запрос

3. Выбираем метод grpc:

4.Уберите ползунок с reflection и укажите .proto файл

5.Выберите метод DownloadImage

6.В поле message заполните поле в соответствии с параметрами, например:

В поле image нужно скопировать текстовую строку ,что идёт после запятой, сгенерированную на шаге 1

7.Далее нужно запустить наше приложение и подключиться к нему с помощью кнопки →

В случае успеха должен появиться статус streaming

8.Отправляем наше сообщение/сообщения нажав на кнопку "Send message" один или несколько раз и завершаем нашу передачу сообщений с помощью кнопки → (если не нажать то приложение будет ожидать приёма сообщений). Результатом будет возврат путей наших обработанных сообщений

VIII. Заключение

Подведем итоги, мы создали сервис который:

Использует gRPC для эффективной передачи данных,

Поддерживает WebP, JPEG, PNG,

Безопасен в конкурентной среде,

Можно легко масштабировать.

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

Исходный код доступен по ссылке

Спасибо за внимание!

Почта Банк имеет широкую разветвленную сеть и работает в 83 регионах нашей страны, в том числе и в отделениях Почты России. У банка несколько миллионов клиентов, которые создают высокую нагрузку на цифровые каналы обслуживания, прежде всего на систему дистанционного банковского обслуживания (ДБО).

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

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

Сейчас система выдерживает 120 тысяч одновременных сеансов, позволяет добавлять новые сервисы не более чем за два часа и обеспечивает управление 30+ кластерами.

Задача: дать банку инструмент для управления десятками кластеров и простого масштабирования

До старта проекта банку необходимо было решить следующие задачи:

• сократить релизные циклы;
• ускорить обновления;
• автоматизировать масштабирование;
• импортозаместить инфраструктуру и ключевые компоненты ДБО;
• увеличить скорость вывода новых сервисов.

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

В основе решения — контейнерная платформа «Штурвал», позволяющая централизованно управлять Kubernetes-кластерами, обеспечивать высокий уровень отказоустойчивости, безопасности и масштабируемости.

«Лаборатория Числитель», разработчик платформы «Штурвал», реализовала глубокую интеграцию с системой виртуализации zVirt, поддержку RedOS и встроенные механизмы безопасности. Платформа обеспечивает централизованное управление множеством кластеров из единого окна, автоматическое масштабирование и высокий уровень отказоустойчивости, что позволяет инфраструктуре расти вместе с цифровыми сервисами банка.

Параметры проекта

• Команда: 70 человек (со стороны банка и «Лаборатории Числитель»)
• Сроки: один год, проект завершился в Q3 2024 г.
• Масштаб клиента: несколько миллионов пользователей, 69% из которых используют онлайн-банкинг
• Инфраструктура: 6 продакшн-кластеров Kubernetes для ДБО, более 500 виртуальных машин, 2 ЦОДа
• Результаты: система выдерживает до 120 тысяч одновременных сеансов, на старте проекта было развернуто 3 кластера, теперь — больше 30

Почему банк выбрал «Штурвал»

Почта Банк сравнил шесть решений, включая Deckhouse Kubernetes Platform, OpenShift, Rancher, «ванильный» Kubernetes и другие. На «Штурвале» остановились из-за ряда причин:

• Архитектура для enterprise. Централизованное управление, простое масштабирование, отказоустойчивость компонентов доступных «из коробки».
• Готовые интеграции. «Штурвал» работал как с тем ПО, которое банк уже использовал, так и с тем, которое только собирался внедрить.
• Гибкие права доступа. Можно сегментировать доступы между командами разработки, инфраструктуры, DevOps и ИБ на уровне всей платформы.
• Высокий уровень безопасности. Механизмы информационной безопасности уже встроены в платформу.
• Масштабирование вместе с бизнесом. Платформа управляет десятками кластеров из одного окна. Новый кластер разворачивается за 15 минут.

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

• Скорость внедрения сервисов

Теперь на запуск нового сервиса требуется не более двух часов. Новый кластер можно создать за 15 минут, поэтому time-to-market сильно сократился.

• Нулевые простои

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

• Нагрузка на команды уменьшилась в пять раз

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

• Система устойчива к высоким нагрузкам

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

• Полная независимость от западных вендоров

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

Сложности проекта

🔴 Проблема: внешние балансировщики с постоянно меняющимися адресами

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

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

✅ Решение: автоматическая синхронизация состояния кластера

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

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

🔴 Проблема: недостаточная отказоустойчивость на уровне виртуализации

Банк требовал размещения управляющих компонентов кластеров на разных физических хостах, чтобы сбой одной части инфраструктуры не приводил к остановке критичных сервисов. Но в системе zVirt отсутствовали готовые механизмы для автоматического обеспечения такого распределения.

✅ Решение: разработка компонента, контролирующего размещение управляющих серверов

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

🔴 Проблема: инсталляционная настройка десятков кластеров

После запуска платформы нужно было настроить большое количество кластеров.

✅ Решение: паттерн Apps-of-Apps

Команда использовала паттерн Apps-of-Apps для модуля непрерывной доставки приложений. Банк получил управляемую модель, где изменения вносятся быстро, предсказуемо и с контролируемыми рисками.

Не лобовая замена, а технологический апгрейд

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

Дорожная карта проекта

3Q 2023: подготовка — уточнение ТЗ, формирование команды, разработка план-графика.

4Q 2023: разработка документации, пилотное развёртывание «Штурвала», перенос 10 пилотных микросервисов на тестовый кластер.

1Q 2024: масштабирование кластера, подготовка платформы и развёртывание HA-кластера.

2Q 2024: перенос пилотных микросервисов в продакшен, старт доработки остальных 150 микросервисов.

3Q 2024: развёртывание новой платформы на RedOS, перенос пилотных сервисов.

Реклама. ООО «Лаборатория Числитель», ИНН 9731042193, erid: 2W5zFHR4LV7

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

«Гравитон» за 17 месяцев сделал систему мониторинга без агентов. Она работает через обычные сетевые протоколы, шлёт уведомления в Telegram и показывает всё в реальном времени. Команда из 7 человек написала всё с нуля и выпустила бесплатно.

Задача: мониторить всю инфраструктуру без установки агентов на каждый сервер

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

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

Параметры проекта

• Срок разработки: март 2024 — август 2025 (17 месяцев)
• Команда: 7 человек
• Статус: продукт на рынке 5 месяцев, предоставляется бесплатно на первый год использования
• Первый проект: мониторинг нескольких сотен моноблоков
• Интерес рынка: несколько десятков запросов на тестирование с момента запуска

Поддерживаемое оборудование: виртуальные машины, серверы, системы хранения данных, клиентские устройства (персональные компьютеры, моноблоки, многофункциональные устройства «Гравитон»).

Архитектура: микросервисы и протоколы без агентов

Систему собрали из микросервисов — каждый отвечает за свою часть:

Устройства в сети

→ Подключение через WebSocket, Redfish, IPMI, SNMP, Prometheus

→ Сервисы, которые собирают и обрабатывают данные

→ SQL для настроек, Prometheus для метрик по времени

→ PromQL для правил уведомлений

→ Веб-интерфейс с графиками

→ Уведомления в Telegram

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

Пять главных фишек

1. Всё в реальном времени через WebSocket

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

Чем быстрее узнал о проблеме — тем быстрее починил.

2. Всё написано с нуля

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

3. Никаких агентов

Система использует протоколы, которые уже есть в оборудовании. Redfish для современных серверов, IPMI для управления на аппаратном уровне, SNMP для сетевых устройств, Prometheus для Linux-серверов. Не нужно ничего устанавливать, настраивать, обновлять на каждой машине.

4. Интеграция с Telegram для уведомлений

Вместо email-рассылок или SMS, которые легко пропустить, система отправляет уведомления о проблемах прямо в Telegram. Администратор получает сообщение на телефон: «Температура процессора сервера srv-db-01 достигла 85°C» или «Диск /dev/sda на сервере srv-web-03 заполнен на 95%». Можно настроить отдельные каналы для разных типов событий или разных команд.

5. PromQL для гибких условий мониторинга

Для составления выражений, которые запускают уведомления, используется PromQL — язык запросов Prometheus. Администратор может создавать сложные условия: «уведомить, если загрузка процессора выше 80% в течение 5 минут» или «предупредить, если свободное место на диске меньше 10% и скорость его уменьшения больше 1 ГБ в час». Это не просто пороговые значения, а гибкие правила с учётом трендов и контекста.

Главная трудность: CORS и удалённое управление KVM

🔴 Проблема: запуск KVM через браузер

KVM (клавиатура, видео, мышь) — технология удалённого управления сервером на уровне «железа», как будто вы сидите перед монитором с клавиатурой. Запуск инструмента KVM из веб-интерфейса системы мониторинга столкнулся со сложностями из-за ограничений CORS (Cross-Origin Resource Sharing) — механизма безопасности браузеров, который блокирует запросы между разными доменами.

✅ Решение: корректная авторизация, поддерживаемая сервером

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

Результаты и конкуренция на рынке

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

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

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

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

Команда «Гравитон» развивает продукт по семи направлениям.

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

Реклама. ООО «Ревотех», ИНН 9731071780, erid: 2W5zFJx4cjB

Всем привет! Меня зовут Вадим, я техлид команды финансовой инфраструктуры в Timeweb Cloud. Сегодня я хочу рассказать об инструменте, который лежит в основе наших Python-микросервисов. Это пилотный пост-знакомство: без долгих историй “как мы дошли до жизни такой” (большая статья с архитектурными кейсами уже готовится), а чисто по делу.

Если вы пишете сложные распределенные системы и устали каждый раз заново изобретать велосипеды для Transactional Outbox, Sagas или Mediator — этот пост сэкономит вам кучу времени.

Представляю python-cqrs — фреймворк для реализации паттернов CQRS и Event-Driven Architecture. Он вырос из форка проекта diator, но превратился в самостоятельный комбайн для построения надежных систем.

Killer Features

Честный CQS и Mediator (База)

По названию может показаться, что пакет исключительно про сложный CQRS и Event Sourcing. На самом деле, название родилось исторически: мы искали инструмент именно для ES-сервиса. Но в итоге создали универсальную реализацию паттернов Mediator и CQS (Command Query Separation).

Суть проста: мы разделяем операции изменения состояния (Команды) и чтения данных (Запросы). Это позволяет изолировать чистую бизнес-логику от инфраструктуры (HTTP, Kafka, CLI). Хендлер ничего не знает о том, как пришел запрос, он просто выполняет задачу.

Распределенные транзакции (Saga Pattern)

Библиотека реализует Оркестрированные Саги с сохранением состояния:

1. Автоматическая компенсация: Если шаг падает, фреймворк автоматически запускает логику отката (compensate) в обратном порядке для всех уже выполненных шагов.
2. Recovery Mechanism: Если под (pod) сервиса был убит (OOM, редеплой) посередине транзакции, при рестарте механизм восстановления вычитает состояние из SagaStorage и продолжит выполнение с прерванного места (или продолжит компенсацию).
3. SagaStorage & SagaLog: Состояние саги персистентно. Каждый шаг (успех, ошибка, начало компенсации) пишется в SagaLog. Это позволяет не терять контекст транзакции даже при падении всего кластера.
4. Конкурентность: В SagaMediator встроена защита от гонок (race conditions). Даже если несколько инстансов сервиса попытаются обработать события одной саги одновременно, механизм блокировок (на уровне хранилища) гарантирует последовательное выполнение шагов.

Transactional Outbox

Классическая проблема “Dual Write”: мы сохранили сущность в БД, но упали перед отправкой события в Kafka. В итоге — рассинхрон. python-cqrs реализует Transactional Outbox, гарантируя, что события сохраняются в той же транзакции БД, что и бизнес-данные.

Streaming Request Handlers

Нужно обработать большой файл или вернуть прогресс-бар пользователю? StreamingRequestMediator позволяет отдавать данные по кускам (yield), идеально ложась на Server-Sent Events (SSE) в FastAPI.

Разделение Domain Events и Notification Events

В python-cqrs мы четко разделяем события на два типа. Это помогает не смешивать внутреннюю логику модуля с публичным контрактом сервиса.

Domain Event (Внутренние)

Это события, которые происходят внутри вашего bounded context. Они нужны, чтобы снизить зацепление (coupling) между компонентами одной системы.

• Как работают: Хендлер возвращает их через свойство events. Mediator перехватывает их и тут же (или в фоне) рассылает локальным подписчикам.
• Пример: “Заказ создан” -> (внутри того же сервиса) -> “Отправить email”, “Обновить аналитику”.
• ⚠️ Важно: Этот механизм работает In-Memory и не дает гарантий доставки (at-most-once). Если процесс упадет во время обработки доменного события, оно (и его сайд-эффекты) будет потеряно.

Notification Events (Публичные / Интеграционные)

Это события, которые улетают наружу — в Kafka/RabbitMQ для других микросервисов.

• Как работают: Это обертки (NotificationEvent), которые содержат топик и пейлоад. Именно их мы сохраняем в Transactional Outbox, чтобы гарантировать доставку.
• EventMediator: Для их обработки на стороне потребителя (Consumer) есть отдельный EventMediator, который умеет маршрутизировать входящие сообщения из брокера.

Почему это круто? Вы можете менять внутреннюю структуру доменных событий как угодно, не ломая контракты с внешними сервисами. Публичный API (Notification Events) стабилен, внутренняя кухня (Domain Events) гибка.

Бесшовная интеграция (FastAPI & FastStream)

python-cqrs проектировался так, чтобы быть “клеем” между вашей бизнес-логикой и внешним миром. Интеграция происходит максимально нативно через Dependency Injection и встроенные bootstrap-утилиты.

FastAPI (HTTP API)

Вам не нужно вручную собирать медиатор. Используйте cqrs.requests.bootstrap для фабрики и fastapi.Depends для внедрения.

FastStream (Kafka Consumer)

Для обработки входящих Notification-событий из Kafka используем cqrs.events.bootstrap для создания EventMediator.

Итог: Ваш Presentation Layer занимается только транспортом. Вся конфигурация собрана в bootstrap, а логика — в Handlers.

Другие фичи

1. Modern Python: Полная типизация, поддержка Pydantic v2.
2. Dependency Injection: “First-class citizen” поддержка популярных DI-фреймворков. Есть готовые интеграции как для легковесного di, так и для мощного dependency-injector. Вы просто объявляете зависимости в init хендлера, и они “прилетают” автоматически.
3. Event-Driven & Protobuf:
   – Нативная поддержка Kafka (используем aiokafka под капотом, отлично дружит с faststream).
   – Поддержка Protobuf для Notification-событий “из коробки” — критично для высоконагруженных систем, где важен размер сообщения.
4. Parallel Event Processing: Хотите обрабатывать 10 доменных событий одной команды параллельно, но не положить базу? Просто настройте max_concurrent_event_handlers в медиаторе.
5. Chain of Responsibility: Цепочки обработчиков с возможностью построения диаграмм.
6. Mermaid Visualizations: Автоматическая генерация диаграмм для Saga и Chain of Responsibility. Планируем расширить это на все типы обработчиков, чтобы документация всегда соответствовала коду.
7. Bootstrap Tools: Набор утилит для быстрой настройки Presentation Layer (FastAPI, CLI). Не нужно писать тонны бойлерплейта, чтобы собрать медиатор, мапперы и DI-контейнер воедино — есть удобные bootstrap-функции.

Планы на будущее (Roadmap)

Мы активно работаем над тем, чтобы библиотека следовала всем стандартам для HighLoad на Python. Вот ближайшие наши планы

Архитектура и Гибкость

• Отвязка от Pydantic: Сделать ядро библиотеки агностиком к моделям данных. Поддержка dataclasses, attrs, msgspec или простых TypedDict для тех, кому важна максимальная производительность и минимум зависимостей.

Observability

• OpenTelemetry: Автоматический проброс trace_id сквозь цепочку Command → Saga → Event.
• Метрики: Middleware для сбора Prometheus-метрик (длительность хендлеров, счетчики ошибок, лаг саг).

Resiliency

• Idempotency Middleware: Механизм дедупликации сообщений (Redis/DB) для безопасной обработки “at-least-once”.
• Circuit Breaker: Защита от каскадных сбоев внешних сервисов.
• Unified Transport: Единый интерфейс для переключения между RabbitMQ, Redis Streams и NATS.

Developer Experience

• Testing Harness: Удобный API для написания интеграционных тестов бизнес-флоу.
• In-Memory Transport: Возможность прогонять тесты “Команда -> Событие -> Сага” в памяти без поднятия Docker-контейнеров.

Что дальше?

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

1. Как мы переписывали монолит на микросервисы и почему стандартные подходы не сработали.
2. Реальные кейсы использования TransactionOutbox и Саг в продакшене (где это спасло деньги).
3. Почему мы отказались от готовых решений и начали пилить своё.

А пока — буду рад любым issues, звездам на GitHub и конструктивной критике в комментариях. Если вы пишете микросервисы на Python, используете Outbox-ы, CQRS или Саги в Python — расскажите, какие боли испытываете вы? Возможно, мы сможем решить их вместе.

Ссылки

1. GitHub

2. PyPi

3. Документация

4. DeepWiki

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

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

Архитектура — не про красивые диаграммы. Это про системы, которые не падают, когда приложение набирает 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 прошли этот путь. Они не избежали ошибок, но выстроили процессы для развития сложных систем. Микросервисы — это эволюция архитектуры и команды. Начинайте с малого, не бойтесь менять решения. Главный критерий успеха — скорость доставки ценности пользователям без поломок продакшена. Если этот показатель растет — вы на правильном пути.

WebAssembly в браузере: как всё начиналось

Прежде чем говорить о настоящем и будущем WebAssembly, вспомним, с чего он начинался. Технология создавалась исключительно для работы в браузере. WebAssembly использовался (и используется сейчас): для оптимизации производительности, миграции legacy-нативных приложений, запуска кода на языках, отличных от JavaScript.

Ярче всего успех этого подхода демонстрирует Figma — популярный редактор для дизайнеров интерфейсов. Для многих стало неожиданностью, что редактор Figma, будучи веб-приложением, написан на C++.

Александр Коротаев, фронтенд-разработчик, автор ТГ канала «Трудно быть Коротаевым»:

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

До WebAssembly разработчики Figma использовали технологию asm.js — предшественника WASM. Специальный компилятор преобразовывал (транспилировал) код C++ в высокооптимизированный JavaScript, который браузерные движки могли выполнять с близкой к нативной производительностью. У этого подхода были недостатки: большой размер получаемого кода и затраты на его парсинг и компиляцию в браузере.

Переход на WebAssembly стал переломным моментом. Поскольку WASM — это бинарный машинно-ориентированный формат, он гораздо компактнее и требует меньше ресурсов для обработки браузером. В результате миграции с asm.js на WebAssembly, Figma получила трёхкратный прирост производительности.

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

Почему WebAssembly выходит за пределы браузера

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

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

Главным катализатором этого процесса стал стандарт WASI (WebAssembly System Interface), разработанный при участии Mozilla, Fastly и других компаний. WASI предоставляет стандартизированный интерфейс, где WebAssembly-модули взаимодействуют с операционной системой и решают проблему переносимости между различными платформами.

Александр Коротаев, фронтенд-разработчик, автор ТГ канала «Трудно быть Коротаевым»:

Открытая «кроссплатформенная» обертка WASI — это довольно большой прорыв в разработке, так как в текущем состоянии все современные продукты, выпускающиеся для разных ОС с одной кодовой базой, имеют большие, подчас legacy модули совместимости, или же запускаются внутри особых песочниц, сильно увеличивающих размер бандла. Например, браузерный движок Electron или React Native.

Как WebAssembly работает вне браузера

Вне браузера WebAssembly исполняется в специальных средах выполнения (runtimes), которые взаимодействуют с операционной системой через WASI. Известные примеры — Wasmtime от Mozilla, Lucet от Fastly и Wasmer.

Эти среды выполняют роль «концептуальной операционной системы», предоставляют модулям WebAssembly стандартизированный доступ к системным ресурсам: файлам, сети, случайным числам и другим функциям.

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

Безопасность как фундаментальное преимущество

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

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

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

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

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

Александр Коротаев, Фронтенд-разработчик, автор ТГ канала «Трудно быть Коротаевым»:

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

Серверные применения WebAssembly

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

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

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

Кейс: компания Fastly использует WebAssembly для исполнения пользовательского кода на серверах. Их технический директор Тайлер МакМаллен отмечает: «Мы рассматриваем WebAssembly как платформу для быстрого и безопасного кода в облаке на границе сети».

Безопасные расширения приложений

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

Веб-сервер Angie использует WASM для безопасности пользовательских модулей. Это решает проблему совместимости, характерную для традиционных модулей, написанных на C.

Экономическая эффективность таких вариантов становится решающим фактором. По данным на 2025 год, глобальный рынок больших языковых моделей (LLM), чьи backend-системы часто используют микросервисные архитектуры, демонстрирует колоссальный рост. Прогнозируется, что к 2033 году он достигнет $140,8 млрд.

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

Александр Коротаев, Фронтенд-разработчик, автор ТГ канала «Трудно быть Коротаевым»:

Здесь все закономерно: бизнес всегда выбирал решения, где можно было написать код один раз и поставить его сразу на несколько платформ. Даже если сами решения сырые и небезопасные, дешевле было увеличить поддержку пользователей и настроить аудит безопасности, чем реализовать фичу для каждой платформы отдельно. Так на рынок вышли Python, Node.js, React Native, стремительно обгоняя конкурентов за счет скорости разработки.

WebAssembly в embedded-системах

WebAssembly успешно работает на серверах, но главные изменения происходят во встроенных системах. В IoT всегда была проблема совместимости: разные процессоры, операционные системы и периферийные устройства.

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

Удаленные интерфейсы и централизованный мониторинг

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

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

Александр Коротаев, Фронтенд-разработчик, автор ТГ канала «Трудно быть Коротаевым»:

А это, пожалуй, самая продающая фича: обычно у компаний, которые выходят на рынок со своими железками, базами данных и прочими продуктами, все продажи буквально построены на том, что программисты у клиента знают, как это быстро встроить. Так, бизнес готов платить деньги. Обычно у них есть проблемы с API для разных языков программирования, ОС и девайсов: либо хорошо все в JS, а в мобилках не заводится, либо наоборот. А то и вообще: стоит забросить поддержку платформы хоть на полгода, сразу всёперестает работать. Потому поставлять модуль для WASI должно быть дёшево, при этом потенциально можно закрыть даже платформы будущего. Это инновация сродни изобретению стандарта USB.

Прототипирование и сотрудничество

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

Компания Qt использует этот подход в Qt Design Viewer, позволяя разработчикам делиться интерактивными дизайнами, созданными в Qt Design Studio, с коллегами по всему миру.

Примеры внедрения: история ByteFog

Компания Inetra из Новосибирска разработала технологию peer-to-peer для доставки видео ByteFog. Система работает на множестве платформ: Windows, Linux, Android, iOS, Web и Tizen.

Изначально веб-версия использовала Netscape Plugin API, но когда основные браузеры прекратили поддержку этой технологии в 2015 году, компания осталась без веб-версии на два года. Поэтому в 2017 году они обратились к WebAssembly.

Используя компилятор Emscripten, разработчики перенесли существующее C++-приложение в браузер. Главной сложностью было разграничить транспортный слой и бизнес-логику через интерфейсы. Основной канал доставки видео заменили на AJAX, а P2P-слой — на WebRTC.

Результат компиляции — двоичный.wasm-файл и «клеевой код» на JavaScript, взаимодействующий с браузерными API. Это позволило запускать сложную P2P-систему Peers.TV напрямую в браузере без плагинов.

Fastly Terrarium: экспериментальная платформа для WebAssembly-приложений

В 2021 году инженеры Fastly выпустили Terrarium — экспериментальную платформу для запуска WebAssembly-модулей на периферийных устройствах (edge devices), над которой работали несколько лет. Сейчас проект всё ещё в демо-версии.

Terrarium показывает, как можно запускать пользовательский код в изолированных средах с минимальной задержкой. Платформа использует рантайм Lucet, разработанный инженерами Fastly, и поддерживает компиляцию из Rust, C++ и AssemblyScript.

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

По данным тестирования, время запуска модулей составляет около 50 микросекунд, а потребление памяти измеряется килобайтами на инстанс. Такие показатели достигаются за счёт изоляции на уровне инструкций, а не процессов.

Хотя Terrarium не стал коммерческим продуктом, его наработки повлияли на другие решения Fastly. Компания развивает направление WebAssembly-вычислений далее — экосистема постоянно обновляется.

Технические вызовы и ограничения

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

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

Александр Коротаев, Фронтенд-разработчик, автор ТГ канала «Трудно быть Коротаевым»:

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

Доступ к аппаратным ресурсам

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

Сообщество WebAssembly уже решает проблемы. Стандарт WASI продолжает развиваться, и в будущем появятся более гибкие способы работы с оборудованием.

Размер файлов и производительность

WebAssembly-модули могут иметь значительный размер, особенно при включении стандартных библиотек. В случае ByteFog размер бандла достигал 100 МБ, что создавало проблемы для инструментов сборки и загрузки в браузере.

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

Александр Коротаев, Фронтенд-разработчик, автор ТГ канала «Трудно быть Коротаевым»:

Тут имеется ввиду краеугольная проблема WASM модулей — ввод и вывод. Дело в том, что он довольно низкоуровневый, и если в случае с микроконтроллерами они буквально будут говорить на «одном языке» с железом, то более высокоуровневые системы, передающие данные в том же JSON, столкнутся с довольно затратным процессом сериализации данных. Чтение строки с английскими буквами это одно, а текст на разных языках — это уже задачка со звездочкой. Так что в случае LLM надо будет серьезно работать надо протоколом обмена данными.

Инструменты и экосистема

Экосистема WebAssembly вне браузера всё ещё развивается. Поддержка различных языков программирования неравномерна: лучше всего дела обстоят у C/C++ и Rust, с интерпретируемыми языками всё сложнее.

Отладка WebAssembly-модулей ограничена в сравнении с традиционными средствами. Разработчикам часто приходится использовать косвенные методы и работать с преобразованным кодом. Это особенно важно в контексте другой быстрорастущей тенденции — переносить выполнение ИИ-моделей с серверов на сами устройства пользователей (edge computing).

Например, современные компактные LLM, такие как Phi-4-mini-flash, демонстрируют впечатляющую производительность на мобильных чипах ARM, обрабатывая запросы за 90–100 мс прямо на устройстве без облака. Для подобных сценариев WebAssembly с его переносимостью и низким потреблением ресурсов выглядит идеальной средой, если сможет предложить более прямой и эффективный доступ к специфическим возможностям железа.

Будущее WebAssembly вне браузера

Перспективы WebAssembly вне браузера выглядит многообещающим. Стандарт WASI совершенствуется, поддерживая новые системные интерфейсы и возможности. Разработчики получают всё более мощные инструменты для создания и отладки WASM-модулей.

В embedded-сфере WebAssembly может стать стандартом для безопасного выполнения кода на различных устройствах IoT (интернета вещей). Его способность работать на ресурсо-ограниченных устройствах при изоляции делает инструмент привлекательной альтернативой традиционным подходам.

Майлз Боринс, технический директор руководящего комитета Node.js, видит потенциал WebAssembly в решении одной из наибольших проблем фреймворка: «Это способ достичь скорости, близкой к нативной, и повторно использовать код, написанный на других языках (C и C++), сохранять портативность и безопасность».

Александр Коротаев, Фронтенд-разработчик, автор ТГ канала «Трудно быть Коротаевым»:

Как я понял, под фундаментальными проблемами имеется в виду ограничение на кол-во операций с потоками и файлами в текущий версиях Node.js, что не дает серверам на «ноде» тягаться с Nginx на равных.

Итоги

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

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

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

Как отмечает Шон Уайт, директор Mozilla по R&D: «WebAssembly уже меняет способы доставки людям новых видов привлекательного контента. С WASI преимущества WebAssembly получат больше пользователей и больше устройств в разных местах».

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

Сегодня их рекомендательная система экономит более $1 млрд в год, удерживая подписчиков и увеличивая время просмотра. И именно ее решил изучить разработчик на платформе BeyondIT.

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

Такой подход помогает избежать «паралича выбора» и быстрее находить интересный контент.

Сердце системы — матричная факторизация

Ключевая технология, популяризованная ещё во времена конкурса Netflix Prize в 2006 году — матричная факторизация.

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

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

Больше, чем просто «похожие на вас»

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

Интерфейс и обложки фильмов постоянно проходят A/B-тесты, чтобы максимизировать вовлечённость.

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

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

Реакция в реальном времени

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

Инфраструктура включает Kafka, Spark, микросервисы в AWS, кэширование в памяти и edge-вычисления для минимальной задержки.

Почему это важно

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

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

Бонус — комментарии экспертов с многолетним опытом работы за границей и глубоким пониманием международного рынка труда.

Какие IT-профессии наиболее востребованы за рубежом

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

• менеджеры по продажам и работе с клиентами (13%),
• операторы колл-центров (5%),
• дизайнеры, менеджеры по маркетингу, интернет-маркетологи, художники (по 4%),
• учителя, SMM- и контент-менеджеры (по 3%),
• секретари, помощники руководителя, ассистенты (по 2%).

Программисты и разработчики заняли почётное второе место (10%). А специалисты технической поддержки и тестировщики набрали всего по 2%.

Но в исследовании образовательной онлайн-платформы «Нетология» и международного коммуникационного агентства Zecomms Agency специалист технической поддержки — наоборот, наиболее востребованная профессия за рубежом. С ним связано 17% от общего массива IT‑вакансий, что делает специалиста техподдержки абсолютным лидером по количеству открытых вакансий.

На втором месте расположился программный инженер (16%), на третьем — бизнес-аналитик (6%) и IT-консультант (6%).

Максим Оганов, ментор, бизнес-консультант, автор проекта Oganov.Consulting:

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

Евгений Козак, senior фронтенд-разработчик компании With Intelligence, живёт в Лондоне, более 10 лет опыта работы за границей:

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

Языки программирования, актуальные для иностранных компаний

Согласно исследованию «Нетологии» и Zecomms Agency, Java признан самым популярным языком программирования — его активно используют компании по всему миру. На Java приходится более четверти всех открытых вакансий (26%) в сфере IT в Европе, США, Латинской Америке, Азии и на Ближнем Востоке.

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

На втором месте по популярности находится язык SQL, который используют для разработки баз данных и систем аналитики. На него пришлось 24% всех вакансий, бóльшая часть из них в Европе, Азии и на Ближнем Востоке.

Замыкает тройку лидеров Python (23%) — более половины открытых вакансий в Азии и на Ближнем Востоке связано именно с этим языком. Оно и неудивительно: на Python пишут модели для машинного обучения, анализа данных и автоматизации.

Сколько айтишникам платят за границей

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

Евгений Козак, senior фронтенд-разработчик компании With Intelligence, живёт в Лондоне, более 10 лет опыта работы за границей:

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

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

Но ключевое — размер оклада. По данным «Профсоюза работников ИТ», медианная зарплата специалистов уровня senior в России составляет 276 362 рубля в месяц, в то время как за рубежом она равна 386 730 рублей в месяц. Российские миддлы получают 170 000 рублей, а работающие за границей — 205 142 рубля. Зарплата джунов несильно отличается, хотя «за бугром» она всё-таки немного больше: 85 000 рублей против 80 000 рублей в России.

Таким образом, зарплата IT-специалистов за рубежом как минимум в 1,5 раза больше, чем в России.

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

Где IT-кадры пользуются спросом

Найти работу в IT сейчас везде нелегко, но чуть проще это сделать там, где активно развивается IT-сектор и требуется много кадров соответствующего профиля:

Германия. Наибольший дефицит IT-специалистов наблюдается в Германии — в 2023 году было опубликовано 103 089 вакансий. Особенно остро нехватка кадров ощущается в таких областях, как разработка программного обеспечения, Data Science, кибербезопасность и DevOps. А в 2025 году страна планирует выдать на 10% больше рабочих виз, чем годом ранее.

Нидерланды. В стране большое внимание уделяется IT-стартапам. Так, в 2024 году голландские технологические компании привлекли €3,7 млрд венчурных инвестиций — это около 5% от общего объёма капитала, вложенного в европейскую экосистему. Благодаря этому Нидерланды вошли в топ‑10 стран Европы по объёму инвестиций в технологии. Особенно быстро растёт сектор DeepTech («глубоких технологий») — полупроводники, искусственный интеллект и квантовые технологии.

Канада. Такие канадские города как Торонто, Ванкувер и Монреаль считаются настоящей IT-меккой. Здесь активно развиваются стартапы и работают подразделения крупнейших технологических компаний — Google, Microsoft, Amazon. Кроме того, для IT-специалистов есть много иммиграционных программ, например, Global Talent Stream, которая позволяет получить разрешение на работу в течение двух недель.

США. В 2023 году объём IТ-рынка США достиг $1,3 трлн и продолжает развиваться высокими темпами. В Европейском союзе он составил $1,05 трлн, в Китае — $348 млрд, в России — $36,1 млрд. Таким образом, американский технологический рынок в 36 раз больше российского, в 1,24 раза больше европейского и почти в четыре раза превосходит китайский. Это подтверждает его статус мирового лидера. Соответственно, IT-специалистов нужно много.

Куда уехать проще всего

По данным HeadHunter, активнее всего российских специалистов приглашают на работу компании из:

• Белоруссии — 172,3 тыс. приглашений,
• Казахстана — 150,9 тыс. приглашений,
• Грузии и Турции — 69,7 тыс. и 67,8 тыс. приглашений соответственно,
• Узбекистана — 57,2 тыс. приглашений.

Самый большой рост интереса продемонстрировали китайские работодатели — он увеличился почти в шесть раз. В 2023 году количество предложений для жителей России о работе в Китае составляло всего 4,8 тыс., тогда как в 2024 году цифра достигла 27,6 тыс. предложений.

Кроме того, за год потребность в российских специалистах выросла в Сербии с 5,8 тыс. до 26,3 тыс. (+356,3%), в Турции — с 23,5 тыс. до 67,8 тыс. (+188,6%), на Кипре — с 4,6 тыс. до 12 тыс. (+160,9%), в Польше — с 4,1 тыс. до 9,0 тыс. (+119,6%) и в ОАЭ — с 19,2 тыс. до 41,7 тыс. (+117,2%).

А Европа стала лидером по количеству предложений для IT-специалистов со знанием русского языка — 3% всех IT-вакансий в регионе. На других рынках доля таких предложений не превышает 1%. Чаще всего русскоязычных специалистов ищут в Польше — 2 200 вакансий, Венгрии — 752 вакансии, Австрии — 178 вакансий, Греции — 152 вакансии.

Максим Оганов, ментор, бизнес-консультант, автор проекта Oganov.Consulting:

Не все страны охотно принимают специалистов из других стран. Если раньше одними из самых популярных направлений для релокации были Канада и США, то сейчас переехать туда стало значительно сложнее. Больше шансов на трудоустройство в компании Испании, Португалии, Кипра, ОАЭ.

Как IT-специалисту найти работу за границей: четыре шага

1. Зарегистрируйтесь на международных платформах

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

Вот подборка сайтов для поиска работы за границей:

• LinkedIn — профессиональная социальная сеть, где можно искать вакансии и налаживать контакты;
• Indeed — международный агрегатор вакансий, позволяющий фильтровать их по странам, городам и отраслям;
• Relocate.me — платформа для вакансий с релокацией;
• Remote OK — площадка для поиска удалённой работы;
• WWR — сервис, где публикуют вакансии крупные зарубежные компании, например, Amazon или Google.
• AngelList Talent — каталог вакансий в иностранных стартапах.

Некоторые из них открываются только с VPN.

Максим Оганов, ментор, бизнес-консультант, автор проекта Oganov.Consulting:

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

Евгений Козак, senior фронтенд-разработчик компании With Intelligence, живёт в Лондоне, более 10 лет опыта работы за границей:

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

2. Адаптируйте резюме для иностранного рынка

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

Эксперты компании EP Advisory, которая помогает российским специалистам строить карьеру за рубежом, рекомендуют включать в CV разделы Name, Profile, Education, Experience, Skills & Other. Названия предыдущих компаний и занимаемые должности следует выделять, а каждый блок — разграничить чертой.

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

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

Максим Оганов, ментор, бизнес-консультант, автор проекта Oganov.Consulting:

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

3. Обратитесь в агентство по трудоустройству

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

Вот список наиболее известных рекрутинговых агентств:

• Adecco — крупнейшее агентство с вакансиями по всему миру;
• Manpower — международная стаффинговая, аутсорсинговая и HR-консалтинговая компания из России;
• Michael Page — международная компания, которая специализируется на подборе персонала среднего и высшего звена;
• Hays — британская рекрутинговая компания, которая предоставляет услуги по подбору персонала в 33 странах мира;
• Harvey Nash — международная компания, которая специализируется на IT-аутсорсинге;
• Randstad — голландская консалтинговая компания, которая сотрудничает с ведущими зарубежными работодателями.

Агентства также консультируют по вопросам адаптации и помогают с поиском жилья.

Евгений Козак, senior фронтенд-разработчик компании With Intelligence, живёт в Лондоне, более 10 лет опыта работы за границей:

Чтобы найти работу в Лондоне, я сотрудничал с международными и британскими рекрутинговыми агентствами — Hays, Harvey Nash и Michael Page. Примерно 50% предложений приходили именно от них. Эти агентства играют важную роль на IT-рынке и обладают широкой сетью контактов с работодателями по всей Европе. Они помогали мне в поиске подходящих позиций и сопровождали на всех этапах — от первичного отклика до собеседования и подписания оффера.

4. Получите визу и разрешение на работу

Без визы и разрешения приступить к работе за границей не получится. Здесь доступны два варианта — Digital Nomad Visa или обычные рабочие визы.

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

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

Чтобы получить визу цифрового кочевника, нужно подтвердить минимальный доход (чаще всего не ниже 2000 евро в месяц) и наличие медицинской страховки. Также может понадобиться трудовой договор или договор подряда, доказывающие, что вы работаете удалённо. Сейчас Digital Nomad Visa оформляют в 66 странах, включая Португалию, Испанию, Эстонию, ОАЭ и Южную Корею.

Классические рабочие визы. Это визы EU Blue Card или виза H‑1B.

• Голубая карта (EU Blue card) — виза для работы в Европе. Чтобы получить её, нужен диплом о высшем образовании (не ниже бакалавра) и оффер с зарплатой от 48 300 евро год (43 760 евро для IT‑специалистов) на срок минимум шесть месяцев. В случае одобрения выдаётся вид на жительство, действующий до четырёх лет с возможностью продления.

• Виза H‑1B — виза для работы в США. Она также требует наличия высшего образования и оффера от местной компании. Но американское законодательство устанавливает лимит на выдачу H‑1B — 65 000 базовых и 20 000 дополнительных виз для специалистов с магистерской степенью из США. Всего 85 000 виз в год. Виза предоставляется максимум на три года с возможностью продления до шесть лет.

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

Официальное трудоустройство или фриланс

Удалённая работа на фрилансе

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

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

Официальное трудоустройство с релокацией

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

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

Максим Оганов, ментор, бизнес-консультант, автор проекта Oganov.Consulting:

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

Евгений Козак, senior фронтенд-разработчик компании With Intelligence, живёт в Лондоне, более 10 лет опыта работы за границей:

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

Какой уровень владения английским языком нужен

Для оценки владения иностранными языками, включая английский, в Европе используют систему CEFR (Common European Framework of Reference). CEFR выделяет шесть уровней знания языка: A1, A2, B1, B2, C1, C2.

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

Максим Оганов, ментор, бизнес-консультант, автор проекта Oganov.Consulting:

Обязательное требование — свободное владение английским: например, в Португалии большинство сотрудников IT-компаний общаются на нём. Но иногда кандидату необходимо знание местных языков — так, если вы хотите переехать во Францию, шансы на трудоустройство без владения французским минимальны.

Евгений Козак, senior фронтенд-разработчик компании With Intelligence, живёт в Лондоне, более 10 лет опыта работы за границей:

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

Коротко о главном

• Иностранные компании активно используют Java, Python, SQL и нуждаются в программистах, умеющих писать на этих языках.
• IT-специалисты особенно востребованы в Германии, Нидерландах, Канаде и США — странах с наиболее интенсивным ростом технологического сектора.
• Проще всего уехать в Белоруссию, Казахстан, Турцию, Грузию и Китай.
• Работать за границей можно официально или на фрилансе.
• Чтобы получить оффер, следует зарегистрироваться на международных платформах для поиска работы, адаптировать резюме, оформить визу и, при необходимости, обратиться в агентство.

В мае 2024 по всему миру разлетелись скриншоты писем от HR с внезапными повышениями зарплат на 40%. Текучка кадров в сфере производства полупроводников выросла с 40% до 53%, и теперь компании дерутся за каждого специалиста.

Масштаб проблемы

169 отраслей пострадали из-за дефицита чипов — от автомобилестроения до бытовой техники. Tesla и Volvo останавливали заводы, цены на подержанные автомобили выросли на 10% за квартал. Даже стиральные машины подорожали из-за недостатка микросхем.

Но настоящая битва кипит в кабинетах бигтехов. США заблокировали экспорт технологий в Китай, Европа запустила программу на €43 миллиарда, а Азия удерживает 77% мирового производства чипов.

Технологическая война изменила ИТ-индустрию навсегда. Компании теперь не могут просто купить больше серверов — приходится искать тех, кто умеет делать софт быстрее и эффективнее. Apple создала собственные M1 и M2, Google разработал TPU, Amazon — процессоры Graviton. Каждый хочет стать независимым от поставок.

Обрушение цепей поставок

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

Мир оказался в заложниках у нескольких азиатских гигантов. Тайвань контролирует 65% мирового рынка чипов, TSMC делает процессоры для Apple, AMD и NVIDIA. Samsung доминирует в производстве памяти и накопителей.

Различные отрасли посыпались, как домино. Время ожидания полупроводников Broadcom выросло до 22 недель против 12 недель в феврале 2020. Автоиндустрия потеряла миллионы машин, дата-центры замедлили расширение, даже PlayStation 5 стали дефицитом.

США первыми объявили технологическую войну. Пошлины уже изменили процессы производства у Nvidia, Intel и AMD. Китай ответил санкциями против Micron Technology.

Ключевые игроки разделились на два лагеря. На стороне США — Intel, NVIDIA, AMD, Qualcomm. Китай развивает SMIC и вкладывает миллиарды в собственные технологии. TSMC и Samsung балансируют между сторонами, строя заводы и в Америке, и в Азии.

Национальные программы превратились в гонку вооружений. CHIPS Act выделил $50 миллиардов на американское производство. Европейская программа нацелена на производство 20% мировых чипов к 2030 году. Китай инвестирует $143 миллиарда в полупроводники.

Гонки в мире чипов

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

Техпроцессы сжимаются в размере. TSMC освоила 3-нанометровый процесс, Samsung догоняет. Каждый нанометр стоит миллиарды инвестиций и годы разработки. Apple M4 имеет Neural Engine в три раза быстрее M1, но производство одного такого чипа требует сотни инженеров.

AI-чипы стали новой золотой жилой. Intel запустила Gaudi 3, который на 50% быстрее NVIDIA H100. NVIDIA ответила платформой Blackwell с 208 миллиардами транзисторов. Qualcomm Cloud AI 100 обошел H100 по энергоэффективности — 227 запросов на ватт против 108.

Квантовые технологии пока остаются в лабораториях, но IBM и Google уже тестируют прототипы. Нейроморфные чипы, которые имитируют работу мозга, обещают революцию в энергоэффективности.

Делать чипы стало сложнее и дороже. Современная фабрика стоит $20 миллиардов, срок окупаемости — 10 лет. Поэтому крупные компании строят собственные решения: Apple создала M-серию, Google — TPU, Amazon — Graviton.

Компании поменяли философию. Вместо покупки большего количества серверов они нанимают инженеров для оптимизации кода. Netflix использует персонализированные рекомендации и алгоритмы ранжирования для оптимизации вычислений. Meta* оптимизировала машинное обучение и уменьшила количество GPU на 40%.

Массовый переход на ARM изменил рынок. Amazon перевела часть ресурсов на собственные процессоры. Microsoft адаптировала Windows под ARM-архитектуру. Даже Intel вынуждена выпускать подобные решения.

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

*– компания признана в РФ экстремистской и запрещена.

Айтишники в центре шторма

Зарплаты разработчиков взлетели вместе с ценами на чипы. Средняя зарплата embedded-инженера выросла до $153,383, а топовые специалисты получают до $175,000 в год. Performance-инженеры зарабатывают в среднем $100,522, но спрос превышает предложение. Оптимизация под ARM-архитектуру, разработка драйверов для AI-ускорителей, программирование FPGA — навыки, за которые компании готовы переплачивать. IT-зарплаты в Северной Америке выросли в среднем до $113,211.

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

География возможностей сместилась. Калифорния лидирует по зарплатам — $126,707 в Сан-Хосе, но спрос есть везде. Даже компании из Техаса и Флориды переманивают embedded-разработчиков зарплатами в $120,000-150,000.

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

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

Свет в конце туннеля

Эксперты расходятся в прогнозах восстановления. CEO Intel Пат Гелсингер ожидал дефицит до 2024 года, но рынок полупроводников уже показал рост на 15,2% в начале года. К 2023-му автоиндустрия в основном восстановилась, глобальное производство автомобилей выросло на 3%.

Новые фабрики меняют географию производства. Intel строит заводы в Аризоне за $20 миллиардов и расширяется в Огайо. TSMC открыла завод в Японии в феврале 2024 и планирует второй к 2027 году. Samsung инвестирует в производство в Техасе.

Европа также входит в игру. European Chips Act нацелен на производство 20% мировых чипов к 2030 году с бюджетом €43 миллиарда. Intel проектирует заводы в Ирландии и Германии, Micron строит завод в Нью-Йорке, а GlobalFoundries расширяется на Мальте.

Будущее отрасли — в диверсификации. Тайвань по-прежнему контролирует 65% производства, но объемы будут снижаться. К 2030 году США планируют удвоить свою долю в мировом производстве чипов.

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

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

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

Здесь и появляются новые роли — Technical Owner и Unit-лид. Их задача — взять на себя куски ответственности, которые раньше выпадали из поля зрения команды.

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

Technical Owner: кто это и зачем нужен

Представим ситуацию: компания разрабатывает маркетплейс на Python и React, всё вроде идёт по плану, пока менеджеры не просят срочно добавить новую систему оплаты. Они не вникают, что для этого придётся переделать схему платежей, разнести микросервисы, рискуя уронить старые заказы. Разработчики объясняют, что быстро не выйдет, но их не слышат — и в итоге проект зависает между требованиями бизнеса и возможностями команды. Именно в таких случаях нужен Technical Owner.

Кто это такой

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

Какие у него обязанности

Вот примерный список того, что делает ТО:

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

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

Чем отличается от продуктового менеджера, техлида и архитектора

Чем ТО отличается от продуктового менеджера

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

Чем отличается от тимлида, техлида и архитектора

Тимлид, техлид — это руководители команды, которые отвечают только за её задачи. TO, хоть и глубоко понимает техническую сторону, но его роль шире — он связывает технику с бизнесом и даже консультирует клиентов. Technical Owner отвечает за общее техническое и архитектурное видение продукта. Масштаб его ответственности больше.

В отличие от архитектора, технический владелец не только принимает участие в проектировании, но и доносит эти решения до клиентов и руководства.

Technical Owner (Технический владелец) ответственен за долгосрочное здоровье и развитие конкретного компонента/системы/продукта. Фокус на технической стратегии, архитектуре, надёжности и поддержке в течение всего жизненного цикла.

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

Архитектор решений определяет технологический стек и взаимодействие компонентов. Фокус на общей структуре и дизайне решения.

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

Сколько зарабатывает и какие нужны навыки, чтобы стать ТО

Если мы сейчас пойдём на hh.ru и введём в поиск Technical Owner, то, в лучшем случае, найдём только пару вакансий. Technical Owner нужен для больших продуктов в крупных компаниях, поэтому должность встречается на рыке редко и пробиться туда сложно.

Зарплата и навыки зависят от конкретной компании, её процессов и задач. Обычно это что-то на уровне топ-менеджмента. Вот пример заработной платы в одной из вакансий от Яндекс 360:

А вот так выглядят обязанности и необходимые навыки:

Вот пример ещё одной такой вакансии от компании Itransition:

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

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

Кто такой Unit-лид, зачем он нужен

Кто это такой

Юнит-лид — это руководитель, который возглавляет «юнит» – объединение нескольких команд (обычно 3-5), работающих над частью общего продукта или бизнес-направления. Он отвечает за стратегию и бизнес-результаты своего юнита.

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

Что такое юнит? Это самостоятельный бизнес-модуль, включающий несколько стримов (направлений). Каждый стрим, в свою очередь, состоит из команд по 5-10 человек. Таким образом, один юнит может объединять от 5 до 12 команд, представляющих разные IT-направления: фронтенд, бэкенд, мобайл и др.

Какие у него обязанности

Обязанности юнит-лида очень обширны и зависят от типа юнита:

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

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

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

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

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

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

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

Что делает продуктовый менеджер

Продуктовый менеджер (PM или Product Owner) отвечает за конкретный продукт или его отдельные части. Его главная задача — понять, что нужно пользователям и бизнесу, сформировать требования и приоритеты, а затем воплотить эти требования в жизнь. PM постоянно держит руку на пульсе метрик, проводит A/B-тесты и собирает обратную связь.

Что делает тимлид

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

Чем занимается юнит-лид

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

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

Две другие команды отдают цены в другие сервисы, организуют скидки, интегрируют новые категории товаров и услуг в систему.

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

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

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

Сколько зарабатывает unit-лид, какие нужны навыки и как им стать

Наткнуться на вакансию юнит-лида на просторах hh.ru тоже непросто. Это новая роль, которая нужна только для сложных продуктов в крупных IT-компаниях.

С зарплатой и обязанностями всё индивидуально, зависит от компании. Вот пример одной из вакансий от Купера:

Зарплата вполне на уровне топ-менеджмента. А вот обязанности и ожидания:

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

А вот ещё один пример обязанностей и ожиданий в другой вакансии, на этот раз от Яндекса:

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

Где и когда эти роли реально нужны (а где — нет)

Какие компании и проекты выигрывают от появления таких ролей

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

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

Сигналы, что команде пора подумать о Technical Owner или Unit-лиде

Есть несколько явных признаков, когда стоит задуматься о введении этих ролей:

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

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

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

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

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

Недавно сходил с Витей на запись подкаста на эту тему и настолько преисполнился, что решил в текстовом виде формализировать свое отношение к теме (я гнался за вами три дня, чтобы сказать, как вы мне безразличны, ага), обобщить то, о чем говорили, и попытаться дать ответ на вопрос «когда микросервисы действительно помогают и как не сойти с ума, если вы с ними работаете». Порассуждаю о проектировании, поддержке, 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-сфере.

1. МояДоска

«МояДоска» — это российский SaaS-сервис для совместной работы и визуализации идей. У онлайн-доски бесконечный размер: это значит, что вы можете размещать сколько угодно элементов и никогда не упретесь в границу. Так, команды, преподаватели и креативные специалисты могут проводить брейнштормы, планирования, презентации и обучение в одном пространстве.

Что под капотом

Фронт написан на React + PixiJS, а бэк — Node.js + PostgreSQL. Это обеспечивает быстрый и понятный интерфейс и стабильную работу даже при большом объёме объектов на доске. Команда выпускает обновления несколько раз в месяц, а о новинках можно узнать в Telegram-канале сервиса. Например, в недавнем апдейте появилась возможность превратить фрейм в таблицу или тетрадь за пару кликов, а еще задать нужное число столбцов, колонок, толщину границ и цвет.

Из главных функций:

• Понятный интерфейс
• Совместная работа в реальном времени
• Привычные инструменты: фигуры, стрелки, стикеры, текст, загрузка файлов, маркер, карандаш
• Обрезка фото прямо на доске, воспроизведение аудио, поддержка PDF
• Гибкое управление доступом
• Возможность повторного использования шаблонов
• Поддержка фреймов и создание логичных пространств для разных задач

Переезд на сервис

«МояДоска» интегрируется в процессы на разных этапах, упрощая жизнь команде. Например, сама команда сервиса перешла с Miro на свою доску для стратегического планирования. С помощью стикеров и стрелок они построили дерево решений, чтобы лучше расставить приоритеты. А одно маркетинговое агентство перевело все документы и сессии планирования на доску, отказавшись от Google Docs и таблиц. Это ускорило принятие решений: сотрудники работали с данными в одном формате, точно собрались в одном кабинете перед маркерной доской.

2. METEOR

METEOR — инструмент управления проектами. Это трекер задач с дашбордами, досками канбан, диаграммами Ганта и API, который работает в виде веб-приложения как в облаке, так и на своих серверах. Продукт создавался как универсальный центр управления задачами: он объединяет в себе все — от разработки и тестирования до маркетинга и поддержки. Сейчас его используют более 250 команд и свыше 2000 пользователей ежедневно.

Что под капотом

В основе — стек Ruby on Rails, React и TypeScript, PostgreSQL и Redis, плюс современная инфраструктура на Docker и Kubernetes.

Система разбита на микросервисы — за фоновую обработку, нотификации и работу с файлами отвечает отдельный функционал. Авторизация построена через OAuth 2.0 (Google, Yandex), а для аналитики используется Posthog и ELK-стек. Мониторинг реализован на Prometheus + Grafana. Обновления выходят каждую неделю, а обратная связь приходит разработчикам METEOR через Telegram-бот.

Вот главные функции:

• Гибкие доски задач (Kanban, Scrum) — 6 видов.
• Списки задач с группировками и иерархией.
• Автоматические отчеты (ежедневные/еженедельные сводки).
• Умные напоминания (Telegram-бот, email).
• Глубокая аналитика (время выполнения задач, загрузка команды).
• Потоковая автоматизация процессов

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

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

Разработчики используют METEOR для линковки задач с pull-requests и контроля бэклога. Менеджеры получают отчеты автоматически и не тратят часы, чтобы собрать всю информацию вручную. QA ведут тест-кейсы и баги в удобных досках, а DevOps отслеживают инциденты и шаги деплоя. Даже HR подключаются — через систему проходят кандидаты и стажеры.

Переезд на сервис

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

• скорость выполнения задач увеличивается в среднем на 25% — благодаря автоматическим напоминаниям и чётким процессам;
• количество потерянных задач снижается на 70% — исчезают хаотичные чаты и забытые письма;
• на составление отчетов и сбор метрик уходит не 5 часов, а всего 30 минут в неделю;
• а экономия времени — около 75 часов в месяц на команду из 10 человек.

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

3. Gitlife

GitLife — это универсальная платформа для хостинга репозиториев и построения полного DevOps-процесса внутри компании. Разработана с прицелом на закрытые контуры, импортозамещение и гибкость — подходит как для современных Git-проектов, так и для инфраструктур, где все еще используется SVN.

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

Что под капотом

Внутри Gitlife собраны модули для:

• Кода — репозитории, ветвление.
• Задач — бэклоги, спринты, дашборды.
• Документации — совместное редактирование документов, управление правами.
• Аналитики — карты потока ценности, качество кода, метрики по инженерам.
• Пайплайны — модуль «Конвейер» управляет сборками и CI/CD.

Gitlife используется ИТ-отделами и R&D-подразделениями в компаниях с высокими требованиями к информационной безопасности. Подходит как для небольших команд, так и для распределённых корпораций с десятками проектов.

Что решает:

• Безопасный и полностью локальный хостинг исходного кода (Git + SVN)
• Управление задачами и CI/CD в одном месте
• Централизованный доступ, права, аудиты и история изменений
• Полная поддержка DevOps-процессов на российском ПО
• Альтернатива GitHub, GitLab и Bitbucket в условиях ограниченного доступа и санкционных рисков

Переезд на сервис

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

4. Cerebro

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

Платформа охватывает полный цикл — от первых идей и планирования до комментирования финальных шотов (отдельных сцен или кадров в видео/анимации) и соблюдения дедлайнов. Такой подход помогает команде ускорить работу на 20%, сократить время на правки и держать весь процесс под контролем — от начала до сдачи проекта.

Cerebro подходит для команд от 1 до 1000+ человек с задачами на проекте от 1 до 10000+. Сервис работает с 2009 года, сейчас им пользуются более 400 команд в России и СНГ.

Что под капотом

Cerebro поддерживает десктоп (Windows, Mac и Linux), веб-версию и мобильное приложение, локальное, облачное и гибридное развертывание. Инструмент построен на клиент-серверной архитектуре — она гибкая, поэтому можно настраивать конфиги исходя из потребностей бизнеса.

Из технологий:

• Backend: C, C++, Python, SQL
• Frontend: JS, TypeScript, ReactJS, Qt, PyQt
• Мобильные клиенты: React Native
• БД: PostgreSQL с проприетарными расширениями + SQLite
• Файловое хранилище: Cargador
• Плагины: Tentaculo (встраивается в производственные программы)

Cerebro покрывает весь пайплайн — от идеи до финала. Вот основные возможности сервиса:

• Множественные уровни вложенности задач — подходит для сложных иерархий продакшена
• Планирование с помощью диаграммы Ганта и специального инструмента «План»
• Канбан-доска для визуального контроля задач
• Инструмент «Моё пространство» — для персонализированной фильтрации и отбора задач
• Уровни доступа и ролевое управление
• Расширенная статистика по проектам, командам, сотрудникам
• Совместная работа над большими файлами (видео, изображения, 3D) — Mirada позволяет комментировать, делать подрисовки, оставлять голосовые заметки
• Интеграция с пакетами Adobe, Autodesk и мессенджерами, возможность встраивать в любые пайплайны
• Удобное подключение фрилансеров

Переезд на сервис

Обычно внедрение начинается еще на этапе препродакшена — во время разработки концепции и четкого плана действий. Затем система сопровождает проект на всех стадиях, вплоть до постпродакшена (финального тестирования и релиза), где она закрывает 80-100% задач. Cerebro позволяет собирать всё в одном месте: задачи, правки, сроки, бюджеты, загрузку сотрудников и статус проекта в целом.

После переезда снимается много рутинных задач: больше не нужно вручную назначать исполнителей, комментировать медиаконтент, передавать файлы между программами и так далее. В среднем проекты выполняются на 20% быстрее, без потери качества. В больших студиях объем выпускаемых шотов может вырасти до 20+ тысяч — это уже работает у других клиентов, среди которых СберМаркетинг, Sinners, Black Point и другие. Cerebro также помогает переехать с других такс-трекеров и систем для управления проектами.

5. Replit Teams

Replit Teams — это платформа для совместной разработки в реальном времени. По сути, это интегрированная IDE + git-репозиторий + система управления задачами — и все доступно через браузер. Подходит как для командной работы в стартапах, так и для образовательных проектов, хакатонов и небольших продуктовых команд.

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

Что под капотом

Внутри Replit Teams есть интерфейсы для:

• Кода — редактор с автокомплитом, подсветкой синтаксиса, терминалом и интеграцией с Git.
• Задач — встроенный таск-менеджер с распределением задач по участникам.
• Общения — встроенные комментарии в коде, возможность ревью и обсуждений.
• CI/DevOps — запуск и отладка приложений без настройки окружения.
• Доступа — гибкие роли, приглашения по ссылке, настройки приватности.

Переезд на сервис

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

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

Рассказывайте в комментариях, какими сервисами пользуетесь вы.

Откуда началось: мой путь в финтех

До Finance.kz я работал в казахстанских финтех-проектах — bai.kz и finbee.kz. Там понял, что рынок агрегаторов в Казахстане находится в зачаточном состоянии. Пользователи мучились, сравнивая предложения банков вручную, а сами финансовые организации не умели эффективно работать с цифровыми каналами привлечения клиентов.

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

Состояние рынка: от монополии к жёсткой конкуренции

Казахстанский рынок агрегаторов финансовых продуктов переживает бум. Ещё два года назад здесь было 2-3 локальных игрока с простейшим функционалом. Сегодня ситуация кардинально изменилась — зашли зарубежные команды: vbr.kz, fintree.kz, moneypanda.com и другие.

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

Технологические вызовы: интеграция с госсервисами и банками

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

API-интеграции с банками и МФО

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

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

Интеграция с госорганами

Finance.kz интегрируется с государственными сервисами eGov и Палаты предпринимателей (ПКБ). Это позволяет автоматически подтягивать справки о доходах, данные о трудоустройстве и другие документы, необходимые для получения кредита.

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

Архитектура продукта: ставка на микросервисы

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

Backend

Основные сервисы написаны на Node.js с использованием Express.js. Для работы с базами данных используем PostgreSQL для транзакционных данных и Redis для кэширования. Очереди сообщений реализованы через RabbitMQ — это критично для обработки заявок пользователей.

Отдельно выделили сервис интеграций, который отвечает за взаимодействие с внешними API. Он построен по принципу circuit breaker — если один из банков не отвечает, это не ломает работу всего агрегатора.

Frontend

Фронтенд построен на React с использованием Next.js для серверной отрисовки. Это важно для SEO — львиная доля трафика приходит из поисковых систем по запросам типа «кредит онлайн».

Стратегия «единого окна»: от поиска до получения

Наша главная идея — превратить агрегатор из витрины в полноценный финтех-сервис. Пользователь должен получить продукт полностью онлайн: от сравнения условий до перечисления денег на карту.

Для этого мы реализовали несколько ключевых функций:

• Умный подбор продуктов на основе данных пользователя и машинного обучения
• Предварительный скоринг для оценки вероятности одобрения ещё до подачи заявки
• Автоматическое заполнение анкет с подтягиванием данных из госсервисов
• Отслеживание статуса заявки в реальном времени

Монетизация: CPS как основа устойчивого бизнеса

Мы работаем по модели CPS (Cost Per Sale) — получаем комиссию только за успешно выданные продукты. Для кредитов это 2% от суммы, для микрозаймов — фиксированная сумма от 7 до 15 тысяч тенге.

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

Конкурентные преимущества: локализация против красивых интерфейсов

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

Что даёт локальный подход:

• Знание рынка: мы понимаем особенности работы казахстанских банков и МФО
• Связи с регуляторами: легче договариваться об интеграциях с госорганами
• Техническая экспертиза: наша команда уже прошла путь интеграции с местными API
• Гибкая настройка продукта под изменения законодательства и требований ЦБ

Результаты и метрики

За год активного развития мы достигли:

• 150 000 уникальных пользователей в месяц
• Интеграция с 15+ финансовыми организациями
• Конверсия заявка-выдача на уровне 35-40% (против 15-20% у конкурентов)
• Средний чек по кредитам — 1,2 млн тенге, по микрозаймам — 85 тысяч

Планы на будущее: от агрегатора к экосистеме

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

Расширение продуктовой линейки

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

Внедрение ИИ и машинного обучения

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

Международная экспансия

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

Собственные финансовые продукты

В долгосрочной перспективе планируем получить лицензию МФО и предлагать собственные займы наиболее качественным клиентам.

Уроки и выводы

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

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

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

Почему «тормоза» — это не всегда про код

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

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

Вот что тормозит, когда код ни при чём:

Архитектура

• Цепочки вызовов: каждый хоп — +latency.
• Синхронные зависимости: завис один сервис — тормозят все.
• Общие ресурсы: shared state, глобальные очереди, блокировки.

Базы данных

• Нет индексов или плохой план запроса.
• N+1-запросы — особенно при неосторожной ORM.
• Частый доступ к одним таблицам — гонка за IO и блоки.
• Нет шардинга или репликации в масштабируемой нагрузке.

Сеть

• Высокая задержка между регионами (особенно multi-cloud).
• Потери пакетов, DNS-проблемы, нестабильность.
• Отсутствие connection reuse: TLS-handshake на каждый вызов.

Очереди и брокеры

• Один медленный потребитель тормозит всех.
• Нет защиты от от backpressure или дедупликации.
• Неправильные batch- и ack-настройки.

Аллокаторы и GC

• Фрагментация памяти, нагрузка на GC.
• Финалайзеры, слабые ссылки, плохо настроенный heap.

Конфигурации

• Маленький пул соединений — пул заканчивается, запросы ждут.
• Агрессивные retry-политики — система перегружается.
• CPU throttling в Kubernetes — контейнеру не хватает ресурсов.

Сериализация и форматы

• Перегруженные JSON/Protobuf.
• Вложенные base64 + gzip + JSON — боли сериализации.

Почему bottlenecks остаются невидимыми до продакшена

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

• мало данных,
• нет конкуренции за ресурсы,
• нет распределённой нагрузки.

В проде начинается хаос. Рассмотрим на конкретных примерах:

• На деве — 2 запроса в секунду, в проде — миллион. Кто-то запустил маркетинговую рассылку, аналитик тащит big report, а клиент ретраит ошибки.
• Архитектура «в лоб»: всё синхронно, каждый сервис вызывает по цепочке десяток других. Пока нагрузка мала — все живет. Как только одно звено не выдерживает — перестает жить.
• Иллюзия масштабируемости: до 100 пользователей — всё окей, на 1000 — каскадная деградация.
• «Невидимая боль» между сервисами: каждый по отдельности быстрый, но блокирует друг друга на базе.

Слои архитектуры и где в них зарыты проблемы

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

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

На уровне клиента

• Тяжёлые бандлы. Огромный JS, куча аналитики, трекеры — и вот страница загружается 8 секунд на старом телефоне.

• Чрезмерные запросы. После загрузки — 10 fetch в секунду. API захлёбывается, браузер — тоже.

• Нет кеша. Даже статичные справочники каждый раз грузятся заново.

• Лаги рендеринга. Бэкенд дал ответ за 100ms, но интерфейс лагает — сложные таблицы, графики, reflow.

На уровне API Gateway / BFF

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

На уровне Backend / бизнес-логики

• Цепочки вызовов. Один сервис вызывает другой, тот — ещё один… И так далее.
• Ограниченный пул соединений — сервис готов работать, но все worker-ы ждут ресурсы.
• Логика в цикле по данным — N+1-запросы, сериализация, дублирование работы.

На уровне базы данных / кэша

• Full table scan. Работает быстро на 1000 строках. Умирает на 10 миллионах.

• Локи и гонка за ресурсы. Один UPDATE лочит строку, остальные ждут.

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

На уровне внешних сервисов (API, брокеры, платёжки)

• Без timeout и fallback. Внешний API залип — вы вместе с ним.
• QPS-лимиты. Вы не знали, а вас уже зарейт-лимитили.
• Нестабильная сеть. DNS тормозит, соединения рвутся, задержки скачут между регионами.

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

Есть архитектурные паттерны риска, которые часто приводят к тормозам через полгода. Во-первых, общий ресурс на всех: один Redis, один Kafka-топик, одна таблица. Пока нагрузка маленькая — ок. Потом начинается бойня за доступ. Во-вторых, микросервисный монолит: формально разделены, но живут как один. Масштабировать невозможно. В-третьих, цепочки вызовов: 5–6 сервисов на путь одного запроса. Один подвис — и вся цепочка тормозит.

Базы данных: когда даже SELECT тормозит всё

В бэкенде одна из самых коварных фраз — «ну это же просто SELECT, что с ним будет». Ответ — сначала ничего. Но со временем появляется 10 миллионов строк, и ваш innocuous SELECT превращается в full scan, который лочит диск, ест CPU и тормозит всё, что движется.

Типичная ситуация: в таблицу пишут JSONB без нормализации и индексов. Пока строк мало — жить можно. Но при росте объёмов каждый запрос превращается в медленное последовательное чтение. Это не просто «долго», а начинает мешать соседним транзакциям: подгружаются stale данные, вытесняется кэш, система начинает проседать вся — вплоть до API.

Отдельная ловушка — смешение OLTP и OLAP нагрузки. Днём — INSERT и UPDATE от клиентов, ночью — фоновая аналитика, высчитывающая отчёт за год с десятком JOIN и чтением всей таблицы. Если все запросы идут в один инстанс, происходит конкуренция за ресурсы: аналитика сбивает кеш, вызывает блокировки, а продакшн-метрики начинают сыпаться.

Как понять, что тормоза идут из базы, а не из бэкенда?

Вот несколько типичных признаков:

• Бэкенд «висит» на запросах к базе — в логах видно, что приложение ждёт результат запроса (долгий await, query(), findMany() и т. д.).

• Latency растёт, а CPU и память в норме — сервис сам по себе не перегружен, но ответ приходит медленно.

• В базе фиксируются медленные запросы — например, SELECT или JOIN занимают секунды, хотя раньше проходили за миллисекунды.

Чтобы подтвердить гипотезу, можно:

• Включить логирование SQL-запросов с таймингом;
• Посмотреть трейс: если шаг DB заметно длиннее остальных — это тревожный сигнал;
• Запустить EXPLAIN ANALYZE на типовые запросы и проверить, где зарыта сложность.

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

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

На что здесь стоит обратить внимание:

• Количество и характер обращений. Один пользовательский запрос не должен порождать десятки обращений к базе. Планирование кэшей, агрегаций, prefetch, нормализация — всё это часть архитектуры.
• Уровень абстракции над данными. ORM может быть удобным, но часто скрывает десятки неэффективных SELECT’ов. Нужно понимать, какие запросы реально идут в базу, и не превращать каждый use case в потенциальный bottleneck.
• Стратегия хранения и агрегаций. Если вы пытаетесь на лету агрегировать 100 миллионов строк без шардинга и партиционирования — тормоза неизбежны. Архитектура должна учитывать нагрузку, частоту агрегаций, структуру данных.

Очереди и событийные системы: скрытые замедления

Событийные архитектуры и очереди вроде Kafka или RabbitMQ часто воспринимаются как универсальное средство от всех проблем: «Сделаем асинхронно — и всё полетит». Но это не серебряная пуля. Очередь не решает проблему — она её откладывает. А иногда сама становится bottleneck’ом.

Типовые ситуации, когда очередь тормозит систему:

• Медленные консьюмеры. Очередь принимает сообщения с высокой скоростью, но обработчики не успевают, и начинается накопление беклога. В результате задержки накапливаются, SLA летит, а вы только недоумеваете, почему всё так тормозит.
• Неправильный размер batch’ей. В Kafka и аналогах размер и частота batch'ей критичны. Слишком большие — ждём, пока соберётся партия. Слишком маленькие — тратим ресурсы на лишнюю загрузку и пересылку. В итоге получаем либо высокую задержку, либо низкую производительность.
• Неравномерное партиционирование. Если сообщения распределяются по партициям неравномерно, то часть узлов будет простаивать, а часть захлёбываться под нагрузкой. Одна горячая партиция может стать bottleneck’ом всей системы.
• Проблемы с retry. Если нет чёткой стратегии повторных попыток, логирования и DLQ (dead-letter queue), битое событие может крутиться в системе бесконечно, тормозя всё остальное. Также если что-то пошло не так и включились retry-механизмы, задержка может вырасти в разы. Особенно если есть backoff или дедлоки.

Почему «асинхронно» ≠ «мгновенно»

Асинхронность — это не про скорость, а про отложенность. Событие отправлено — но когда оно будет обработано, никто не знает. Через секунду, через минуту, через час?

Типичные причины задержек в асинхронной обработке:

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

Что происходит, когда очередь переполнена — и почему это тяжело заметить

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

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

Для защиты от переполнения очереди нужно мониторить несколько важных показателей:

• Глубина очереди (в Kafka — consumer lag, в RabbitMQ — queue.messages_ready или queue.messages): показывает, сколько сообщений накопилось и ждёт обработки.
• Publish rate: сколько сообщений в секунду публикуется.
• Processing rate: сколько сообщений в секунду обрабатывается.
• Утилизация ресурсов воркеров (CPU, memory, I/O).
• End-to-end latency: сколько времени проходит от публикации события до его обработки.

Есть самые частые причины накопления сообщений:

1) Медленные потребители, которые не успевают обработать весь поток сообщений.
2) Шумная архитектура: 10 сообщений там, где можно было обойтись и одним.
3) Неправильное масштабирование брокера (например, неправильно выбранный ключ партиционирования в Kafka).

API и микросервисы: где тормозит взаимодействие

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

Что тормозит в микросервисах?

Много лишних вызовов

Один пользовательский запрос вызывает лавину внутренних HTTP/gRPC-запросов. Каждый из них — это:

• сетевые задержки (latency),
• сериализация/десериализация данных,
• ретраи при сбоях,
• риск таймаутов и обрывов.

Если таких вызовов много, задержка накапливается каскадом.

Цепочка зависимостей

Классика жанра: заказ зависит от оплаты, оплата — от биллинга, биллинг — ещё от трёх микросервисов.

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

Нет fallback'а и таймаутов

Если вызов к нужному сервису не отвечает, а у вас нет fallback'а или таймаута — всё встаёт. Особенно плохо, если вызов синхронный и блокирует поток.

Наносервисы

Иногда архитекторы увлекаются и дробят сервисы до абсурда. Начинается с «давайте переиспользуем», а заканчивается 10 API-вызовами ради одного действия.

Вместо бизнес-логики система начинает заниматься оркестрацией — координирует сама себя.

Кэш и CDN: почему «ускорители» тоже могут тормозить

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

Вот несколько типичных ошибок, которые приводят к деградации производительности:

Невалидные или слишком агрессивные стратегии

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

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

Перегрузка кэша

Когда кэш настолько загружен, что сам по себе начинает тормозить — это уже не помощь, а вред. Такое часто случается с Redis, Memcached или in-memory решениями, особенно если они:

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

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

Кэш-миссы и лавины запросов

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

Вместо одного запроса вы получаете 10 000, и тормозит всё. Особенно критично это для систем с CDN, где внезапное истечение кэша популярных страниц может вызвать DDoS-подобную нагрузку.

Несогласованность кэшей

Если в системе несколько уровней кэширования (CDN, фронтовый кэш, Redis) и они обновляются по-разному, возникает несогласованность. Один пользователь видит новые данные, другой — старые. Один сервис работает с актуальной версией, другой — с устаревшей. Начинается охота за фантомами: баги вроде есть, но не у всех.

Вычисления и память: что не так с аллокацией

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

Частые и крупные аллокации

Каждый раз, когда создаётся новый объект, память выделяется из кучи. При интенсивной работе (например, при парсинге JSON или обработке больших структур) это может происходить слишком часто, и тогда запускается сборщик мусора (GC).

Сборка мусора — это не бесплатная операция: она останавливает выполнение программы. Частые GC-паузы создают «плавающую» производительность, когда всё работает быстро, но время от времени подвисает даже на секунду.

GC-паузы

Автоматическое управление памятью — благо, но оно же и ловушка. В языках вроде Go, Java или Python невозможно точно контролировать, когда сработает сборщик. Даже задержка в 50 миллисекунд может ощутимо ударить по RPS или нарушить real-time обработку.

Некоторые компании придумывают обходные пути. Так, в Twitch использовали технику memory ballast для Go-приложений, чтобы стабилизировать поведение GC и избежать всплесков пауз.

Синхронные и блокирующие операции

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

Классический пример — однопоточный web-сервер, который просто ждёт ответ от другой системы. Или библиотека, использующая mutex.Lock() в горячем участке, из-за чего десятки горутин встают в очередь.

Ограниченные ресурсы и очереди

Даже в многопоточном приложении можно легко создать узкое место. Например:

• доступ к объекту синхронизирован через mutex или RW-lock;

• пул соединений имеет жёсткий лимит;

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

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

Однопоточные горячие участки

Даже в многопоточной архитектуре может оказаться, что 80% времени тратится в одном месте, которое не масштабируется — например, в процессе сериализации, расчёта или шифрования. Иногда этот участок реализован однопоточно (особенно в Node.js, Python или старом Go-коде) и становится главным тормозом системы. Под высокой нагрузкой это становится особенно заметно.

Что делать: подход к поиску и устранению bottlenecks

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

Шаг 1. Зафиксировать симптомы и контекст

Важно понять, что именно «тормозит» и в каких условиях. Типовые вопросы:

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

Пример: пользователи жалуются, что отчёты стали строиться дольше. Вчера — 5 секунд, сегодня — 20.

Шаг 2. Проверить очевидные метрики

Начинаем с того, что уже доступно в мониторинге:

• латентность API (p50, p95, p99);
• загрузка CPU, использование памяти и диска;
• глубина очередей и backlog;
• паузы GC;
• кэш hit/miss ratio.

Если латентность растёт, а CPU загружен на 20%, это может указывать на проблемы в синхронных вызовах, аллокации или неэффективной работе кэша.

Шаг 3. Сузить область через трейсинг и логирование

Чтобы выяснить, не «тормозит» ли другой сервис, используйте распределённый трейсинг (Jaeger, OpenTelemetry, Sentry Performance) или логирование таймингов внутри запроса.

Пример (Go, обёртка для http.RoundTripper):

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

Шаг 4. Воспроизвести нагрузку

Если проблема зависит от объёма данных, воспроизведите реальный сценарий или нагрузку:

• используйте инструменты вроде k6, Locust, Artillery;
• проверьте реальные условия (например, отчёт за 30 дней, а не за 3).

Если латентность растёт нелинейно, это может быть признаком N+1-запросов, неоптимального SQL или проблем с аллокацией.

Шаг 5. Подтвердить проблему профилированием

Если есть подозрение на перегрузку CPU или утечку памяти, используйте профилировщики:

• Go — pprof;

• Java — JFR, VisualVM;

• Node.js — clinic.js, chrome://inspect.

Пример (Go, локальный pprof):

Профиль покажет, где тратится CPU, как распределяются аллокации, как часто запускается GC и в каком коде.

Шаг 6. Оптимизировать, перепроверить и зафиксировать

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

• кэшировать внешний вызов;

• заменить тяжёлую сериализацию (например, на easyjson в Go);

• убрать блокирующую операцию;

• перейти на batch-обработку.

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

Итоги: как не попасть в архитектурную ловушку

Bottleneck’и возникают даже в самых технологичных проектах. Это не всегда следствие «плохого кода» — куда чаще они появляются из-за архитектурных просчётов: недооценили нагрузку, не предусмотрели масштабирование, сделали ставку на неправильное решение.

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

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

Думайте об объёмах и росте

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

Настраивайте метрики с первого дня

Без данных вы работаете вслепую. Любой анализ будет превращаться в гадание: виноват код или Redis, где тормозит — непонятно. С самого начала следите за ключевыми метриками: latency, очереди, GC, hit/miss в кэше, ошибки. Это не «доработка потом», а часть живой системы.

Проектируйте с учётом деградации

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

Не усложняйте архитектуру без повода

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

Bottleneck’и — это не баг, а симптом. И хороший архитектор — это не тот, кто устраняет тормоза, а тот, кто их не допускает.

Больше боли коддеров — тут.

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

Исходная схема:

• Backend: Spring Boot
• Frontend: Angular

Так как у меня уже был арендованный VDS, я зарегистрировал домен у одного известного провайдера, а хостил сайт уже на VDS сервере. Для простоты интегрировал Angular-сборку в Spring Boot как статику через frontend-maven-plugin. Всё собиралось в один JAR. Почему так? Ранее уже был такой опыт, и я решил пойти этим путем.

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

• Отсутствие SSR в Angular негативно влияло на SEO;
• Ошибка в Angular ломала Maven-сборку;
• Сложно поддерживать и масштабировать.

Переход на микросервисы

Было принято решение разделить фронтенд и бэкенд на отдельные сервисы и использовать микросервисный подход с SSR для Angular:

Новая структура:

• Backend: Spring Boot
• Frontend: Angular Universal (SSR)
• Инфраструктура: Docker Compose, Nginx, HTTPS

Docker, Nginx и запуск

Создана базовая структура docker-compose.yml:

И соответствующий Nginx:

После запуска проект открывался по IP, но появилось множество проблем:

• Дублирование API-префиксов: /api/api/endpoint → Решение: корректировка proxy_pass и URL в Angular
• Редиректы на POST: Spring добавлял лишние слеши → Решение: правильные аннотации и настройка Nginx
• 405 Method Not Allowed → Решение: использовать @PostMapping
• Docker-сети → Решение: задать общую сеть в docker-compose.yml

Безопасность: HTTPS, SSL, CORS

Чтобы сайт открывался по имени с панели провайдера для моего домена, значения DNS-сервера оставил без изменений (провайдер предоставляет их бесплатно), а для ресурсной записи @ и www указал ip адрес своего хостинга. Так как провайдер домена бесплатно предоставил SSL-сертификаты (Let's Encrypt), то как я их интегрировал:

Скачал с панели провайдера и перенес на хостинг такие файлы:

domain.crt — сертификат

domain.key — приватный ключ

ca_bundle.crt — цепочка доверия

Добавил в Nginx такую запись для HTTPS:

Но при обращении к сайту по https конечно же возникли ошибки. А именно: в логах Nginx были ошибки на SSL_CTX_use_PrivateKey_file. Оказалось формат был PKCS#7, а требовался PEM. Конвертировал через OpenSSL:

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

К тому же всегда следует проверять логи Nginx (error.log), там могут находится ответы на вопросы, почему сайт не работает.

На стороне Spring Boot были CORS-проблемы, решено так:

Атаки ботов и защита

После запуска сайта в логах Nginx стали появляться тысячи запросов от ботов, ищущих уязвимости WordPress, PHPMyAdmin и других популярных утилит, хотя мой сайт работает на Java/Angular. Пример лога:

45.155.205.213 - - [01/Jan/2023:04:12:11 +0000] "GET /wp-login.php HTTP/1.1" 404 153

Добавлен фильтр в nginx.conf:

Финальная конфигурация

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

docker-compose.yml

nginx.conf

Dockerfile backend

Dockerfile frontend

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

Основные инструменты и технологии

Статьи, с которых стоит начать, если хочется обновить стек или разобраться в новых подходах:

ТОП 60 лучших инструментов для разработки ПО в 2025 — Собрали шестьдесят лучших инструментов для разработки программного обеспечения в 2025 году. От трекеров и редакторов до библиотек и фреймворков.

Топ 11 трендов, которые нужны айтишнику в 2025 году — Представляем одиннадцать ключевых трендов в IT, которые будут актуальны в 2025 году. Краткий гид по технологиям, которые будут на слуху.

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

Инструменты и фреймворки QA, которые (не) нужно знать — о том, что реально используется в тестировании.

Что изучать начинающему разработчику на C# — рассматриваем языки, среды и подходы, которые пригодятся новичкам. Рекомендуем, с чего начать изучение C# и какие темы освоить в первую очередь.

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

Базы, API, DevOps и CI/CD

Набор инструментов и практик, которые помогут масштабироваться и не выгорать:

Топ-10 инструментов DevOps, которые упростят вашу жизнь и избавят от ночных релизов — must-have решения для DevOps-команд.

PostgreSQL vs. ClickHouse vs. DuckDB: какую опенсорс базу выбрать для аналитики в 2025 году? — Сравниваем три популярные опенсорс СУБД для аналитики: возможности, производительность и кейсы использования.

Семь API, которые сократят вам недели разработки — Подборка решений, которые можно быстро внедрить.

Разворачиваем инструменты CI/CD: практики от DevOps-инженеров — Делимся практическими советами по развертыванию инструментов CI/CD от профессионалов.

Как автоматизировать простые задачи с помощью скриптов? — Гайд по быстрой автоматизации без боли.

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

AI-инструменты и нейросети

Что может помочь вам уже сейчас — от подсказок до генерации кода:

Топ-5 ИИ-инструментов для программистов в 2025 году — Самые полезные AI-ассистенты по мнению редакции.

DeepSeek или Claude: какая нейросеть напишет код, за который не стыдно? — Сравниваем возможности нейросетей DeepSeek и Claude в контексте генерации качественного кода.

Edge AI: как работают нейросети на устройствах с ограниченными ресурсами — Объясняем, как нейросети работают на устройствах с ограниченными ресурсами и где это применимо.

10 способов заработать на искусственном интеллекте в 2025 — Рассказываем о десяти способах монетизации искусственного интеллекта в 2025 году.

Утилиты, лайфхаки и неожиданно полезные штуки

То, что экономит время, силы и нервы:

11 сайтов, экономящих время, которые нужны каждому разработчику — Подборка must-have ресурсов.

7 библиотек для анимаций на React — Обзор популярных библиотек для создания анимаций в React: от простых эффектов до сложных переходов.

30 самых полезных библиотек Python для веб-разработки в 2024 году — Подборка тридцати полезных библиотек Python, которые пригодятся веб-разработчикам в 2025 году.

7 программ для шифрования данных — Базовая кибер-гигиена для всех, кто работает с пользовательскими данными.

Топ самых полезных магических команд для завсегдатаев Colab — Рассказываем, как использовать магические команды в Colab, чтобы ускорить работу с данными и кодом.

5 ETL для обработки данных из Python-ботов — Представляем пять ETL-инструментов, которые помогут автоматизировать сбор, трансформацию и загрузку данных от Python-ботов

Работа с Excel: где он применяется, чем полезен и где освоить этот навык — Объясняем, где и как используется Excel, почему он важен для аналитиков и где научиться работать с ним.

Немного философии

Когда хочется не просто выбрать инструмент, а понять, зачем он вам нужен:

Язык Elixir и функциональное программирование: что это за зверь и почему он хорош для отказоустойчивых систем — Знакомим пользователей с Elixir и его применением.

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

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

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

Кстати! Забрать все самые топовые нейронки для айтишников можно в нашем большом гайде с 70+ ИИ-инструментами

Но правда в том, что это решение подходит далеко не всем компаниям. В 90% ситуаций микросервисная архитектура (она же MSA) — избыточность, а не необходимость. Это не просто сложно, а очень сложно. Микросервисы требуют мощной инфраструктуры, глубоких знаний DevOps, тонкой настройки мониторинга и отказоустойчивости. И самое главное — они редко нужны на старте проекта.

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

Почему все говорят про микросервисы

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

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

Маркетинг на волне хайпа

Разработчики инструментов в этой сфере хорошо зарабатывают на своих продуктах.

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

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

Ориентированность на резюме

Многие разработчики (особенно начинающие) учат микросервисы не потому, что столкнулись с их необходимостью, а потому, что это круто звучит. В итоге в вакансиях пишут «знание Docker/K8s — огромный плюс», а на собеседованиях спрашивают про «опыт работы с распределенными системами», даже если у компании всего лишь сайт-визитка.

Это создает порочный круг:

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

Факт. Несмотря на универсальность микросервисов, далеко не все гиганты перешли на такой формат работы. Например, GitLab и Spotify до сих пор работают на монолитах.

Завышенные ожидания по проекту

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

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

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

В итоге пока вы разбираетесь с Istio и мониторингом, ваш конкурент уже запустит тот же функционал на монолите и получит первых клиентов.

Нужны ли вашему проекту микросервисы

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

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

Действительно ли ваш проект настолько масштабен?

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

Сразу проверьте себя:

• Если ваш сервис — это один API, который обслуживает 5 конечных адресов, микросервисы вам не нужны.
• Если вы не можете четко объяснить, какие части системы могут жить автономно (например, платежи без каталога товаров), значит, у вас монолит. И это нормально.

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

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

Действительно ли вам необходимо масштабировать части приложения автономно?

Типичный аргумент за микросервисы: «У нас нагрузка только на платежи, а не на каталог — выгодно масштабировать их по отдельности». На самом деле 99% стартапов никогда не сталкиваются с такой нагрузкой, где это критично. Кроме того, современные облака (AWS, GCP) умеют масштабировать отдельные модули монолита.

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

Если вы не Amazon — вам, скорее всего, хватит вертикального масштабирования (+1 сервер) или модульного монолита.

Есть ли у вас услуги, связанные с транзакциями?

В монолите транзакция — это пара строк кода. В микросервисах — сложный квест.

Вот как это выглядит:

1. Платежный сервис списал деньги.
2. Инвентарный сервис не ответил (упал или залагал).
3. Теперь у пользователя списаны деньги, но заказ не создан.

Микросервисы создают проблемы согласованности. В монолите вы обновляете данные одной транзакцией, в MSA это стоит в 10 раз дороже.

7 причин не лезть в микросервисы

Значительная часть начинающих прогеров по умолчанию считает, что микросервисы — это прогрессивно и круто. Но они просто не видят подводных камней. На самом деле MSA — это компромисс со сложностью, деньгами и нервами. И не нужно считать, что монолит — это отсталая технология. Решения, касающиеся архитектуры продукта, нужно принимать, основываясь на объективных данных, а не хайпе.

Рассмотрим главные причины, по которым вам не стоит связываться с микросервисами.

Сложность съедает пользу

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

На практике получается следующее:

• Kubernetes (или иной подобный инструмент) становится источником проблем. Вместо написания кода вы теперь разбираетесь, почему поды (базовые строительные блоки) не стартуют, настраиваете контроллеры, обновляете Helm-чарты. Это занимает 30-50% рабочего времени.

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

Команда тратит полгода на переход. Но сервис получает те же 100 запросов в секунду. Только теперь он становится медленнее, сложнее в поддержке, дороже в эксплуатации.

Сложность ради сложности — это точно не про эффективность. Прежде чем переходить на микросервисы, подумайте — готовы ли вы тратить половину времени не на продукт, а на борьбу с инфраструктурой?

Микросервисы не лечат плохой код

У вас есть монолит — большой, тяжелый, с запутанными зависимостями. И вот вы решаете: «Давайте разобьем это на микросервисы!» В теории звучит отлично: каждый сервис — маленький, независимый, аккуратный.

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

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

Нужна подготовленная команда

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

• Без полноценного DevOps или SRE-инженера вы быстро утонете в бесконечной настройке и мониторинге. Это не та работа, которую можно взвалить на бэкендера — она требует специфических знаний и постоянного внимания.
• Когда сервисов становится много, появляется новая головная боль — согласование контрактов между командами. Кто за что отвечает? Как тестировать изменения? Что делать, если один сервис ломает другой? Без четких договоренностей и CI/CD-культуры это превращается в хаос.
• В большинстве стартапов два бэкендера, один стажер и горящие сроки. Они едва успевают пилить фичи, не то что разбираться с продвинутыми практиками DevOps.

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

Деньги тратятся быстрее

Когда речь заходит о микросервисах, многие почему-то забывают простую истину — за все надо платить:

• Без профессионального DevOps-инженера (а хорошие специалисты стоят дорого) ваш «распределенный рай» быстро превратится в ад. Кто будет настраивать Kubernetes, разбираться с падающими подами и оркестрировать логи?
• Базовый мониторинг вроде Prometheus + Grafana — это только начало. Когда сервисов станет много, вам понадобятся системы трассировки и еще десяток инструментов, каждый из которых требует времени и денег.
• Главная скрытая цена микросервисов — время инженеров. В монолите проверка занимает минуты. В мире микросервисов вам сначала придётся поднять пол-инфраструктуры, чтобы просто удостовериться, что код вообще работает.

Для проектов с нагрузкой меньше 100k пользователей микросервисы обходятся в 2-3 раза дороже монолита. И это без учета скрытых затрат — нервов, задержек и упущенных возможностей.

Отладка микросервисов — это головная боль

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

Но в мире микросервисов ошибка может прятаться где угодно: в сервисе А, который не так ответил сервису Б, который передал кривые данные сервису В, а тот и вовсе решил ничего не отвечать. И все это с таймаутами, повторными запросами и загадочными HTTP-статусами.

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

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

Легкого масштабирования не будет

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

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

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

Когда микросервисы все же нужны

Иногда микросервисная архитектура действительно необходима. Но точно не тогда, когда об этом кричат маркетологи или модные блогеры.

Вот три реальных ситуации, когда MSA имеет смысл.

Независимые продукты под одной крышей

Типичный пример — Яндекс. Это не просто такси, но и доставка еды, и грузоперевозки. Абсолютно разные бизнес-процессы, которые разрабатываются отдельными командами, используют разные технологии, масштабируются независимо.

Здесь микросервисы — не прихоть, а необходимость.

Огромные масштабы

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

Технический стек из разных компонентов

Иногда часть системы логичнее писать на Go (где важна скорость), часть на Python (для ML), а часть оставить на JVM (для legacy).

Микросервисы позволяют:

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

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

Итоги

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

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

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

Что вообще такое context collapse

Есть вероятность, что вы слышите этот термин в первый раз. Немного лирики: в мире микросервисов есть два понятия: технический контекст и доменный контекст (Bounded Context).

Технический контекст

Технический контекст — это информация, которая передается между микросервисами для выполнения запросов или операций. В нем лежит большое количество данных: идентификаторы запросов (например, TraceID в трассировке), пользовательские сессии, метаданные или параметры аутентификации.

Без технического контекста микросервисы не могут:

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

Доменный контекст (Bounded Context)

Доменный контекст происходит из методологии Domain-Driven Design (DDD) — это про четкое разделение бизнес-логики между микросервисами. У каждого сервиса должна быть своя «ограниченная область» (Bounded Context), где термины, данные и правила имеют уникальное значение.

Например, в интернет-магазине слово «заказ» может означать разные вещи для сервиса оплаты (финансовая транзакция) и сервиса доставки (отправка покупателю). Если границы контекста не определены четко, возникает путаница: сервисы начинают дублировать логику или интерпретировать данные по-разному.

Без доменного контекста:

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

Вернемся к коллапсу контекста

Автор статьи просит нас представить следующую картину: вы сделали новую архитектуру, она масштабируется, разделяется, деплои проходят гладко, CI/CD пайплайны цветут и пахнут — другими словами, не архитектура, а мечта. Все работает как часы, поэтому вы сидите, попивая кофе и раскладывая пасьянс.

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

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

Что на самом деле происходит

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

Сервис теряет важное состояние, например:

• «Это корзина Пети»
• "Этот платеж уже прошел"

И начинается хаос: дублирующиеся API-запросы, потерянные транзакции или, что еще хуже, повреждение данных.

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

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

Как понять, что контекст вот-вот может «коллапснуться»

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

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

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

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

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

Опрос CNCF за 2024 год показал, что 68% команд, которые используют микросервисы, сталкиваются с необъяснимыми проблемами производительности. И всему виной в том числе контекстный коллапс.

5 решений, как бороться с контекстным коллапсом

Да, контекстный коллапс — крайне неприятный баг. Главное — чтобы все сервисы работали слаженно и «знали» друг друга.

1. Правильно передавайте контекст

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

Вот пример реализации middleware автором на Go:

2. Кэшируйте с умом

Нет смысла заставлять сервисы угадывать, если они просто могут запомнить. Быстрый кэш, например, с Redis, может хранить временный контекст — например, токены сеанса или состояния запросов, — поэтому сервисы не будут постоянно спрашивать «кто это?» Вот фрагмент кода на Питоне, где используется Redis для хранения и извлечения контекста:

Это позволяет поддерживать контекст во всех вызовах, не перегружая вашу базу данных. А еще TTL (time-to-live) Redis сам за собой убирает — устаревшие данные не скрываются.

3. Используйте Event-Driven Architecture

Микросервисы без сохранения состояния выглядят отлично, пока не контекст не коллапснется. Событийная архитектура идет от обратного: вместо того чтобы надеяться, что службы все запомнят, регистрируйте каждый шаг как событие. Если служба все-таки забудет, воспроизведите поток. Вот пример на Node.js с Kafka:

Здесь также можно использовать RabbitMQ. В общем, больше никаких отговорок со стороны сервиса из разряда «я забыл».

4. Проверяйте логи

Когда контекст теряется, логи — ваше место преступления. Настройте Grafana Loki или Datadog для поиска «потерянных контекстов». Вот пример с Grafana:

Тэгните логи с помощью request_id или user_id, а затем вызовите Loki:

5. Тестируйте на коллапсы

Профилактика лучше, чем лечение. Добавьте хаос-тестирование с помощью, например, Chaos Mesh, чтобы моделировать потери контекста.

Хаос-тестирование — это метод преднамеренного введения сбоев в систему, чтобы проверить, насколько она устойчива и надежна. Обычное тестирование и мониторинг могут выявить проблемы, но хаос-тестирование (Chaos Engineering) помогает увидеть, как система поведет себя в случае неожиданных отказов.

Прервите mid-requests к сервисам — сможет ли система восстановится в таком случае? Если нет, значит, ваша передача контекста недостаточно надежна.

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

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

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

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

Рост сложности

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

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

Высокие затраты на инфраструктуру

Монолитное приложение можно развернуть на одном сервере или в простом контейнере.

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

Пример: стартап из 12 человек использовал 87 микросервисов. В результате 60% бюджета уходило на AWS для поддержки этой сложной архитектуры.

Низкая предсказуемость работы

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

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

1. Глобальные сервисы – Netflix, Amazon, Google используют микросервисы из-за огромного количества пользователей и высоких требований к масштабируемости.
2. Разные технологии в одной системе – если одна часть системы требует Python, другая – C++, третья – Java, разделение на микросервисы может быть оправдано.
3. Сильная изоляция сервисов – если разные команды разрабатывают независимые части продукта, микросервисы помогают снизить конфликты в коде.

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

Как избавиться от избыточных микросервисов

1. Аудит архитектуры – если сервис не изменялся 6 месяцев, возможно, он не нужен.
2. Оценка альтернатив – вместо нового микросервиса можно реализовать модуль, библиотеку или просто улучшить код монолита.
3. Оптимизация инфраструктуры – сокращение количества сервисов снижает нагрузку на DevOps и упрощает отладку.

Вывод

Микросервисная архитектура не является универсальным решением.

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

Почему модульность кода — не тренд, а необходимость

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

Без модульности всё разваливается

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

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

Модульность решает множество проблем

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

Упрощает сопровождение кода

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

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

• Разработчики смогут изменять один модуль, не боясь сломать остальную систему;
• Новый человек в команде быстрее разберётся в коде, так как модули работают автономно;
• Логика кода станет прозрачнее: у каждого модуля чётко определённые границы ответственности.

Снижает количество багов, связанных с зависимостями

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

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

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

Делает тестирование проще и быстрее

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

При модульной архитектуре каждый компонент можно тестировать отдельно:

• Юнит-тесты проверяют конкретные модули без запуска всей системы;
• Интеграционные тесты оценивают взаимодействие между модулями;
• Тестирование становится параллельным — можно одновременно проверять разные модули.

Основные принципы модульного кода

Принцип единой ответственности (SRP): каждый модуль выполняет ровно одну задачу

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

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

Если один модуль отвечает сразу за несколько задач, это приводит к нескольким проблемам:

1. Любые правки могут затронуть совершенно несвязанные части кода;
2. Покрыть тестами такой модуль становится сложно, потому что у него слишком много точек отказа;
3. Если модуль выполняет несколько задач, его трудно переиспользовать в других частях системы.

Если нарушить SRP:

Допустим, у нас есть класс OrderProcessor, который должен обработать заказ. Но вместо этого он делает слишком многое:

• Валидирует данные заказа;
• Вычисляет стоимость;
• Обрабатывает оплату;
• Отправляет email-подтверждение.

Что произойдёт, если нам нужно изменить процесс оплаты? Мы рискуем сломать логику валидации или отправки email, потому что всё завязано в одном месте.

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

Теперь каждый класс отвечает только за свою задачу. Изменения в логике оплаты не затронут валидацию или отправку email, а тестировать каждый модуль можно отдельно.

SRP особенно полезен в ситуациях, где код часто меняется и развивается:

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

Слабая связность и высокая когезия: модули взаимодействуют минимально, но логика внутри них цельная

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

Связность (coupling) — степень зависимости одного модуля от другого. Что происходит при высокой связности?

1. Любые изменения ведут к каскадным поломкам — обновление одной части кода требует изменений во множестве других мест.
2. Тестирование становится сложным — чтобы протестировать один модуль, нужно учитывать все его зависимости.
3. Повторное использование затруднено — если модуль слишком тесно связан с кодом, его трудно применять в других проектах.

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

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

Но как уменьшить связность? Нужно использовать инъекцию зависимостей (Dependency Injection) и разделять интерфейсы и реализации:

Теперь OrderProcessor не зависит от конкретной реализации PaymentProcessor. Можно легко подставить другую реализацию, например, PayPalPaymentProcessor или StripePaymentProcessor, без изменений в основном коде.

Перейдем к когезии (cohesion). Это степень связанности логики внутри одного модуля. Если модуль выполняет слишком много разрозненных задач, его сложно понимать и поддерживать. Что происходит при низкой когезии?

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

Например:

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

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

Пример высокой когезии:

Теперь UserManager отвечает только за управление пользователями, а EmailService занимается отправкой писем. Логика каждого модуля цельная и легко расширяется.

Как достичь слабой связности и высокой когезии?

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

Чистые интерфейсы и контрактное программирование: API модулей должны быть понятными и стабильными

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

Чистый интерфейс — это API модуля, которое:

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

• Не перегружено лишними методами;

• Стабильное — изменения API минимально затрагивают пользователей.

Плохой пример:

Этот метод делает слишком много:

• Сохраняет пользователя,
• Отправляет email,
• Логирует активность,
• Обрабатывает override от администратора.

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

Пример чистого API:

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

Контрактное программирование же означает, что каждый модуль:

• Ясно определяет, какие входные данные он принимает;
• Гарантирует ожидаемый результат;
• Защищается от некорректных данных.

Пример контракта в коде:

Здесь чётко определено:

• Если сумма заказа ≤ 0, метод выбросит ошибку.

• Если плата прошла успешно, метод вернёт PaymentResult.Success = true.

Как проектировать чистые интерфейсы?

• API должен быть понятен без чтения документации;

• Чем меньше точек входа, тем проще сопровождать код;

• Если метод принимает bool-флаги, вероятно, его стоит разбить на несколько методов;

• Лучше сделать API чуть менее удобным, но не ломающим обратную совместимость.

Простота в тестировании: возможность заменить модули заглушками и писать юнит-тесты

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

Когда код монолитный и сильно связан, тестирование становится головной болью:

• Один тест может затрагивать десятки зависимостей;

• Невозможно протестировать отдельную функцию без запуска всего приложения;

• Каждый новый баг ломает кучу тестов, потому что код слишком взаимозависимый.

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

Можно заменять реальные модули заглушками (моками, стабами, фейками)

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

Пример без модульности:

Здесь OrderService жёстко завязан на PaymentProcessor, и в тесте мы не сможем подменить его заглушкой.

Пример с модульностью:

Теперь мы можем подменять IPaymentProcessor тестовой заглушкой:

В тесте вместо реального PaymentProcessor подставляем FakePaymentProcessor

Легко писать юнит-тесты для отдельных частей кода

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

Пример юнит-теста с моками:

Здесь мы проверяем, был ли вызван метод ProcessPayment(), но не запускаем реальную оплату.

Можно легко писать интеграционные тесты, используя только нужные связки

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

Пример тестирования API без реальной базы:

Здесь TestDbContext — in-memory база, которая не трогает продовые данные.

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

Как правильно разбивать код на модули?

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

Думайте о модулях с самого начала

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

• Какие ключевые бизнес-объекты в проекте (например, «Пользователи», «Заказы», «Оплата»);
• Какие у них чёткие границы (UserModule не должен отвечать за Payments);
• Какие взаимодействия между ними (какие API вызывают друг друга).

Пример проектирования модульной системы (возьмем e-commerce):

В интернет-магазине можно выделить такие модули:

• UserModule — управление пользователями;
• CatalogModule — товары и категории;
• CartModule — корзина покупок;
• OrderModule — оформление заказов;
• PaymentModule — платежи.

Каждый модуль должен иметь своё API и не лезть в чужие данные напрямую.

Как делать НЕ надо:

Здесь OrderService вмешивается в чужие модули (работает с UserRepository и PaymentService). Это создаёт жёсткую связанность.

Как надо:

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

Выделяйте независимые модули по принципу «Один модуль = одна ответственность»

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

Хорошая практика — модули по бизнес-областям (например, UserModule, OrderModule, PaymentModule)

Пример:

Каждый модуль самодостаточен:

• В user хранятся все файлы, связанные с пользователями;
• В order — всё, что касается заказов;
• В payment — логика работы с платежами.

Минимизируйте связи между модулями: слабая связанность и чёткие контракты

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

• Каждый модуль предоставляет API для взаимодействия;
• Взаимодействие между модулями происходит через интерфейсы или события;
• Модули не лезут друг другу в базы данных.

Пример с хорошими контрактами:

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

Не усложняйте: модульность ≠ миллион мелких файлов

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

Как НЕ надо:

Зачем так делать? Теперь, чтобы просто добавить новый API-метод, нужно создавать новый файл.

Как лучше:

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

Разбить код на модули — это не просто про удобство. Это про гибкость, тестируемость и возможность развития проекта. Удачи с модульностью!

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

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

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

Антипаттерны могут привести к сложному, плохо поддерживаемому или неэффективному коду. Ниже — несколько примеров.

Distributed Monolith

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

В результате:

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

Например, у нас есть три микросервиса: заказы, оплата и пользователи. При этом сервис «Заказы» напрямую вызывает остальные сервисы, и наоборот. Так, если в одном сервисе поменяется API, остальные перестанут работать.

Чтобы исправить, можно использовать, например, асинхронную коммуникацию через Kafka.

Микролиты

Архитектура по идее микросервисная, но каждый микросервис настолько сложный, что превращается в «маленький монолит». Да, у сервиса есть собственная база данных, но код все равно сложно поддерживать и масштабировать.

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

Чтобы не было такой путаницы, упрощайте сервисы и следуйте принципу: «один сервис — одна ответственность».

Многослойность

Архитектура перегружена кучей слоев, например, API → сервис → репозиторий → DAO → DTO → и так далее. Причем каждый слой выполняет какую-то минимальную работу и банально вызывает следующий.

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

А теперь рассказываем, какие паттерны при разработке архитектуры будут эффективными.

Паттерны для предоставления данных и управления

Наиболее популярные паттерны для предоставления данных — MVC, MVVM и MVP. Рассказываем, чем они отличаются.

MVC (Model-View-Controller)

Этот паттерн делит приложение на три компонента: Model — хранит бизнес-логику, View — отображает UI, и Controller — обрабатывает ввод пользователя, следит за Model и View. Работает это так:

Пример — пользователь хочет авторизоваться на сайте:

1. Юзер вводит логин и пароль окно входа — через View.
2. View отправляет данные в Controller.
3. Controller передает логин и пароль в Model, которая проверяет их в базе данных.
4. Model возвращает результат (успешная или неуспешная аутентификация).
5. Controller обновляет View — он выводит либо сообщение, что все успешно, либо ошибку, например, «Неверный логин или пароль».

MVVM (Model-View-ViewModel)

В этом паттерне тоже три компонента, но немного другие: Model — тоже отвечает за логику, View — UI, который поддерживает привязку данных (data binding), ViewModel — преобразует данные Model для View, содержит команды для обработки действий. Вот схема:

Пример — пользователь хочет добавить новую задачу в список.

1. Пользователь вводит новую задачу в поле ввода через View.
2. View автоматически передает данные в ViewModel через двустороннюю привязку.
3. ViewModel обновляет Model, например, заносит новую задачу в базу данных.
4. Model говорит ViewModel, что данные изменились.
5. ViewModel обновляет View, и на экране появляется новая задача, но без явного вызова апдейта интерфейса.

MVP (Model-View-Presenter)

В этом паттерне лежат: Model, View — здесь это пассивный UI, Presenter — посредник между View и Model, плюс в нем есть логика отображения. Работает это вот так:

Пример — приложение, где есть чат.

1. Пользователь набирает сообщение и нажимает «Отправить» или просто кнопку через View.
2. View передает этот текст в Presenter, и он вызывает Model, который отправляет сообщение на сервер.
3. Когда сообщение отправлено, сервер возвращает подтверждение Model, а он говорит об этом Presenter.
4. Presenter обновляет View, добавляя это сообщение в интерфейс.
5. Когда приходит новое сообщение от друга/коллеги, Model получает его из сети и передает Presenter.
6. Presenter обновляет View и отображает новое сообщение в чате.

Мы используем MVC при разработке бэкенда, MVVM — при кодинге на Angular и Vue, а MVP — для разработки UI на Android.

А для управления данными можно использовать:

• Repository — абстрагирует доступ к данным и минимизирует зависимость от конкретной базы данных.

Важно разделять Repository на несколько интерфейсов (interface segregation). Для транзакций в распределенных системах можно использовать Saga или outbox + event bus.

• Unit of Work — контролирует транзакции на уровне логики.
• Active Record — связывает объекты с таблицами баз данных и просто упрощает работу.

Паттерны распределительных систем

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

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

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

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

Пример

В приложении онлайн-магазина могут быть такие сервисы — User/Client Service, Product Order Service и Payment Service. Очевидно, что такой паттерн подойдет только большим приложениям, поэтому использовать микросервисы ради того, чтобы использовать — бессмысленно. В таком случае лучше остановиться на монолите.

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

Чтобы микросервисы работали четко, нужно грамотно организовать мониторинг, логирование и управление конфигами. Плюс нужен Kubernetes и API-шлюзы.

Event-driven архитектура

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

Event-driven архитектура — это подход, при котором компоненты системы взаимодействуют через события. Сами события генерируются при изменении состояния системы и обрабатываются нужными компонентами.

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

Пример

Тот же самый интернет-магазин:

1. Пользователь создает заказ (создается событие).
2. Сервис уведомлений отправляет, например, пуш или письмо юзеру.
3. Сервис склада бронирует товары.
4. Сервис оплаты проводит транзакцию.

CQRS (Command Query Responsibility Segregation)

CQRS — это паттерн, который разделяет логику команд и запросов. Для чтения (Query) и записи (Command) используются разные модели данных — так можно оптимизировать каждую операцию.

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

Пример

Это может быть большой блог или медиа. Работать будет так:

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

Эти паттерны часто используются вместе. Например, в микросервисной архитектуре можно применять Event-driven подход, чтобы взаимодействовать между сервсами, а CQRS — для оптимизации операций чтения и записи.

Паттерны для масштабируемости

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

Circuit Breaker

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

Например, вы делаете покупку на маркетплейсе, и у в нем упал платежный сервис. В таком случае Circuit Breaker временно блокирует запросы и говорит пользователю, что нужно попробовать оплатить позже.

Load Balancer

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

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

Retry (exponential backoff with jitter)

Паттерн нужен для повторения идемпотентного действия, которое завершилось безуспешно. Так, некоторые ошибки бывают кратковременными, и вместо немедленной блокировки запроса, Retry позволяет повторить запрос, но с увеличенным интервалом между попытками (экспоненциальная задержка). А добавление случайного разброса времени (jitter) помогает избежать ситуации, когда все запросы повторяются одновременно, вызывая новую перегрузку.

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

Паттерны безопасности

• OAuth 2.0 — стандартное решение. Он позволяет пользователям предоставлять доступ к своим данным сторонним сервисам без передачи пароля. Например, зарегистрироваться на сайте через Google, Яндекс или VK.
• TLS (Transport Layer Security), криптографический протокол, шифрует данные при передаче.
• AES один из самых надежных алгоритмов симметричного шифрования. Его часто используют в базах данных или кеше.
• Token-based Security — безопасная аутентификация с JWT. В основе лежит цифровая подпись (обычно HMAC или RSA) — она гарантирует подлинность данных.
• В финтехе используют HSM для генерации и защиты криптографических ключей на аппаратном уровне.

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

И поскольку даже опытные разработчики сталкиваются с дилеммами при выборе подходящей модели, на Solvery вы можете разобрать ваш проект и получить обратную связь от архитекторов и разработчиков уровня Яндекса, Авито и Т-Банка.

Если хотите сохранить короткую версию статьи — у нас есть она в ВК.

Я — Даниил Динько, веду свой личный телеграм-канал, где рассказываю о себе, об IT и о Golang. Также являюсь экспертом и спикером в компании Эйч Навыки, TeamLeadом в компании-лидере в международном кибербезе, ex. старшим разработчиком в Ozon Tech. Вместе разбираемся, что объединяет Go-разрабов каждого грейда.

А почитать о том, как сейчас стать Go-разрабом, можно в предыдущей статье.

Навык собеседований vs. навык работы

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

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

Теперь разберем, что требуется от Go-разработчиков на каждом уровне.

Что нужно с точки зрения навыка собеседований

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

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

Грейд: Junior

Сейчас на рынке Go очень много джунов — он перегрет, и попасть в компанию без коммерческого опыта будет крайне сложно. Более того, от начинающих разработчиков ждут немало знаний и навыков. О них — ниже.

Углубленное знание Go

• Уметь абстрактно рассказать про очереди в планировщике.
• Знать про мапу под капотом: как устроено хеширование, коллизии и разрешение конфликтов.
• Уметь решать задачи по concurrency на относительно базовом уровне (воркер пул) и на слайсы
• Понимать принципы работы горутин и каналов.

Базы данных

• Знать виды баз данных и рассказать про максимальное количество юзкейсов из опыта с разными типами данных.
• Знать индексы и ACID и уметь их базово писать.
• Знать SQL, уметь составлять схемы и идейно понимать, как работают самые известные базы — PostgreSQL, ClickHouse.
• Понимать репликацию и шардирование

Системный дизайн

Да-да, теперь даже джуну нужно иметь абстрактное понимание сисдиза:

• Монолит vs. микросервисы: знать плюсы и минусы каждой архитектуры.
• Знать варианты коммуникаций между сервисами (брокеры сообщений, REST API, gRPC).

Алгосы и Computer Science

• Уметь решать медиум-задачки на LeetCode. Фокус при этом на задачах со слайсами, деревьями и графами.
• В Computer Science — знать про устройство Linux, планировщик, потоки/процессы, а еще про устройство сети — OSI, TCP/IP, протоколы и т.д.

Также в некоторых компаниях сейчас ко всему этому требуют еще и знание Kubernetes.

Вот здесь собрал дорожную карту, как влиться в IT на примере Go. Из полезных ссылок:

1. Один из лучших курсов по Go на Youtube
2. Крутой урок по системному дизайну
3. Все про каналы в Go

А здесь можно посмотреть, как джуну стать мидлом.

Грейд: Middle

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

Go

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

Базы данных

• MVCC,
• Проблема разбухания индексов,
• Селективность,
• Шардирование на уровне реальных решений основной проблемы решардинга — Consistent Hash,
• Реприликация и паттерн Raft.

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

Сисдиз

Нужно знать про паттерны межсервисного взаимодействия: Saga, Transactional Outbox, Circuit Breaker. На мидла могут уже спокойно давать практические задачи на внедрение каких-то идейных дизайнерских штук, например, идемпотентности.

Алгосы и Computer Science

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

Грейд: Senior

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

Go

Нужно знать библиотеку Reflection со всякими приколами, которые могут ускорить concurrency. Также разбираться в аренах памяти и планировщике.

Сисдиз

В паттернах межсетевого взаимодействия история с обычным рассказом не пройдет — юзкейсы здесь must-have. Поэтому важно уметь проходить System Design-интервью — собирать функциональные и нефункциональные требования, считать нагрузку, проектировать на разных уровнях абстракции, углубляться и решать проблемы в своей же архитектуре. Это сложно, и без хотя бы косвенного соприкосновения с проектированием, будет непросто. Поэтому в качестве совета — стремитесь максимально участвовать на архитектурных сессиях и грумингах, будучи мидлом.

Базы данных

Будет круто знать, как под капотом реализован, например, PostgreSQL: как он поднимает что-то в буфер, как хранит данные на диске, что такое чекпоинты и бэкапы и как реализована MVCC.

В случае с ClickHouse лучше верхнеуровнево понимать LSM-дерево, а с ElasticSearch — инвертированные индексы.

Алгосы и Computer Science

Алгоритмы уже почти не играют роли в большинстве компаний, а Computer Science требуется примерно на том же уровне, что и на джуна. Единственное — в Linux могут чуть капнуть.

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

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

• Собес ≠ работа. Принято считать, что знания, требуемые на собеседовании, пригодятся в работе — это не так. За несколько часов невозможно полностью оценить кандидата, поэтому интервью строятся на проверке общих знаний и концепций.
• Почему спрашивают про планировщик? Банально узнают софты.
• Жесткая конкуренция. Все просто: знание — сила.

Что нужно с точки зрения реальной работы

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

• Грейд Junior. Нужно уметь делать максимально базовые задачи. Например, добавить поле или прокинуть фича-флаг. Или же при курировании и ревью быть мотивированными. Этого достаточно. Да, как бы грустно это ни звучало, здесь по классике предполагается, что тебе нельзя доверить что-то серьезное без сторонней помощи.
• Грейд Middle. Относительно безболезненно брать на себя полноценные части продукта в зону ответственности, фича-лидить. Здесь предполагается, что ты можешь действовать относительно самостоятельно, приходя с вопросами лишь иногда. Тут уже желательно участвовать в каких-либо технических обсуждениях.
• Грейд Senior. Здесь нужно разрабатывать фичи любого уровня сложности под ключ. Тебе достаточно предоставить бизнес-требования, сходить с ними по командам с экспертизой. Затем спроектировать качественную архитектуру, которая развалится с минимальной вероятностью, самому реализовать и принести лиду таску в Done. Здесь также важно менторить сотрудников, активнейшим образом участвовать на грумингах и любых других технических созвонах.

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

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

Pub/Sub помогает создавать надёжные и быстрые приложения, даже если пользователей много. О том, как это работает, читайте ниже.

Что внутри Pub/Sub

Чтобы было проще понять, как устроена архитектура Pub/Sub, приведём простую аналогию. Представьте, что у вас есть канал в Telegram. Автор канала (Publisher) пишет сообщение, а все участники (Subscribers) его получают. Если один из подписчиков покидает канал или кто-то, наоборот, присоединяется, автору ничего не нужно менять — он, как и раньше, публикует посты, уведомления о которых приходят всем, кто подписан на этот канал.

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

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

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

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

1. Издатель отправляет сообщение (например, текст или видео) в определённый канал — он называется темой (Topic).
2. Получатели подписываются на нужную тему, чтобы принимать эти сообщения.
3. Как только сообщение отправлено в тему, все подписчики его получают.

Этот процесс проиллюстрирован на следующей схеме:

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

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

Итак, почему же эта архитектура так удобна?

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

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

Теперь для наглядности приведём пример простого кода брокера.

Пример кода брокера на Python

Код можно написать на разных языках, но для примера мы возьмем Python — просто потому, что его легче понять. Мы используем популярную библиотеку для работы с очередями — asyncio. А чтобы продемонстрировать случайную задержку при обработке сообщений, используем библиотеку random.

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

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

Как выбрать инструменты для реализации Pub/Sub

Как мы уже сказали, брокера для Pub/Sub можно написать на разных языках с использованием дополнительных библиотек. Выбор зависит от масштаба проекта, специфики, количества пользователей.

Рассмотрим наиболее популярные инструменты.

Apache Kafka

Это платформа для обмена данными между приложениями в реальном времени. Она позволяет передавать большие объёмы информации быстро и надёжно — можно не переживать, что данные будут потеряны.

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

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

Вот где используют Apache Kafka:

• LinkedIn использует Kafka для передачи сообщений между микросервисами.
• Netflix применяет Kafka для контроля количества событий, обрабатываемых одновременно, и передачи данных из нескольких потоков.
• The New York Times использует Kafka для публикации новостей в режиме реального времени.

Приведём пример простой публикации и получения сообщений (учитывайте, что у вас должна быть установлена соответствующая библиотека и запущен Apache Kafka на локальном сервере или в облаке):

Producer отправляет сообщения в Kafka в определённую тему (в нашем случае — test_topic). Consumer подписывается на эту тему и получает сообщения.

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

RabbitMQ

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

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

RabbitMQ работает как почтовая служба:

1. Одно приложение отправляет сообщение (письмо).
2. RabbitMQ принимает это сообщение и сохраняет его в очереди.
3. Другое приложение (подписчик) получает сообщение из этой очереди.

Особенность RabbitMQ — push-модель. Брокер сам отправляет сообщения получателю сразу, как только они появляются. Получателю не нужно запрашивать данные постоянно — он просто ждёт, пока RabbitMQ пришлёт новые сообщения.

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

Покажем пример (RabbitMQ можно подключить к Python с помощью библиотеки pika):

Вот как это работает:

Сначала Producer отправляет сообщение в очередь test_queue. Затем Consumer подписывается на эту очередь и получает сообщения. RabbitMQ принимает сообщение и доставляет его получателю сразу после появления в очереди (та самая push-модель).

Redis

Система управления данными, которая поддерживает не только стандартную очередь сообщений, но и паттерн Pub/Sub. Этот инструмент используют для организации обмена сообщениями, при этом он хранит промежуточный контент (например, набранный, но не отправленный текст), управляет базами данных небольших приложений и одностраничных сайтов.

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

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

Примеры реализации Pub/Sub

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

Рассмотрим наиболее актуальные области применения шаблона.

Мониторинг системы и мгновенная отправка уведомлений

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

Вот пример сценария:

1. В крупномасштабной системе мониторинга серверов сообщения о сбоях отправляются в специальный канал.
2. Система визуализации Grafana или Prometheus подписана на этот канал и сразу обновляет дашборды.
3. В случае критического сбоя на основной системе резервный сервер автоматически включается через подписку на ту же тему.

Pub/Sub позволяет внедрить автоматические реакции на определенные события. Например, если загруженность сервера превышает 90%, система может отправить сообщение об аварийном переключении нагрузки или даже автоматически включить дополнительные вычислительные узлы.

IoT (Интернет вещей)

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

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

Для лучшего понимания приведём пример:

1. Датчики движения отправляют сообщения в тему «Безопасность».
2. Подписчик — система управления домом — принимает эти сообщения и отправляет уведомления на мобильное приложение пользователя.
3. Тем временем умная лампа подписана на другой канал и автоматически включается по сигналу о движении.

Pub/Sub обеспечивает масштабируемость IoT-систем — новые устройства можно легко подключать к существующим темам, не нарушая работу всей архитектуры.

Резервное копирование

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

1. Каждую ночь системы баз данных отправляют уведомление в тему «Резервное копирование».
2. Подписчик (облачный сервис хранения) получает это сообщение и инициирует процесс копирования данных.
3. Если основной сервер недоступен, сообщение передаётся на резервный сервер, который берёт на себя задачу сохранения.

Также Pub/Sub позволяет настроить многоуровневое резервирование: копии данных могут одновременно отправляться на несколько хранилищ, что и позволяет минимизировать риски потери информации.

Преимущества и недостатки использования Pub/Sub

Давайте кратко пройдёмся по основным плюсам этого паттерна:

• Систему легко адаптировать под любое количество пользователей. Новых издателей и подписчиков можно добавлять без потери производительности, а архитектуру тем и посредников менять без затрагивания базовых компонентов.
• Издатели и подписчики работают независимо друг от друга. Это позволяет создавать безопасные, модульные системы, где компоненты не зависят от прямых связей и могут развиваться отдельно.
• Pub/Sub можно использовать с разными языками программирования (например, Python или Java) и интегрировать с различными брокерами сообщений.
• Сообщения доставляются мгновенно, что делает Pub/Sub идеальным решением для сервисов реального времени.
• Сообщения дублируются в хранилищах для гарантированной доставки. Дополнительно обеспечивается проверка подлинности издателей и шифрование данных для защиты информации.

У паттерна есть и недостатки. Он слишком сложен для использования в небольших приложениях, требует грамотной настройки и сопровождения. Если продукт не нуждается в масштабировании, то применение Pub/Sub — неоправданная трата ресурсов. Не всем системам требуется такой уровень сложности и надёжности.

Для потоковой передачи медиафайлов Pub/Sub — не лучший выбор, поскольку работает в асинхронном режиме. Для конференций в формате видео, голосовых коммуникаций по протоколу IP технология не подойдёт.

Итоги

Pub/Sub — это эффективный и сравнительно простой способ организовать обмен данными между компонентами системы. Он лежит в основе работы распределённых приложений с микросервисной архитектурой и обеспечивает передачу информации в реальном времени.

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

Определение и особенности монолитной архитектуры

Что такое монолитная архитектура и какие у неё основные характеристики

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

Основные характеристики:

• Единое хранилище кода и структур данных.
• Тесная взаимосвязь компонентов: изменения в одном модуле часто требуют обновлений в других.
• Унифицированное развертывание: приложение разворачивается в одном контейнере или среде.

Плюсы монолита

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

Минусы монолита

• Сложность масштабирования. Масштабирование требует копирования всего приложения, даже если нужно повысить производительность только одной его части. Плюс если высокую нагрузку испытывает лишь одна часть приложения, увеличивать производительность приходится для всей системы.
• Зависимость компонентов. Любое изменение в одном модуле может привести к непредсказуемым последствиям в других частях системы. К тому же трудно изолировать ошибки и снижать взаимные влияния между частями приложения.
• Долгосрочная поддержка. Переход на новые технологии требует переработки всей системы. Например, если монолитная архитектура построена на устаревшей версии фреймворка, переход на более современный инструмент требует изменений во всех связанных модулях, включая базу данных, пользовательский интерфейс и 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. Вы не уделяете внимание безопасности

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

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

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

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

Узнаем, каковы принципы и основы событийной архитектуры ПО, каковы преимущества и недостатки такой структуры, как работает 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 архитектуру.

Как выглядит наша CRM-система

Мы используем микросервисную архитектуру, микросервисы в основном написаны на Java. Маршрутизатором трафика работает Traefik: он собирает в себя все запросы и определяет, в какой микросервис, в какой API, отправлять реквест. Схема работы выглядит так:

Клиент —> Traefik —> (mcp-api-cleaner, mcp-reseration, mcp-proressing)

Микросервисы взаимодействуют с NoSQL и Redis, из которой информация попадает в топики Kafka и дальше в mySQL. Данные хранятся до 90 дней и после удаляются.

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

Redis взяли по нескольким причинам

Первая: в банковском секторе нужна скорость. Вторая — у Redis быстрое и удобное взаимодействие с Java. Третья — это очень популярная система управления базами данных и применяется во многих компаниях.

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

Мы тоже столкнулись со сложностями

При экспоненциальном росте нагрузки на CRM-систему Redis переполнялся и падал с неопределенной периодичностью. Изучив проблему, мы поняли, что в базе копятся записи с одинаковым ключом.

Например, мы провели тренинг, на котором сотрудники выполняли одни и те же действия: зашли в профиль, выполнили задачи А и Б и так далее. Система проанализировала контакты и объединила пользователей по интересам. В результате мы получили дерево из тысяч записей с одинаковым ключом. Мало того что это увеличило нагрузку на аналитическую систему и замедлило работу приложения, так еще и подвергло риску отказоустойчивость внутри контура банка.

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

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

Последняя идея, пришедшая к нам, была такой: искать высоконагруженные ID в mySQL и уже потом удалять их из Redis. Но это бы тоже не сработало, потому что постоянно сканировать счетчик ID долго и дорого.

Не найдя комфортного решения на текущей архитектуре, мы начали и тестировать другие инструменты

Взяли MongoDB, это тоже NoSQL база данных, которая хранит информацию не в кэше, а в формате BSON, в виде документов, содержащих пары ключ-значение. Мы сравнили скорость работы с Redis и выяснили, что MongoDB работает медленнее. Поэтому остановились на компиляции Redis и MongoDb с помощью паттерна Cache aside. На тестирование ушло несколько месяцев.

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

Клиент в это время получает информацию из MongoDB (да, информация придет чуть позже, это медленнее процентов на 15, но решает проблему с нагрузкой).

На перформансе, при частых запросах, потерь в скорости почти нет: даже если данные успели стереться из Redis, они не превышают 10%. В дальнейшем данные уже попадают в Redis, и скорость возвращается.

Так мы решили проблемы с нагрузкой

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

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

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

Пример конкретной задачи: Банк А принимает оплату только в PLN (польский злотый), но покупатель готов оплатить это только картой с валютой EUR. Нам необходимо определить сумму в PLN для отправки запроса к банку-эквайру. Какие есть варианты решения этой задачи?

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

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

Пример 1: У вас карта в евро. Вы совершаете покупки в отпуске в Италии тоже в евро. Сумма покупки — 50 евро, итого с вашего счёта спишется 50 евро.
Пример 2: У вас карта в евро. Вы совершаете покупку в Польше в польских злотых. В этом случае схема пересчёта следующая: польские злотые (PLN) → пересчитываются в USD по курсу Mastercard, далее USD → пересчитываются в CNY по курсу Mastercard, затем CNY → пересчитываются в евро по курсу банка.

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

1. “Mastercard” PLN -> USD
2. “Mastercard” USD -> CNY
3. “Альфа-Банк Беларусь” CNY -> EUR

С такими вводными приступаем к анализу рынка…

Анализ рынка

Напомню, мы выделили основные критерии поиска:

1)Быстрая обработка большого объема запросов для получения курсов валют и готовых результатов конвертации.
2)Возможность создания собственных стратегий конвертации, учитывая различные особенности, например, принятие оплаты в одной валюте и конвертацию в другую.

Xe:

+ быстрый и удобный API

+ есть возможность выбора источника курса валют (но на данный момент только центральные банки нескольких стран, что недостаточно для моего кейса)

+ есть курсы криптовалюты

– дорого

– нет возможности создания собственных стратегий для конвертации

Openexchangerates:

+ быстрый и удобный API

+ приятная цена

– нет возможности создания собственных стратегий для конвертации

– нет возможности выбрать источник курса

Currencylayer:

+ быстрый и удобный API

+ приятная цена

– нет возможности создания собственных стратегий для конвертации

– нет возможности выбрать источник курса

Coinlayer:

+ быстрый и удобный API

+ приятная цена

+ есть курсы криптовалюты

– нет возможности создания собственных стратегий для конвертации

– нет возможности выбрать источник курса

Fixer:

+ быстрый и удобный API

+ приятная цена

– нет возможности создания собственных стратегий для конвертации

– нет возможности выбрать источник курса

Изначально выбрал https://openexchangerates.org и использовал именно его, но достаточно быстро появились новые бизнес-кейсы, такие как пример с “Альфа-Банк Беларусь” и покупкой в PLN, когда этого функционала перестало хватать. Об этом упоминалось выше.

Все сервисы имели почти одинаковый набор плюсов и минусов, но главное, что ни один из них не имел того, что требовалось мне. С этого момента произошло разочарование из-за отсутствия нужного инструмента, но с другой стороны появилось вдохновение от возможности создать то, что будет работать именно под мою конкретную задачу. Благодаря этому анализу у меня возникла некоторая насмотренность на то, как крупные игроки рынка делают свои API. Поэтому в моей голове уже начала складываться база того, как это должно выглядеть: source_currency, target_currency, amount, base_currency, и поехали, думал я. Но как я ошибался, что этим все ограничится.

Разработка

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

• /api/v1/rates – эндпоинт, который позволяет получать курсы валют, указывая необходимые параметры.

• /api/v1/conversions – этот эндпоинт выполнит конвертацию в соответствии с указанной стратегией, учитывая все соответствующие правила и параметры конвертации.

• /api/v1/conversion_strategies – для создания стратегии конвертации валют.

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

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

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

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

P.S. Сам микросервис я трансформировал в отдельное API, к которому теперь есть доступ не только у меня. Если кто-то захочет использовать его или просто “потыкать палкой”, то велкоме: https://irates.io.

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

Эта статья предназначена для профессионалов в сфере IT, стремящихся расширить свои знания в области оптимизации работы бэкенда. Ниже мы в деталях рассмотрим, что такое OpenTelemetry, из каких ключевых концептов она состоит, и какие проблемы помогает решить. Если вам интересно, как OpenTelemetry может изменить подход к мониторингу и отладке ваших бэкенд-систем, повысив их надежность и эффективность – читайте дальше!

OpenTelemetry — важный слой наблюдаемости, но не вся картина целиком. Если нужен полный маршрут DevOps-инженера и место observability в нём, посмотрите Roadmap DevOps-инженера в 2026 году: что учить и в каком порядке.

Коротко об истории OpenTelemetry

Первыми с проблемой распределенного логирования и трейсинга столкнулись крупные технологические компании еще в конце 2000-х годов. В 2010 году Google опубликовал статью "Dapper, a Large-Scale Distributed Systems Tracing Infrastructure", послужившую основой для разработки компанией Twitter инструмента трейсинга - Zipkin, который был выпущен в 2012 году.

Затем, в 2014 году, появился Kubernetes, который значительно упростил разработку микросервисов и других облачных распределенных систем. Это привело к тому, что все большее количество компаний начало сталкиваться с проблемой распределенного логирования и трейсинга в микросервисах. Для стандартизации распределенного трейсинга был создан стандарт OpenTracing, принятый CNCF, а также проект OpenCensus от Google, решающий ту же задачу.

В 2019 году проекты OpenTracing и OpenCensus объявили об объединении под названием OpenTelemetry. Полученная платформа объединяет лучшие практики, накопленные за много лет, и позволяет с минимальными усилиями интегрировать трассировку, логирование и метрику в любые системы, независимо от их сложности.

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

А что внутри?

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

Контексты

OpenTelemetry вводит понятие контекста операции. Контекст в первую очередь включает в себя атрибуты trace_id (идентификатор текущей операции) и span_id (идентификатор подзапроса, при ретраях каждый подзапрос, например, должен иметь уникальный span_id). Кроме того, контекст может содержать статическую информацию, такую как название ноды, на которой развернуто приложение, или название окружения (prod/qa). Такие поля в терминологии OpenTelemetry называются resource и прикрепляются к каждому логу, метрике или трассировке для более удобного поиска. Дополнительно в контексте могут содержаться динамические данные, например, идентификатор текущего эндпоинта ("http_path": "GET /user/:id/info"), которые могут быть выборочно прикреплены к группе логов, метрик или трассировок.

Контексты OpenTelemetry могут передаваться между различными приложениями с использованием протоколов context propagation. Эти протоколы представляют собой наборы заголовков, которые добавляются в каждый HTTP- или gRPC-запрос, или же в заголовки сообщений для очередей. Это позволяет нижестоящему приложению восстановить контекст операций из этих заголовков.

Можно выделить следующие виды передачи контекста:

• B3-Propagation: Это набор заголовков вида x-b3-*, изначально разработанный для системы трассировки Zipkin. Он был адаптирован в OpenTracing и использовался многими инструментами и библиотеками. B3-Propagation обеспечивает передачу trace_id/span_id, а также флага, указывающего на необходимость семплирования;
• На смену ему пришел стандарт W3C Trace Context: Разработанный рабочей группой W3C. Он объединяет в себе практики различных подходов к контекстному распространению в единый стандарт и этот подход является стандартным в OpenTelemetry.

Tracing

Трейсинг - это процесс записи и последующей визуализации таймлайна пути запроса через несколько приложений.

На визуализации каждая полоска называется "span" и имеет идентификатор "span_id". Корневой span называется "trace" и имеет идентификатор "trace_id", который служит идентификатором всего запроса.

Такая визуализация позволяет:

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

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

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

Logs

Логирование, несмотря на свою кажущуюся тривиальность, остается одним из наиболее мощных инструментов для диагностики проблем. OpenTelemetry расширяет возможности традиционного логирования, добавляя контекстную информацию. В частности, при наличии открытого трейса к логам автоматически добавляются атрибуты trace_id и span_id, позволяющие связать логи с таймлайном операций. Кроме того, в качестве атрибутов лога можно использовать как статическую информацию из контекста OpenTelemetry – например, идентификатор ноды, так и динамическую информацию – например, идентификатор текущего HTTP-эндпоинта ("http_path": "GET /user/:id").

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

Metrics

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

Коллекторы метрик OpenTelemetry совместимы со стандартами выгрузки метрик Prometheus и OpenMetrics, что обеспечивает возможность легкого перехода на решения OpenTelemetry без необходимости внесения значительных изменений. SDK OpenTelemetry позволяет вместе с метриками выгружать примеры trace_id, чтобы была возможность связывать метрики с примерами логов и трейсами.

Связь между сигналами

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

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

Помимо этих трех компонентов, OpenTelemetry включает в себя концепции Sampling, Baggage и управления контекстом операций.

Sampling

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

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

Для решения этой проблемы механизмы распространения контекста OpenTelemetry передают флаг семплирования вместе с trace_id/span_id. Это необходимо для того, чтобы, если сервис, первый принявший запрос от пользователя, решит, что запрос должен быть выгружен подробно, все остальные системы также должны следовать этому решению и также выгружать данные подробно. В противном случае все системы должны выгружать сигналы частично или не выгружать вовсе, чтобы сэкономить ресурсы. Такой подход называется "Head Sampling" - решение принимается в начале обработки запроса случайно или на основе каких-то входных атрибутов.

Кроме этого, OpenTelemetry поддерживает режим "Tail Sampling", при котором все приложения всегда выгружают все сигналы подробно, но существует некоторый промежуточный буфер. После получения всех данных этот буфер принимает решение о том, стоит ли сохранить данные полностью или оставить лишь частичную выборку. Такой подход позволяет сохранить более репрезентативную выборку по каждой категории запросов (успешные/долгие/ошибочные), но требует настройки дополнительной инфраструктуры.

Baggage

Механизм Baggage позволяет вместе с trace_id/span_id передавать произвольный набор пар ключ-значение, который автоматически будет передаваться между всеми микросервисами по ходу обработки запроса. Этот механизм полезен для передачи дополнительной информации, которая необходима на протяжении всего пути запроса – например, для передачи информации о пользователе или настройках среды выполнения.

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

tracestate: rojo=00f067aa0ba902b7,congo=t61rcWkgMzE,userId=1c30032h5

Вот несколько примеров использования Baggage:

• Передача бизнес контекста операции, такого как userId, productId, deviceId, через все микросервисы. Такую информацию приложения могут автоматически логировать, чтобы получить возможность искать логи любого приложения по контексту юзера, совершившего оригинальный запрос;
• Специфичные настройки параметры для SDK или инфраструктуры;
• Флаги, по который балансировщики могут принимать решение о роутинге запроса – такой подход можно использовать, чтобы автоматически роутить некоторые запросы на mock бекенды во время тестирования. Т.к. baggage передается автоматически – не надо придумывать дополнительных протоколов, достаточно настроить правило на балансировщике.

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

Имплементация

С точки зрения инфраструктуры

Имплементация OpenTelemetry на уровне инфраструктуры требует интеграции бекендов OpenTelemetry в архитектуру приложений и настройки инфраструктуры для агрегации данных и состоит из четырех этапов:

1. Интеграция с приложениями. На первом этапе SDK или агенты OpenTelemetry интегрируются непосредственно в приложения для сбора метрик, логов и трассировок. Это обеспечивает непрерывный поток данных о работе каждого компонента системы.
2. Конфигурация экспортеров. Собранные данные направляются из приложений через экспортеры во внешние системы для дальнейшей обработки. Это могут быть системы логирования, мониторинга, трассировки или аналитики, в зависимости от ваших потребностей.
3. Агрегация и хранение. На этом этапе может происходить нормализация данных, обогащение их дополнительной информацией и слияние данных из разных источников для создания единого представления о состоянии системы.
4. Визуализация данных. Наконец, обработанные данные представляются в виде дашбордов в таких системах, как Grafana (для метрик и трассировок) или Kibana (для логов). Это позволяет командам быстро оценивать состояние системы, выявлять проблемы и тенденции, а также создавать алерты на основе созданных сигналов.
   

С точки зрения приложения

Для интеграции с приложением необходимо подключить SDK OpenTelemetry для соответствующего языка или использовать библиотеки и фреймворки, имеющие прямую поддержку OpenTelemetry. OpenTelemetry часто предоставляет свои реализации широко используемых интерфейсов известных библиотек, что позволяет осуществить drop-in замену. Например, в мире Java для сбора метрик часто используется библиотека Micrometer. SDK OpenTelemetry предоставляет свои реализации интерфейсов Micrometer, что позволяет заменить выгрузку метрик без изменения основного кода приложения. Кроме того, OpenTelemetry предоставляет реализации старых интерфейсов OpenTracing и OpenCensus, что позволяет максимально безболезненно мигрировать на OpenTelemetry.

В заключение

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

Ошибка 1. Нет четких границ между слоями приложения

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

Можно выделить три базовых уровня:

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

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

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

Ошибка 2. Игнор масштабирования с первого дня

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

Важно сразу закладывать в архитектуру точки роста, даже если пока они не нужны на каждый день.

Например:

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

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

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

Ошибка 3. Преждевременное усложнение архитектуры

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

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

Упрощённая архитектура на старте позволяет команде сосредоточиться на продукте: монолит с чёткими слоями (контроллеры, сервисы, репозитории) куда быстрее дорабатывается и легче деплоится, чем микросервисы с отдельными контурами.

Что можно делать:

• Запускать монолит на FastAPI или Django, а не дробить на микросервисы до появления реальных узких мест.
• Использовать Postgres без брокеров событий, пока не появятся требования к масштабированию.
• Добавлять кэш Redis точечно, когда видна реальная нагрузка, а не вслепую кэшировать каждый запрос.

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

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

Ошибка 4. Непродуманная работа с зависимостями

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

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

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

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

Например, при работе с Python удобным подходом будет использование Poetry: можно зафиксировать версии зависимостей в pyproject.toml, автоматически создавать lock-файл, следить за актуальностью библиотек и легко пересоздавать окружение. Если проект запускается на CI/CD, можно установить точные версии и сразу выявить, где обновление ломает тесты.

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

Ошибка 5. Нет стратегии управления состоянием

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

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

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

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

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

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

Без стратегии управления состоянием проект становится сложным в отладке и поддержке. Грамотное управление состоянием ускоряет разработку и снижает количество багов в будущем.

А какие ошибки допускаете вы? Делитесь в комментариях или в тг-канале Веб-страница.

В статье основной упор делается на приготовление одного из рецептов CI в монорепозитории, прохождение по стадиям настройки Spring Cloud Gateway, в конце добавлена щепотка мониторинга — подключение Sentry к микросервисам.

Данная статья является продолжением статьи:

Код статьи размещён в монорепозитории:

Автор: Александр Леонов, руководитель группы разработки одной из распределенных команд Usetech.

Дисклеймер:

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

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

Для начала проведём подготовку со стороны кода, выделив в отдельные модули важные части (будем дробить по бизнес-ценности), затем изолируем модули друг от друга и сделаем их самостоятельными. Spring Boot приложениями. В итоге, проект будет выглядеть так:

Отлично, теперь у нас есть 4 отдельных разрозненных микросервиса, которые разные и под которые нужно переделывать фронт. Но нам, по возможности, этого бы не хотелось, поэтому пришла идея использовать Spring Cloud Gateway. Но не стоит сразу с места в карьер. В теории, если успех магазина по продаже книжек зайдёт, то его можно будет развести до целой платформы и потом продавать другим разработчикам сертификаты о её знании. Для того, чтобы безболезненно внедрять микросервисы, нам нужно хранить их конфигурации в одном месте, всё равно уже в монорепозитории делаем. Так как проект учебный, то почему бы не использовать стандартный Spring Config Service. Добавим к нашим разрозненным сервисам config-service и вынесем в специальную папку config все отличающиеся части application.yml файлов сервисов, унифицировав оставшиеся к одному стандартному виду, который будет тянуть всё содержимое из сервиса конфигурации.

В итоге получается вот такая структура:

Новый сервис по коду — обычный spring boot application, но с особенностями:

1) В помнике присутствуют две зависимости:

2) Над стартером приложения размещена аннотация @EnableConfigServer

Рассмотрим application.yml нового config-service:

Рассмотрим конфигурацию order-service, которую мы будем подгружать из конфиг сервиса config/order-service.yml:

А теперь увидим изменённый application.yml внутри сервиса order-service:

Всё, теперь order-service будет подгружать конфигурацию из config-service. Помимо плюсов, стоит отметить, что будут минусы при написании тестов, т. к. нам нужно будет или поднимать config-service или копировать содержимое части order-service.yml в application-test.yml. Но мы пока о тестах не думали, поэтому вывели все конфигурации сервисов в наш config-service.

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

Отлично, унифицировав наши микросервисы, давайте избавимся от необходимости вносить правки на фронте, применяя один API Gateway для взаимодействия со всеми сервисами. Для этого создадим новый сервис — gateway-service, который будет использовать Spring Cloud Gateway и крутится на 8080 порту, как наш старый монолит.

Из особенностей gateway-service можно выделить только:

1) наличие необходимых зависимостей

2) наличие в конфиге application.yml необходимых перенаправлений на сервисы:

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

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

Итак, напишем наш ci файл. Как и раньше будем использовать github-ci. В итоге, получим такой конфиг сборки артефактов наших сервисов и упаковки их в образы, в docker-hub:

.github/workflows/maven.yml (по стандартному шаблону github):

Ура, мы сделали CI из монорепозитория только тех сервисов, которые будем править. Но есть одно но: сервисы за нашим Spring Cloud Gateway не будут масштабироваться автоматически, т. к. выше мы их завязали на порты, т. е. Нам нужно будет править ещё и Spring Cloud Gateway. Давайте поднимем свой service discovery и подружим его со Spring Cloud Gateway. В свободном доступе все предлагают использовать Eureka, её и будем использовать.

Добавим ещё один сервис discovery-service, который будет ничем иным, как Eureka Server со следующими приметами:

1) Над стартером используется аннотация @EnableEurekaServer

2)

3) во все существующие сервисы добавим над стартером аннотацию: @EnableDiscoveryClient

и зависимость в помники:

Теперь переделаем наш конфиг gateway-service:

Ура, вот теперь мы можем не трогать Spring Cloud Gateway при масштабировании наших сервисов. Работа через Eureka это, конечно, хорошо, но мы бы хотели стенд на kubernetes (т. к. монолит деплоился раньше туда). К тому же, там просто чудесные средства масштабирования приложений из коробки. В таком случае, давайте переведем наши сервисы в k8s:

Создадим пространство имён:

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

Обновленный gateway-service.yml:

Готово, давайте задеплоим наши поды, отмасштабируем payment-service и проверим, что всё работает, как мы задумывали:

Т.к. у нас ещё жива Eureka давайте проверим, что она видит 2 поды:

Постучимся через API Gateway к нашему сервису:

Супер, а теперь постучимся за детализацией несуществующих платежей и проверим, что балансер Kubernetes распределяет трафик по двум подам:

Итого, из 6 минус идентификаторов — 2 ушли в ошибку на одной поде, 4 на второй (основная).

Мы достигли цели, осталось накрутить мониторинг Sentry, для наработки навыка работы с фоном ошибок в домашних условиях.

1) Зарегистрируемся в https://sentry.io/

2) Создадим своё пространство, в нём создадим Spring Boot проект:

3) Добавим нужные зависимости в pom.xml по инструкции и dsn путь для отправки ивентов в payment-service.yml (см. код проекта по ссылке) + сделаем выставление значений через переменные среды в deployment файле payment-service.yaml k8s, для замены значений на лету.

Всё, теперь посмотрим как выглядит фон ошибок по нашим двум подам payment-service:

Отлично, мы подняли свой стенд микросервисов из дробленого монолита с деплоем из монорепозитория и мониторингом Sentry. Конечно, можно продолжить улучшать то, что уже есть: пирамида тестов, безопасность через sso, зеркалирование трафика kubernetes, внедрение Vault конфигов, но это потом.

Надеюсь, статья была полезной и интересной. Спасибо за уделенное время!

Автор: Александр Леонов, руководитель группы разработки одной из распределённых команд Usetech.

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

Код статьи c инструкцией установки доступен в репозиториях:

1. https://github.com/alexandr-leonov/eda-configuration
2. https://github.com/alexandr-leonov/eda-order-service

Итак, вам понадобилось обкатать какое-то решение на практике, но на работе это делать не разрешено/опасно/коллеги не поймут… Тогда самое время развернуть свой стенд для испытаний и экспериментами с инфраструктурой и сервисами.

Дано:

• Кластер на Kubernetes;
• Пару сервисов на Spring с PostgresSQL базой, кешом Redis и взаимодействием по Kafka и REST API;
• Аккаунт на Github (конечно, ближе к настоящей системе поднять свой Gitlab, но т. к. экспериментируем для себя и в одиночку, то Github достаточно);
• Аккаунт на DockerHub.

Найти:

Поднять у себя на локальной машине кластер k8s, который бы по пушу в Github деплоил на стенд необходимый сервис.

Решение:

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

Отлично, кластер мы подняли и запустили. Теперь создадим неймспейс наших сервисов. Пускай это будет Event Driven Architecture Develop — слишком долго, поэтому укоротим до eda-dev.

Создадим namespace.yaml с неймспейсом:

Применяем конфиг в k8s c помощью команды:

Теперь попробуем установить Postgress, но перед тем как искать нужный yml в документации, необходимо озаботиться тем, где будем хранить секреты. В этой статье не будем затрагивать тему Vault. Для начала используем стандартный механизм k8s для хранения секретов.

Оформим secret.yaml:

Запускаем той же командой:

Теперь найдём эталонный конфиг k8s для Postgres и модифицируем его под себя.

Итоговый файл postgres-cluster.yaml:

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

Далее применяем yaml.

1. zookeeper-cluster.yaml, устанавливающий zookeeper (если используете не самую последнюю версию Kafka);
2. kafka-broker.yaml, устанавливает Kafka.

Исходный код:

1. https://github.com/alexandr-leonov/eda-configuration/blob/master/dev/kafka/zookeeper-cluster.yaml
2. https://github.com/alexandr-leonov/eda-configuration/blob/master/dev/kafka/kafka-broker.yaml

После применим наши конфиги по очереди — сначала zookeeper, потом Kafka.

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

Установим Redis через helm.

Для начала установим сам helm, в терминале Ubuntu это делается установкой snap пакета:

Далее добавим репозиторий с компонентами. Довольно распространены сборки компонент от компании Bitnami.

А теперь установим полноценный Redis, как есть с указанием неймспейса:

Готово! Установка helm с переопределением некоторых переменных на примере Mongo DB выглядит так:

Пример конфига переопределённых переменных.

Отлично, теперь напишем один из пары микросервисов. Пускай это будет сервис заказов, написанный с использованием Kotlin, Spring Boot, Webflux, Gradle. Так как написание такого сервиса не является целью этой статьи, то можно воспользоваться готовым кодом.

Теперь, когда код сервиса написан, осталось настроить его CI/CD в кластер Kubernetes. Для CI части будем использовать Github Actions, в то время как для CD части обычно используют Webhook. Однако представим, что у нас не белый ip и мы вообще не хотим предоставлять какие-то данные наружу и готовы пожертвовать частью удобств, дабы не увлечься и не сожрать лимиты бесплатного использования service registry, в качестве, которого будем использовать Docker Hub, настроим крон джобу, которая периодически будет обновлять стенд самыми новыми образами сервисов.

Итак, CI делаем на стороне order-service, сначала подготовим Dockerfile для образа приложения:

Затем, модифицируя стандартный github-ci конфиг, а также используя стандартные секреты Github для хранения логинов и паролей, получим:

Данный конфиг будет собирать образ и публиковать его Docker Hub при каждом пуше в мастер.

Настало время CD части.

Создадим order-service.yaml, который будет разворачивать наше приложение в k8s с заданными настройками:

Так как конфиги лежат в отдельной Github репе, то креды Docker Hub скрыты подобным образом. Однако при локальной работе их нужно будет заменить настоящими значениями. Значения вида $(POSTGRES_SERVICE_HOST) стандартные, их можно не менять.

Применим конфиг:

Готово, сервис пошёл тянуть образ из Docker Hub. Смотрим поды:

Ждём, когда сервис стартанёт.

Готово, сервис поднят, теперь можно стучаться к сваггеру. Для этого определим какой ip адрес у ноды k8s, а затем найдём порт, по которому доступно приложение:

Открываем сваггер:

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

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

Создадим конфиг прав для плана order-service-deployment — rights.yaml:

Теперь создадим джобу scheduler.yaml, которая будет каждые 4 часа обновлять order-service в кластере, если в Docker Hub появились новые образы.

Применим данные конфиги:

Ура! Мы развернули кластер с микросервисом Spring, с полноценным CI/CD процессом, познакомились с некоторыми сущностями k8s, helm и подняли тестовый стенд для экспериментов.

Если вам понравилась эта статья, то скоро выйдет продолжение, где мы рассмотрим более сложную работу микросервисов в Kubernetes с балансировкой через Spring Cloud Gateway, хранением конфигураций приложений в Spring Config Service, фиксированием инцидентов через Sentry.

1. Вводная
2. Бизнес-требования
3. Требования к архитектуре
4. Требования к веб-фреймворку
5. Выбор веб-фреймворка
6. Начало работы над проектом

Вводная

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

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

Бизнес-требования

В рамках серии статей мы разработаем интернет-магазин. Давайте разложим функционал магазина на несколько простых пользовательских историй. Я, как пользователь сайта интернет-магазина, могу:

1. Зарегистрироваться на сайте.
2. Авторизоваться на сайте.
3. Посмотреть список товаров.
4. Посмотреть карточку товара.
5. Положить товар в корзину.
6. Управлять товарами в корзине.
7. Оплатить товары в корзине.
8. Получить чек на почту.

Требования к архитектуре

Как мы видим, весь функционал раскладывается на три предметные области или домена:

1. Пользователи.
2. Товары.
3. Заказы.

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

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

Архитектура, разработанная на принципах DDD, имеет очевидные преимущества:

1. Бизнес-логика пишется один раз внутри домена и переиспользуется другими. Значит изменение логики либо не затронет остальные части проекта, либо будут дешевле с точки зрения времени и денег.
2. Все домены имеют схожую структуру, значит разработчикам будет легче переключаться между доменами и разбираться, что там происходит.

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

1. Пользователи.
2. Товары.
3. Заказы.

Команда разработки Ogon.ru начинает новую фичу с проектирования API и схемы СУБД, т.к. готовая фича — это работающая и серверная, и клиентская часть. Кроме того, фича должна соответствовать критериям приемки, значит и тестировщики должны быть сразу вовлечены в процесс. Другими словами, надо организовать работу N человек, а для этого надо с чего-то начать. Давайте начнем с API, но сначала поймем, что мы хотим от веб-фреймворка.

Требования к веб-фреймворку

Во время разработки API Ogon.ru мы использовали свой положительный опыт из прошлых проектов и рекомендации REST API Tutorial. Таким образом, веб-фреймворк должен поддерживать:

1. Маршрутизацию запросов по схеме.
2. Маршрутизацию запросов по заголовкам.
3. Маршрутизацию по URL-пути.
4. Переменные в URL-пути.
5. HTTP-методы.
6. Контекст запроса.
7. Middleware.
8. Получение запросов в JSON, XML и т. д.
9. Встроенную десериализацию запросов и ответов.
10. Генерацию документации для фронтэндщиков, тестировщиков и наших партнеров.
11. Минимизацию трафика между микросервисами.

Выбор веб-фреймворка

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

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

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

1. RAML
2. API Blueprint
3. OpenAPI (Swagger)

На наш взгляд RAML и API Blueprint слабо представлены в golang, т.к. количество проектов, использующих эти технологии, невелико по сравнению с OpenAPI. Строить коммерческое веб-приложение на непопулярных технологиях — это риски для компании и для команды разработки, т.к. при самом плохом раскладе придется поддерживать выбранную технологию. Мы остановили свой выбор на OpenAPI, и тут на помощь нам пришел GRPC в реализации Go Protobuf и GRPC-Gateway.

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

1. Go Swagger, но сам swagger более многословный, чем protobuf, вдобавок не хочется гонять JSON внутри сети, поэтому он нам не подошел.
2. Swag, но этот проект выглядит костыльным решением для команд, которым потребовалось документировать свое API через полгода разработки на своем любимом фреймворке. Есть риски, что документация API на основе комментариев в коде и сама реализация разойдутся, потому что разработчик забыл их актуализировать, при этом нет никаких инструментов валидации этой ситуации.

Начало работы над проектом

Теперь давайте потрогаем технологии руками и для начала:

1. Установим зависимости:
   a. protoc
   b. docker
   c. golang
   d. buf, после 24 февраля введена блокировка для России, решается установкой VPN
   e. make
2. Создадим структуру проекта на основании популярного решения.
3. Настроим генерацию сервисов и сущностей из protobuf.

Генерация сервисов и сущностей из protobuf

Установим зависимости для GRPC и GRPC-Gateway:

Настроим buf

1. Создадим enterprise-application/buf.yaml
2. Создадим enterprise-application/buf.gen.yaml
3. Выполним buf mod update

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

Давайте опишем сервисы и сущности корзины enterprise-application/api/proto/v1/order.proto:

enterprise-application/api/proto/v1/order_service.proto:

По аналогии с сервисом корзины описываем:

1. Микросервис продуктов и его сущности.
2. Микросервис пользователей и его сущности.

Генерируем golang-код:

buf generate

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

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

Внутренняя архитектура микросервиса будет основана на принципах DDD:

1. Доменный слой — описание сущностей, интерфейсов сервисов и репозиториев.
2. Инфраструктурный слой — реализация интерфейсов репозиториев и сервисов.
3. Слой приложения — реализация GRPC-сервиса.

Доменный слой

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

pkg/product/domain/service/product.go:

Обратите внимание, что имя пакета отличается от имени папки из-за того, что в каждом домене будут свои сервисы, соответственно будут конфликты при импорте между order/domain/service и product/domain/service. С помощью такого простого трюка современные IDE будут импортировать пакеты и сразу вешать на него алиас.

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

Теперь необходимо собрать все воедино и проверить работоспособность, для этого соберем docker-compose.yml.

deployments/docker-compose.yml:

Поднимаем наш проект

docker-compose -p enterprise_application -f deployments/docker-compose.yml up -d --build --force-recreate

Пропишем 127.0.0.1 enterprise.application.local в /etc/hosts.

Введем в адресную строку браузера http://enterprise.application.local и увидим нашу документацию в виде swagger-файла:

Swagger-файл — это не только наглядный, но и рабочий документ, который позволяет провалиться в конкретный метод, выполнить запрос и получить ответ:

Итак, в рамках данной статьи нам удалось

1. Получить бизнес-требования.
2. На их основании выработать требования к архитектуре.
3. Подобрать веб-фреймворк.
4. Реализовать микросервисы.
5. Собрать и развернуть микросервисы на локальном стенде.
6. Подготовить документацию по API.

Код проекта представлен в репозитории.

В следующей статье мы научимся:

1. Работать с middleware.
2. Настраивать приложения с помощью конфигурационного файла и переменных окружения.
3. Автоматически внедрять зависимости.
4. Мокать и тестировать код.

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

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

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

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

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

Проектирование микросервисов

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

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

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

Также стоит определиться с тем в каком формате будут взаимодействовать ваши микросервисы (JSON, XML, GraphQL, gRPC). Данный шаг очень важен, так как впоследствии с ростом микросервисов будет сложно перестроиться на новый формат

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

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

Инструменты для работы с МС: создание, логирование, мониторинг

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

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

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

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

Как можно догадаться, объём логов может выходить за границы чувственного восприятия человека. На помощь приходит ELK-схема — набор из трёх инструментов для генерации, обработки и индексации лога. Микросервис генерирует файлы лога, которые в дальнейшем проходят три этапа обработки. Logstash собирает логи приложений по заданным правилам и направляет их в ElasticSearch, который хранит и индексирует все логи. Затем информация визуализируется в Kibana, где мы можем с ней работать.

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

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

Для мониторинга можно использовать популярные Zabbix или Prometheus. Выбор зависит от ваших потребностей.

Напоследок упомянем CI/CD — практику continuous integration и continuous delivery. Так как микросервисов достаточно много, процесс интеграции вручную не представляется возможным. CI/CD позволяет автоматизировать выкладку на разные ландшафты и обладает следующими преимуществами: автоматизация сборки проекта, автоматическое тестирование, экономия времени при доставке фич на разные ландшафты. Для реализации CI/CD используют: Gitlab CI, Bitbucket Pipelines, Jenkins, Gitlab Actions.

Работа в команде

Чтобы микросервисы не превратились в распределённый монолит, команде также нужно придерживаться некоторых правил работы.

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

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

И добавляем самое важное правило: разработал блок — написал документацию.

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

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

Стоит ли вам перейти на микросервисы?

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

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

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

Вы также можете посмотреть выступление тимлида Hawking Bros, Ильи Малиновского, о микросервисной архитектуре веб-приложений на конференции Mind Bros Conf

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

Из-за цифровизации и пандемии, которая подтолкнула многие компании к онлайну, time-to-market новой клиентской функциональности стал одной из метрик эффективности бизнеса. Считается, что низкий параметр TTM снижает жизнеспособность продукта на 20% (данные Gartner).

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

В активной фазе микросервисы в России стали применять около пяти лет назад, хотя первые упоминания этого подхода в мире датируются началом 2000-х. По мнению аналитиков Allied Market Research, объём рынка микросервисов к 2026 году превысит $8 миллиардов, демонстрируя ежегодный прирост на уровне 18%. Это одна из точек роста глобального ИТ-рынка, включая нашу страну. Из 500 клиентов КРОК Облачные сервисы не менее 65% уже используют у себя микросервисную архитектуру, а примерно 18% планируют «распилить свой монолит» в ближайшие годы.

В чём преимущества микросервисов?

Рассмотрим на примере двух типов архитектур.

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

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

Минусы:

• Сложность внесения изменений. Чтобы поменять что-то, пусть и незначительное, в структуре, например, e-commerce платформы (предположим, код модуля, отвечающий за каталог товаров), надо вручную отследить и скорректировать большое количество других зависимостей. Это не только увеличивает время доработки онлайн-ресурса, но и требует вовлечения большого количества инженеров.
• Трудности масштабирования. В монолитных архитектурах не всегда возможно нарастить вычислительные мощности для какого-то одного из сервисов, например, только лишь основной витрины товаров или модуля, отвечающего за оплату. Можно нарастить потребление ресурсов для всего сайта, а это часто бывает избыточно.
• Риски сбоев. Из-за связности компонентов сбой на уровне ПО одного из сервисов с большой долей вероятности негативно повлияет на всю платформу.
• Сложность внедрения новых технологий. Если платформа была написана, предположим, на Python, перейти на что-то другое фактически нереально. В ИТ-отрасли это ещё зовется legacy — унаследованной инфраструктурой, которая в статичном виде может функционировать годами.
• Большие трудозатраты на поддержку. Когда сервисов становится много, нужен супер-квалифицированный специалист, который сможет видеть верхнеуровневую картину. Скорее всего, найти такого на рынке не получится, либо он будет стоить слишком дорого для компании. Единственный путь — вырастить его изнутри.

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

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

Плюсы:

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

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

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

Содержание:

0:17 Знакомство с MinIO

3:54 MinIO docker-compose.yml

5:43 Разработка микросервиса на Golang

28:08 Текущее состояние системы заметок

Знакомство с хранилищем MinIO

MinIO создано для размещения неструктурированных данных, таких как фотографии, видеозаписи, файлы журналов, резервные копии, а также образы виртуальных машин и контейнеров. Небольшой размер позволяет включать его в состав стека приложений. В MinIO также поддерживается распределённый режим (Distributed mode), который предоставляет возможность подключения к одному серверу хранения объектов множества дисков, в том числе расположенных на разных машинах.

MinIO крайне минималистичо, у него нет красивого и функционального UI. Но по части использования ресурсов оно крайне жадное — оперативную память и процессор кушает достаточно много. Также хочу отметить, что такие известные решения, как FreeNAS и TrueNAS под капотом используют именно MinIO.

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

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

Использование MinIO Erasure Coding

Erasure Coding — это программная защита данных от повреждения и потери. Как рейд, только намного надёжней. Если классический RAID 6 может позволить себе потерять 2 диска, то MinIO спокойно переживает потерю половины.

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

Хотите 1:1? Пожалуйста! Хотите 5:2? Без проблем! Очень важная функция, если вы используете сразу несколько нод и хотите найти свой собственный баланс между максимальной безопасностью данных и количеством затраченных ресурсов.

Из коробки MinIO использует формулу N/2 (где N — общее количество дисков), т.е. делит ваши данные между N/2 дисками данных и N/2 дисками чётности. Перевожу на человеческий: можно потерять половину дисков и восстановить данные. Это соотношение задаётся через Storage Class, позволяя вам самостоятельно выбрать, что важнее — надёжность или ёмкость.

Предположим, что у вас инсталляция на 16 дисков и вам надо сохранить файл размером 100 Мб. Если используются настройки по умолчанию (8 дисков под данные, 8 под блоки чётности), то файл в итоге займёт практически двойной объём т.е. 200 Мб. Если отношение дисков будет 10/6, то понадобится 160 Мб. 14/2 — 114 Мб.

Настройка и запуск MinIO

Cкачиваем файлы docker-compose.yml и nginx.conf, после чего можно запускать.

Давайте поближе посмотрим docker-compose файл.

По дефолту здесь 4 сервиса MinIO. Их количество можно увеличить до 16, но мы уменьшим до 2, чтобы сохранить кластер. Большее количество узлов для нас сейчас избыточно. Также здесь описан сервис NGINX, для которого мы скачивали конфигурацию. Он нужен для балансировки запросов между узлами кластера.

Описание сервисов MinIO по сути одинаковое. Давайте посмотрим на minio1:

• image с тегом релиза от определенной даты;
• два volume, их можно распределить по разным физическим дискам, чтобы обеспечить отказоустойчивость;
• наружу выставляется 9000 порт для обращения к API;
• указываются переменные среды с логином и паролем доступа к MinIO;
• команда для запуска сервера MinIO в URL  которой используется синтаксис указания множества серверов: [http://minio{1…2}](http://minio{1…2})/data{1…2} раскрывается как массив http://minio1/data1 и http://minio2/data2;

Далее описан healthcheck, который позволяет мониторить здоровье сервиса. У него есть параметр test. Это Shell-команда, которая вызывает Curl и передает ему URL для проверки того, живёт ли сервис. Делать такую проверку мы будем каждые 30 секунд. Если за 20 секунд сервис не ответит, он будет помечен как нездоровый.

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

На этом знакомство с MinIO завершено, далее — продолжение разработки системы заметок с нуля. В предыдущих частях мы:

• спроектировали микросервисную архитектуру;
• разработали RESTful API Service на Golang cо Swagger и авторизацией;
• познакомились с графовой БД Neo4j и работали над микросервисами CategoryService и APIService;
• разработали микросервисы NoteService, TagService и UserService.

Исходный код проекта на GitHub

Какая текущая ситуация? Мы разработали все сервисы. Осталось реализовать веб-клиент в виде приложения на Vue.js, а также заняться инфраструктурой системы, такой как Service Discovering и OpenTracing, упаковать все сервисы в docker-контейнеры и настроить CI/CD.

Но и нюансов у технологии достаточно. Для кого среда Kubernetes становится стандартом? Кому лучше воспользоваться другими инструментами? И в чём особенность облачного Kubernetes-as-a-Service? Рассказывает Дмитрий Лазаренко, директор по продукту Mail.ru Cloud Solutions.

О контейнерах и микросервисах

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

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

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

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

Kubernetes — инструмент для масштабных разработок

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

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

Таким образом, система Kubernetes ускоряет разработку контейнерных приложений и выкатку обновлений. А ведь максимально быстрый Time-To-Market — это именно та задача, которые сегодня пытаются решить крупные игроки в ритейле и логистике, в финансовой сфере, в телекоме и других высококонкурентных направлениях бизнеса.

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

Основные преимущества Kubernetes:

• Программное управление релизами на серверах. В том числе моментальное внедрение и откатывание релиза, a/b тестирование и другие процессы.
• Автоскейлинг — автоматическое увеличение или уменьшение количества копий приложения или размера кластера (добавление или удаление нод в зависимости от нагрузки).
• Автоматическая регулировка отказоустойчивости — распределение приложений по серверам с учётом нагрузки и в случае сбоя одного из них.
• Автоматизация тестирования и выкатки приложений — без участия администраторов.

Есть смысл внедрять Kubernetes, если:

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

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

Самостоятельное развёртывание vs KaaS

Самостоятельное развёртывание (self-hosted) Kubernetes на собственных серверах «из коробки» не единственный вариант внедрения технологии. Ту же функциональность можно реализовать в облаке проще, используя готовый сервис: KaaS или Managed Kubernetes.

Если вы используете среду Kubernetes как сервис, провайдер сам обновляет и поддерживает систему. А также занимается вопросами отказоустойчивости кластера. Клиенту для эксплуатации системы потребуется только DevOps-инженер, а не целое подразделение. KaaS хорошо подходит для быстрого первоначального развёртывания кластера. Так, процесс, который в варианте self-hosted занимает от нескольких часов до нескольких дней, в облаке сокращается до десяти минут.

Дополнительные open source решения в облачном сервисе предоставляются по умолчанию или легко подключаются. Пользователю не нужно вручную настраивать систему мониторинга, балансировку нагрузки, сбор и хранение логов, настройки безопасности, авторизацию пользователей и другие параметры. То же касается хранилищ постоянных данных приложений (так называемых постоянных томов, или Persistent Volumes), которые приходится держать вне часто обновляющихся контейнеров. Хранилище также можно приобрести у провайдера и достаточно просто интегрировать со средой Kubernetes через API.

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

Мы разберём реализацию JSON Web Token авторизации и систему ошибок. Посмотрим на программную архитектуру проекта, изучим программные паттерны разработки и посмотрим, как использовать в проекте язык программирования Golang.

Исходный код проекта доступен на GitHub.

0:33 Обзор структуры проекта, функции main в файле main.go — точке входа в приложении.

2:42 Обзор обёртки над логером logrus. Логирование в разные файлы с разным уровнем логирования.

12:34 Создание объекта конфигурации из YAML-файла при помощи библиотеки cleanenv.

16:30 Разбираем обёртку над кэшем в Golang и реализацию кэша с использованием библиотеки freecache.

21:40 Реализация JSON Web Token.

32:05 Смотрим на хендлеры — обработчики запросов к сервису, разбираем паттерн Data Transfer Object в Golang.

41:13 Система обработки ошибок и определения статуса HTTP кода возврата по ошибке.

1:00:10 Общий REST Client для взаимодействия с RESTful сервисами.

1:09:00 Разбираемся с сервисами бизнес-логики и контекстом в Golang.

1:23:10 Функции старта приложения по порту и на сокете, Graceful Shutdown с закрытием ресурсов.

1:26:40 Разбираемся с особенностью Golang: nil != nil.