Граница сервиса важнее количества приложений
Полезная граница связана с самостоятельной задачей: каталог описывает товары, заказ хранит состояние покупки, доставка рассчитывает доступные варианты. Это учебный пример, а не обязательная схема для любого магазина. Если изменение одного поля требует одновременного выпуска всех компонентов, независимость оказывается ограниченной. Перед разделением стоит записать, кто владеет данными и какие сведения передаёт наружу. Добавление сетевого вызова превращает простой обмен внутри процесса в взаимодействие, где возможны задержки, потеря ответа и временная недоступность.
Инструменты решают разные задачи
Spring Cloud Config помогает работать с внешней конфигурацией, Gateway организует маршрутизацию запросов, а механизмы обнаружения сервисов помогают находить экземпляры. Circuit Breaker предоставляет средства для ограничения обращения к проблемной зависимости. Наличие одного компонента не выполняет задачи остальных. Например, успешная маршрутизация не гарантирует корректность состояния заказа. Версии компонентов также не выбирают независимо наугад: совместимость Spring Cloud со Spring Boot проверяют для выбранной линии выпусков. Архитектурная схема должна отражать назначение инструментов, а не просто перечислять знакомые названия.
Ожидание и повтор имеют цену
У сетевого обращения нужен осмысленный предел ожидания. При этом тайм-аут сообщает, что ожидающий компонент не получил ответ вовремя; он не доказывает, что сосед ничего не сделал. Представим создание заказа: операция завершилась, но ответ потерялся. Без продуманной защиты повтор может создать второй заказ. Поэтому повторяемость проектируют вместе с идентификатором операции и правилами обработки дублей. Число повторов и паузы ограничивают: множество клиентов, бесконечно повторяющих запросы, усиливает нагрузку именно тогда, когда зависимость уже испытывает трудности.
Запасной ответ должен сохранять смысл
Circuit Breaker может временно прекращать обычные обращения к зависимости при неблагоприятных результатах, позволяя системе реагировать быстрее. Но он не определяет бизнес-смысл ответа. Для недоступных рекомендаций допустимо показать страницу без подборки. Для неподтверждённой операции нельзя выдавать успешный результат только ради зелёного индикатора. Нужно явно различать отказ, ожидание уточнения и завершение. Наблюдаемость помогает проследить путь запроса: сопоставить события, задержки и ошибки нескольких сервисов, не включая секреты или лишние персональные данные в журналы.
Попробуйте на практике
Спроектируйте на бумаге обработку запроса, который сохраняет заказ и затем получает оценку времени доставки. Запуск приложений не требуется.
- Нарисуйте два сервиса и обозначьте, кто хранит заказ, а кто сообщает предварительную оценку доставки.
- Для каждого обращения запишите ожидаемый результат и отдельный исход при отсутствии ответа в пределах установленного ожидания.
- Разберите случай, когда заказ сохранён, но ответ о сохранении потерян. Опишите, как повторный запрос будет связан с той же операцией.
- Выберите честный ответ при недоступной оценке доставки, который не отменяет уже сохранённый заказ и не выдумывает срок.
- Определите сведения для проверки сценария: идентификатор операции, состояние заказа, исход обращения и длительность ожидания.
Как проверить результат. Схема различает потерянный ответ и невыполненное действие, учитывает дубли и описывает понятное пользователю состояние при частичном сбое.
Частые вопросы
Нужен ли отдельный сервис для каждой таблицы?
Нет. Таблица отражает способ хранения, а граница сервиса связана с ответственностью и правилами изменения данных. Механическое разделение таблиц может создать множество зависимых сетевых вызовов.
Circuit Breaker заменяет тайм-аут?
Нет. Это разные механизмы. Ограничение ожидания относится к длительности обращения, а размыкатель управляет допуском последующих обращений согласно своей конфигурации и наблюдаемым результатам.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.