Коммуникация микросервисов

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

На последнем семинаре мы подробно обсудили, как строить требования к сервису, чтобы сохранять высокую связность внутри сервиса. Следующий шаг - выстроить грамотную коммуникацию. Подробно этот вопрос разобран в лекции Основы коммуникации микросервисов (нужна подписка №1 на soer.pro).

Некоторые вещи из лекции, которые будут полезны:

- Высокая когезия (high cohesion) - реализуется через проведение границ сервисов;
- Низкое зацепление (low coupling) - реализуется с помощью асинхронной коммуникации или промежуточных абстракций (например, сервисов-координаторов).

Аспекты проектирования, которые нужно рассмотреть:

1. Границы сервиса - не по командам, а по бизнес-задачам (bounded context). При этом команды должны распределяться по контекстам.

2. Использовать SRP при определении границ сервиса, так чтобы у сервиса была только "одна причина" меняться.

Здесь есть сложность - понятие "одна причина" имеет несколько трактовок:

- одна причина - это когда у сервиса один владелец, которые принимает решение о изменения (или "один актор");

- одна причина - это когда есть бизнес задача и причина связана с этой задачей;

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

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

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

Синхронными транзакциями проще управлять, их легко строить, но они более "хрупкие" и склонны повышать зацепление. Но дают способ обеспечить атомарность операций через блокировку ресурсов (наприме, 2PC), высокую скорость и стриминг (через gRPC).

Асинхронные транзакции сложнее с технической точки зрения (требуют инфраструктуру), осложняют поиск корневой причины в случае сбоя, создают дополнительные "точки отказа", но при этом повышают "жизнеспособность" системы, уменьшают зацепление. Часто используются с SAGA или Outbox паттернами.

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

4. Идемпотентность - нужна в большинстве случаев, чтобы реализовывать стратегии с повторными вызовами.
Про проектировании требуется отдельно посмотреть на метод POST, он не идемпотентен от слова "совсем", поэтому требуется предусмотреть ключ идемпотентности (обучно в заголовке).

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

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

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

Стал часто встречать подобные комментарии: "В эру AI будущее за хардскиллами, лол"

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

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

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

Удивляет, что многие воспринимают ИИ как конкурента и потенциальную угрозу для своего трудоустройства.

На мой взгляд ИИ наоборот — огромное окно возможностей, которое возвращает нас во времена, когда можно было в соло создавать крутые проекты.

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

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

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

Так что одна дверь закрылась, но взамен открылась тысяча других

Инженеры которых мы заслужили:

Масштабирование как процесс включает в себя процесс деплоя

Навсякий случай напомню, что согласно Вики: "Software deployment is all of the activities that make a software system available for use"

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

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

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

Разрыв между навыками написания кода и полноценными инженерными навыками оказался огромным. Проблема даже не в знаниях, которые нужны для ИИ-инжиниринга, а в неумении декомпозировать задачу до уровня, где LLM не теряет контекст, составлять проверяемые требования, исключать противоречия. Сложно менять привычки, уходить от I-shape подходов, перестать ждать от LLM архитектурных решений.

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

Что нужно делать:

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

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

3. Работать с инфраструктурой. Это ещё одна важная деталь, которая подразумевает уход от узкой специализации к более широкому взгляду. Инженер должен видеть «общую картину» и понимать, как проект работает на всех этапах — от локального запуска до продакшна. База здесь: виртуализация, контейнеризация, СУБД, очереди сообщений, брокеры событий. Без этого LLM будет генерировать код, который работает в изоляции и ломается в реальной среде.

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

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

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

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

Стратегия ближайших лет: кодинг как основная специализация не спасёт от ИИ-агентов. Архитектура, работа с требованиями и умение проектировать систему — вот наша новая «валюта».

Вот я постоянно рекламирую наше сообщество "наш клуб дает то", "наш клуб делает это", а чем он так хорошо этот "наш клуб"?

Для меня это вопрос ответ на который дает мотивацию и силы для дальнейшего движения вперед. Ну правда, клуб ради чего? Чтобы денег заработать? Какой-то сомнительный стимул, есть другие способы заработать, реализовать которые проще (например, консультации).

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

Обычный подход в подобного рода объединениях - это обучение. Сделал курс, собрал людей, курс закончился и все.

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

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

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

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

Кажется, что это далекое будущее, но если посмореть на скорость последних лет, то это горизонт 2-3 лет.

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

Попросил клода посмотреть на мой сайт soerdev.space глазами дизайнера, он сказал, что использовать темную тему для чтения текстов - издевательство над пользователями и переделал все нафиг.

А потом я посмотрел на все это дело и заодно попросил его докрутить отображение memrmaidjs диаграмм, перекроить кое-какие блоки.

И знаете, что? Мне понравилось как получилось!

По пабликам гуляет новость, что Mythos нашел за месяц более 10к багов. Нюанс в том, что новостей о таком же количестве багфиксов от ИИ как-то не наблюдается.

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

Ответ простой: ИИ этого пока не может.

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

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

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

Какая же жизаааа 👇👇👇

Уооо Горбушка, стоит на месте, всё нормульдик

Скоро снова будем тут диски/флешки покупать, будет снова тут центр цифровой движухи, как в 90х-нулевых

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

«Лучшие Python и Nodejs библиотеки 2026»
«Полный набор ИИ май 2026»
«Брейкинг Бэд в переводе Гоблина все сезоны»
«Гуф золотые шлягеры»

Хорошо так, тепло:)

Отказываюсь от использования Claude и вот почему.

Anthropic делает одни из лучших моделей — это факт. Я в полном восторге от Opus 4.7, новая модель Opus 4.8 на проверочных задачах выглядит ещё лучше. И казалось бы, нужно пользоваться лучшим инструментом, чтобы получать лучший результат. Но нет, на практике всё упирается в «цена/качество». И здесь выясняется самое неприятное:

Opus отлично справляется с простыми задачами по разработке, но на сложных задачах его мощности не хватает.

Я делаю несколько пет-проектов, которые полностью разрабатывает ИИ, показательны два примера:

1. Простой сайт (soerdev.space) с типовыми веб-элементами, Angular и разделением на модули. Claude разрабатывает модули и делает это на изи. На выходе вполне читаемый код, но требует отдельно создавать модули и отдельно их интегрировать в проект.

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

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

В какой-то момент принимаешь решение: «Стоп! Хватит!», делаем новую версию и учитываем все проблемы в планировании и описании архитектуры.

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

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

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

Если ткнуть ИИ в конкретные АДР, то он видит, понимает и даже говорит «сейчас всё исправлю», а в итоге становится только хуже.

Последний вариант оркестратора я собрал на своей архитектуре, которую разработал сам (включая структуру проекта). ИИ делает только конкретные небольшие модули, для которых уже созданы и описаны интерфейсы, прописаны ограничения, есть АДР и т.д. Клод справляется с этим на ура... Есть только одно «но» — китайские модели — MiniMax, Kimi, GLM тоже выдают при таком подходе нормальный результат.

Сейчас Anthropic в своего «сжигателя токенов» (Claude Code) добавил динамический воркфлоу, который сделал процесс уничтожения токенов ещё быстрее, но описанные выше проблемы это не решает (возможно, если лимиты будут в 100 раз больше, то ситуация исправится, но у меня нет таких денег).

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

Поэтому я решил переехать на китайские модели + свой оркестратор.

Функции оркестратора: подбор LLM, использование ролей (определяет скилы и инструменты), запуск агентов, использование пайплайнов.

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