Книга Sam Newman ценна не тем, что уговаривает перейти на микросервисы, а тем, что показывает их полную цену.
Для реального проектирования глава помогает увидеть, как декомпозиция, коммуникация, развёртывание, тестирование и организационные паттерны должны собираться в один операционный контур, а не жить разрозненными практиками.
Для интервью и инженерных разборов она полезна тем, что помогает обсуждать микросервисы через пробелы платформы: отсутствие CI/CD, трассировки, управления контрактами и других вещей, без которых сервисная архитектура быстро деградирует.
Практическая польза главы
Практика проектирования
Проектируйте сервисные границы вместе с владением данными и ответственностью команды.
Качество решений
Связывайте развёртывание, тестирование и наблюдаемость в единый инженерный контур.
Аргументация на интервью
Показывайте не только целевую картинку сервисов, но и путь безопасного запуска.
Анализ отказов
Учитывайте пробелы платформы: CI/CD, трассировку, управление контрактами и поддержку дежурства.
Связанная книга
От монолита к микросервисам
Практическое продолжение: как применять идеи Newman при миграции существующей системы.
Building Microservices, 2nd Edition (Микросервисы и интеграция)
Авторы: Sam Newman
Издательство: O'Reilly Media, 2021 (2nd Edition)
Объём: 612 страниц
Разбор книги Sam Newman: сервисные границы, независимое развёртывание, коммуникация, данные, тестирование, наблюдаемость и эксплуатационная цена микросервисов.
В этой главе микросервисная архитектура начинается с , и . Newman показывает, что сервисы становятся полезными только вместе с дисциплиной , , и .
Главная мысль книги проста и неприятна: микросервисы покупают автономию ценой распределённой сложности, поэтому их нельзя рассматривать отдельно от команд, данных, платформы и эксплуатации.
Структура книги
Второе издание удобно читать как маршрут: сначала понять, где границы сервисов, затем научиться их выпускать и соединять, а потом оценить организационную цену такого выбора.
Часть I: основы
Что делает сервис микросервисом, как выбирать и как разделять монолит и данные.
Часть II: реализация
Коммуникация, бизнес-процессы, , тестирование, и безопасность.
Часть III: эксплуатация
, масштабирование, организационные структуры и цена владения микросервисами.
Часть I: основы микросервисов
Что делает сервис микросервисом
Хорошие сигналы:
- Сервис можно от соседей.
- Граница проходит вокруг понятной .
- Команда владеет кодом, и эксплуатацией.
- устойчив к эволюции клиентов.
Когда лучше не спешить:
- Домен ещё плохо понятен и часто меняет форму.
- Команда слишком мала для отдельной операционной нагрузки.
- Разделение создаёт больше сетевых проблем, чем автономии.
- остаётся главным контрактом между сервисами.
Связанная книга
Learning Domain-Driven Design
Подробный разбор ограниченных контекстов, языка модели и отношений между командами.
Моделирование сервисных границ
DDD помогает не просто нарезать код, а найти места, где меняются правила, язык и ответственность.
Ограниченный контекст
- собственные правила и
- и понятные изменения
- один контекст может содержать один или несколько сервисов
Карта контекстов
- видно, кто поставляет модель, а кто её потребляет
- можно явно выбрать , или
- споры о границах переводятся из вкуса в архитектурное решение
Разделение монолита
Newman не предлагает «переписать всё». Он показывает, как вытаскивать поведение постепенно и сохранять контроль над риском.
Strangler Fig
Старая функция постепенно вытесняется новым сервисом за стабильным маршрутом.
Branch by Abstraction
Абстракция отделяет вызывающий код от старой и новой реализации до переключения.
Параллельный запуск
Старый и новый путь работают рядом, пока команда сравнивает поведение и снижает риск.
Разделение данных
Как отделять хранилище:
- как целевое состояние.
- только как временный этап миграции.
- для ограниченного чтения.
- , когда прямой доступ нужно закрывать постепенно.
Как синхронизировать изменения:
- через Debezium для синхронизации старого и нового контура.
- для бизнес-операций через несколько сервисов.
- для надёжной публикации.
- Явная работа с , а не надежда на мгновенное совпадение данных.
Часть II: реализация
Связанный кейс
API Gateway
Практический пример единой входной точки: маршрутизация, доступ, лимиты и бэкенд для фронтенда.
Коммуникация между сервисами
Синхронное взаимодействие:
REST
простота, совместимость, понятная документация через OpenAPI
gRPC
строгие , высокая скорость и удобство для внутренних вызовов
GraphQL
гибкая выборка данных, когда клиенты часто отличаются по потребностям
Асинхронное взаимодействие:
Брокеры сообщений
Kafka, RabbitMQ и AWS SQS помогают снизить отправителя и получателя
Событийный стиль
сервисы публикуют , а не вызывают соседей напрямую
Асинхронный запрос-ответ
correlation ID и ответные очереди нужны, когда результат приходит позже
Бизнес-процессы между сервисами
Длинные бизнес-сценарии редко укладываются в один запрос, поэтому нужно выбрать, где живёт координация и как выполняются компенсации.
Оркестрация
- есть явный координатор процесса
- проще видеть состояние и ошибки
- подходит для сложных бизнес-сценариев с компенсациями
- может стать центральной точкой
Хореография
- каждый сервис реагирует на события
- меньше центрального управления
- сложнее восстановить полную картину процесса
- требует зрелой и дисциплины событий
Сборка и развёртывание
Непрерывная доставка превращает микросервисы из набора репозиториев в систему, которую можно выпускать маленькими безопасными шагами.
Контейнерные образы
Docker и реестр образов делают поставку сервиса воспроизводимой.
Платформа Kubernetes
Берёт на себя запуск, и восстановление экземпляров.
GitOps
ArgoCD и Flux помогают держать окружения в декларативном и проверяемом состоянии.
Тестирование
Чем больше сервисов, тем важнее разделять быстрые проверки внутри сервиса, контрактные проверки и дорогие сквозные сценарии.
Модульные
Подтверждают:
Примеры: JUnit, pytest, Jest
Интеграционные
Подтверждают: Хранилище, брокер, внешние API
Примеры: Testcontainers, WireMock
Контрактные
Подтверждают:
Примеры: Pact, Spring Cloud Contract
Сквозные
Подтверждают:
Примеры: Cypress, Playwright
Наблюдаемость и безопасность
Наблюдаемость:
- структурированные логи и единый поиск по ним
- метрики сервиса через Prometheus и Grafana
- через Jaeger, Zipkin или OpenTelemetry
Безопасность:
- взаимная аутентификация сервисов и через Istio или Linkerd
- шлюз API для проверки доступа и ограничения частоты запросов
- и управление секретами через Vault или облачные сервисы
Часть III: люди и эксплуатация
Устойчивость и масштабирование
Паттерны устойчивости:
- — быстро прекращает вызовы к деградировавшей зависимости
- — ограничивает радиус поражения при сбое
- — не даёт запросу ждать бесконечно
- — уменьшает риск перегрузить уже больную зависимость
Масштабирование:
- Горизонтальное масштабирование — добавляет экземпляры сервиса вместо усиления одного узла
- Автомасштабирование — меняет число экземпляров по метрикам нагрузки
- Кэширование — снижает давление на дорогие зависимости через Redis или сеть доставки контента
- — помогает, когда пути записи и чтения требуют разных моделей
Организационные структуры
«Организации, проектирующие системы, вынуждены создавать архитектуры, похожие на собственную структуру коммуникации».
— закон Конвея
Топология команд:
- — владеют бизнес-потоком от кода до эксплуатации
- Платформенные команды — дают внутреннюю платформу и снижают повторяющуюся инфраструктурную работу
- Помогающие команды — временно усиливают продуктовые команды экспертизой
- Команды сложных подсистем — берут на себя редкие технически сложные части системы
Практики владения:
- : маленькая автономная группа с понятной зоной ответственности.
- : команда сопровождает то, что выпускает.
- : команды могут улучшать соседние сервисы через согласованные правила.
- : структура команд меняется под желаемую архитектуру.
Ключевые выводы
Что делать:
- Начинать с монолита, если предметная область ещё не ясна.
- Считать главным практическим критерием микросервиса.
- Проектировать вместе с границами сервиса.
- Инвестировать в наблюдаемость и с первого дня.
Чего избегать:
- Делить систему на сервисы только потому, что это модно.
- Создавать с общими релизами и общей базой.
- Оставлять долгосрочным контрактом между командами.
- Игнорировать организационную структуру: она всё равно проявится в архитектуре.
Для кого эта книга
Особенно полезна:
- архитекторам, которые проектируют сервисные границы;
- техлидам, отвечающим за эволюцию продукта и команды;
- разработчикам в растущих командах, где один монолит уже тормозит изменения;
- кандидатам, готовящимся обсуждать микросервисы на интервью по системному дизайну.
Лучше читать, если уже есть:
- опыт разработки веб-приложений;
- понимание базовых идей распределённых систем;
- общее знакомство с Docker и платформой Kubernetes;
- готовность обсуждать не только код, но и команды, релизы и эксплуатацию.
Совет: читать вместе с DDIA: Kleppmann даёт глубокую теорию распределённых данных, а Newman показывает, как эта теория превращается в команды, сервисы, контракты и операционную практику.
Связанные главы
- Зачем нужны микросервисы и интеграция - Контекст раздела: зачем нужны границы сервисов, контракты API и разные способы взаимодействия между командами.
- Стратегии декомпозиции - Практическая карта выбора сервисных границ до того, как команда начнёт выделять код и данные.
- Learning Domain-Driven Design (short summary) - DDD-основа для ограниченных контекстов, языка модели и более устойчивого распределения ответственности.
- Паттерны межсервисной коммуникации - Следующий слой после книги Newman: синхронные вызовы, асинхронные сообщения, тайм-ауты и устойчивые контракты.
- Monolith to Microservices (short summary) - Практическое продолжение: как мигрировать от монолита к сервисам без остановки продукта и большого взрыва.
- Software Architecture: The Hard Parts (краткий обзор) - Глубже про распределённые решения: владение данными, транзакции и координация между сервисами.