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

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

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

Привет, Хабр. Меня зовут Виктор Овчинников, я руковожу разработкой интеграционной платформы Digital Q.Integration в компании Диасофт.

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

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

Почему не классический ESB

Коротко, потому что Дмитрий уже написал развёрнуто.

Классическая ESB — это монолитное ядро. Масштабирование только вертикальное. И при падении падает всё. Но самое болезненное для эксплуатации это то, что со временем шина становится местом, куда стекается вся прикладная логика. Через несколько лет она знает о бизнесе компании больше, чем любая из систем, которые к ней подключены. Разобраться в этом — отдельная задача. Это то нас и подтолкнуло к собственному подходу.

Мы сформулировали для себя так: возьмём лучшее из point-to-point и из ESB. Независимые сервисы — без централизованной бизнес-логики. Общий транспорт, общий мониторинг, общий инструментарий — как в ESB.

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

Архитектура: каждая система — отдельный микросервис

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

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

Решение лежит на поверхности: давайте распилим монолит на микросервисы! Здесь одни достоинства: горизонтальное масштабирование, отдельные команды, независимые сервисы, отказоустойчивость, автономные релизы. Недостатки отсутствуют, ну или почти отсутствуют. А может, если быть честными, их лишь «заметают под ковёр»?

А что если я скажу вам, что при таком подходе мы, скорее всего, получим с десяток микросервисов, которые по цепочке синхронно вызывают друг друга, знают подробности внутреннего устройства каждого, ходят в общие таблицы (крайне запущенный случай), и отказ одного из них вызовет крах всей системы? Прямо как с костяшками домино. Встречайте, Его Величество Распределённый Монолит!

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

В этой статье я разберу проблему по слоям: откуда физически берётся расхождение, какие есть уровни решений (от коробки до event-driven на Go), и почему модный ответ «поставьте Kafka» для одного селлера почти всегда оверкилл. Будет код и будут цифры.

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

Привет! Меня зовут Евгений, я работаю в БКС Мир инвестиций владельцем сервиса «Портфель».

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

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

Но внутри компании за этим экраном стоит много всего. Backend‑сервисы, frontend, интеграции, биржевые данные, банковские продукты, сетевой путь, мониторинги, SLA, обращения клиентов в контактный центр, поддержка, аналитика, релизы и ожидания бизнеса.

На стыке всего этого и появляется роль Service Owner.

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

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

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

От CRUD на FastAPI до видеоплатформы: история одного pet-проекта

История о том, как учебный CRUD-проект на FastAPI постепенно превратился в стенд с микросервисами, мониторингом, Kubernetes.

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

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

В статье описан практический опыт интеграции ERP‑системы с 1С. В материале я рассказываю:
• почему мы выбрали микросервисную архитектуру
• зачем в одной интеграции использовали и GraphQL, и REST API
• как строили маппинг данных для разных конфигураций 1С
• как работает формат EnterpriseData и почему он сложный, но универсальный
• и на какие грабли мы наступали — чтобы вы на них не наступали.

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

Всем привет! Это Денис Сметнев. Последние пару месяцев я плотно сижу на вайбкодинге. Поднял свой сервер, запилил базу лидов из Телеграма и карту знаний, хотя последний раз кодил в 9 классе на Pascal. Вижу, что у многих появилась мысль: если я могу сам сделать себе любой софт под задачу, зачем тогда вообще нужны SaaS-продукты? Неужели они умрут? В этой статье хочу порассуждать, как на самом деле изменится рынок и почему хоронить софт пока рано.

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

В этой статье разбираем, как перейти со Spring Boot 3.x на 4.0 и с Java 21 на Java 25 не одним рискованным прыжком, а как управляемой инженерной процедурой: с промежуточной остановкой, проверками, канарейкой и понятным планом отката.

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

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

Лиз Райс — вице-президент по open source в Aqua Security, мейнтейнер eBPF и автор первого издания. Первые пять лет после выхода книга реально была настольной у инженеров, которые расследовали инциденты в контейнерных средах.

Второе издание серьёзно переработано. Угрозы изменились, Kubernetes получил новые механизмы безопасности, eBPF вышел из стадии экспериментов, а supply chain-атаки стали обыденностью.

Если читали первое — здесь обновлённые модели угроз, разбор реальных CVE и конкретные рекомендации, а не просто теории.

Год назад доступ к зарубежным LLM из России превратился в квест. OpenAI и Anthropic не принимают российские карты и блокируют запросы по гео. Обходные пути — VPN, иностранная карта, прокладка через знакомых за рубежом — годятся для пет-проекта, но не для продакшена, где нужен стабильный аккаунт, предсказуемый счёт и возможность объяснить бухгалтерии, за что платим.

Мы сделали apiglue — шлюз, который закрывает эту боль: один OpenAI-совместимый endpoint, за которым прячутся десятки провайдеров, оплата рублёвой картой и баланс в рублях. А заодно — управляемый хостинг n8n, чтобы не только дёргать модели через API, но и собирать на них автоматизации без своего сервера.

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

На связи Сергей Скирдин, технический директор ИТ-интегратора «Белый код». Последние два года я изучаю российский рынок ESB и интеграционных платформ, делаю обзоры на продукты. Есть интересная закономерность: многие компании, которые выбирают ESB, готовят собственный опросник. В прошлом году вместе с вендорами, мы решили составить единый опросный лист. Рассказываю и показываю, что из этого получилось.

Третья, заключительная статья из цикла.

Часть 1 — где LLM теряет межсервисный контекст и почему локальных спек недостаточно.

Часть 2 — archspec как контракт вместо свободного Markdown.

Часть 3 — archspec investigate: исследование фичи, обновление контрактов и реализация.

В части 1 я показал, что spec-driven development с LLM начинает ошибаться, когда фича проходит через несколько микросервисов: по отдельности каждый сервис выглядит аккуратно, а вместе система работает не так, как нужно. Модель теряет межсервисный контекст — правила, которые живут на границах между сервисами, не записаны в одном месте, и LLM их пропускает. В части 2 я собрал archspec: на каждый сервис генерируется машиночитаемый контракт SERVICE_MAP.yaml, который делает эти правила явными.

В этой части я беру ту же фичу — автоматическое переназначение задачи после отказа фрилансера — и прогоняю её заново через /archspec:investigate, но уже поверх контрактов. Тот же промпт, та же модель (Claude Sonnet 4.6). Вопрос один: поймает ли план те межсервисные ошибки, на которых в первый раз фича не сошлась, ещё до написания кода — и где спотыкается уже сам инструмент.

Разберемся, как на самом деле устроена интеграция Flyway в Spring Boot 4: что изменилось с появлением отдельного starter’а, как Boot прокидывает настройки и почему в связке с PostgreSQL одна неочевидная опция может намертво зависнуть миграцию