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

Около года назад я написал первую часть статьи о Single SPA — о том, как я выбирал архитектурный подход, боролся с монолитом и пробовал собрать первые микрофронтенды. В статье были разобраны базовые принципы работы Single SPA, подключение importmap, сравнение с другими архитектурными решениями и настройка сборки на Webpack и Vite.

Эта статья — продолжение цикла. Здесь я поделюсь практикой: как на самом деле живётся с Single SPA, какие есть подводные камни и что можно вынести в виде рекомендаций.

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

Статья о реализации сервиса на C++ с применением TDD, DDD и событийно-ориентированной архитектуры. Проект переносит идеи из книги «Паттерны разработки на Python: TDD, DDD и событийно-ориентированная архитектура» на C++.

Привет, дорогой читатель! Я, Владимир Зиновьев, ведущий тестировщик в ИТ-команде «Северстали». Если тебя заинтересовала эта статья, то скорее всего ты такой же тестировщик, как и я, и задаёшься вопросом, как эффективно выстроить свою работу. Здесь я поделюсь долгим путём нашей команды со всеми «шишками» и успехами тестирования наших систем в большом MES-проекте. Особенно я бы порекомендовал обратить внимание на раздел с тестированием «Legacy-системы», так как там применялись довольно нестандартные и интересные подходы, по-моему мнению, конечно. Давай погружаться.

Мир веб‑разработки давно вышел за пределы простых проектов. Статьи про «Hello, world» больше не спасают, когда нужно собирать масштабируемые приложения для реальных пользователей. Что выбрать — монолит или микросервисы? REST или GraphQL? React, Vue или Angular? Node.js, Python или Go? Какая база данных лучше подойдёт — реляционная или NoSQL? Нужно ли кэширование? Как настроить CI/CD, контейнеризацию и мониторинг? И почему нельзя забывать о мобильной версии и SEO? В этой статье я делюсь опытом, описываю архитектурные подходы, сравниваю основные технологии и инструменты, рассказываю о бэкенд‑ и фронтенд‑best practices, базах данных, кэшировании, DevOps, мониторинге и оптимизации. Каждая тема подкреплена примерами и ссылками на источники. Материал рассчитан на тех, кто хочет уверенно руководить полным циклом разработки — от планирования до продакшна. Если вы давно ищете структурированное руководство по современному фулл‑стеку, оно перед вами. Из этого путеводителя вы также узнаете об оптимизации производительности Node.js (gzip, асинхронность, логирование), работе с графами данных и типизации GraphQL, особенностях React (hooks, SSR), Vue, Angular, Tailwind и shadcn/ui, выборе баз данных, настройке кэширования Redis, задачах CI/CD и Dockerfile, Kubernetes, а также об инструментах мониторинга и SEO, включая мобильную адаптивность и структурированные данные. Текст большой, но разбит на разделы и содержит кодовые примеры, так что вы сможете легко адаптировать идеи под свои задачи.

Здравствуйте! Антон Боев, исполнительный директор веб-интегратора DD Planet. В текущей статье поговорим о том, что внутри моей команды вызывает горячие дискуссии практически каждый день. Итак, речь пойдет об ИНТЕГРАЦИЯХ.

В нашей команде каждый день звучат одни и те же вопросы: «Как подключиться быстрее?», «Какую архитектуру использовать?», «Где взять устойчивое решение для этого сервиса?» Ответы на них не просто технические решения. Это опыт, который накапливается годами. И я хочу предложить вам посмотреть на него под неожиданным углом - как на криптовалюту веб-интегратора.

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

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

Способы интеграций, есть ли изменения?

Организовать взаимодействие двух сервисов можно разными способами:

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

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

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

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

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

Команда Альфа-Банка с нашей поддержкой перенесла CRM-платформу, которую используют сотрудники в отделениях по всей стране, на Axiom JDK и контейнеризовала её с помощью Axiom Runtime Container.

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

Нормализация vs Денормализация: Mongo, Postgres и реальная жизнь. Почему у нас вырастает 160 таблиц там, где мог быть один jsonb? И как понять, когда денормализация — это костыль, а когда осознанный выбор?

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

Привет, Хабр! Каждый раз, создавая новый эндпоинт, я ловил себя на мысли: «А как назвать маршрут?». Казалось, что где-то есть законы и правила, которые помогают создавать API последовательно. Со временем я наткнулся на диаграммы по проектированию, прочитал книгу JJ Geewax — API Design Patterns (Джей‑Джей Гивакс), изучил рекомендации от крупных компаний и понял важную мысль: проектирование API — это такая же область знаний со своими принципами и стандартами.

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

Цель статьи — дать компактную шпаргалку по проектированию API для простых CRUD‑сервисов и показать ход мыслей, который позволяет проектировать последовательно и осмысленно.

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

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

Один неправильно «пришитый» IP — и рождается фантомная зависимость. Netflix на масштабе ≈5 млн TCP-потоков/с отказался от событийного учёта адресов и построил атрибуцию на наблюдаемых таймлайнах владения IP: eBPF-сайдкар точно метит локальную нагрузку (включая Titus и связку IPv6→IPv4 по паре IP+порт), а FlowCollector держит интервалы в памяти и рассылает их через Kafka, форвардя межрегиональные кейсы по trie из VPC-CIDR. Задержка — ~1 мин вместо 15, ложных совпадений — ноль по проверке на Zuul. В итоге flow logs стали источником истины о зависимостях и «здоровье» сети.

Великий аргентинский писатель Хорхе Луис Борхес в одном из своих произведений попытался доказать, что вся мировая литература сводится к четырем базовым сюжетам: история об осаде и защите обречённого города, история о возвращении, история о поиске и история о жертвоприношении или самоубийстве бога. В комментарий к этому заявлению Виктор Пелевин в одном из своих романов написал: «А по‑моему, сюжетов всего два. Первый — как человека убивают из‑за денег. Второй — как человека приносят в жертву. А на самом деле оба сюжета можно даже объединить в один». Как бы то ни было, оставим этот спор о сюжетах литературоведам. В этом же посте я хочу разобрать схожий тезис — все архитектуры разных видов программного обеспечения можно свести к двум базовым структурам — монолиту и шине.

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

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

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

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

Предыдущая часть

Картина мира: почему браузер — главный блокер для «настоящего» gRPC

Если коротко, gRPC живёт поверх HTTP/2 и активно полагается на стримы. А в браузере до сих пор нет низкоуровневого API, который позволил бы JavaScript управлять HTTP/2‑стримами на том уровне, который нужен gRPC. Даже unary‑вызов в gRPC — это частный случай стрима: открыли поток, отдали запрос, забрали ответ, закрылись. Пока браузеры не дадут этот «рычаг», все WEB‑решения — это компромиссы разной степени изящности.

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

Нативные bidi‑стримы из браузера недоступны

Приходится конвертировать транспорт: HTTP/1.1 или WebSocket → что‑то «похоже на gRPC» → gRPC/HTTP2 на бэкенде

Добавляются прокси, адаптеры и слой совместимости, где теряется часть достоинств «чистого» gRPC

Ранее мы с вами развернули кластер Kafka. Что дальше?

В этой статье, как всегда, переходим от теории к практике: разработаем собственные продюсер и консьюмер на Python. Это будет не просто демонстрация кода — мы погрузимся в детали работы с Kafka.

Подробно разберем структуру сообщений Kafka,

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

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