В главе 1 мы отметили, что минимизация затрат на координацию — основной метод архитектуры микросервисов. Этот показатель настолько фундаментальный, что команды, которые смогут продемонстрировать тенденцию к снижению потребности в координации, преуспеют независимо от того, скольких принципов Ньюмана, Льюиса, Фаулера или Митры/Надареишвили они придерживаются изначально.
В своей основополагающей работе по сложности программного обеспечения — статье «Серебряной пули нет» (http://worrydream.com/refs/Brooks-NoSilverBullet.pdf), опубликованной в 1986 году, Фред Брукс метко отмечает:
«Нет ни одной разработки ни в технологии, ни в методике управления, которая сама по себе обещала бы хотя бы на порядок повысить производительность, надежность и простоту».
Если вы обнаружите, что часто вносите изменения сразу в несколько моделей данных, то это может быть признаком необходимости переоценки границ микросервисов.
Чтобы запустить нашу систему как можно быстрее, мы не включили компонент контрактного тестирования в архитектуру. Но многие практикующие специалисты добились успеха, используя Pact (https://pact.io) для тестирования контрактов, ориентированных на потребителя
Если вы заинтересованы в создании эволюционирующих API, то мы рекомендуем изучить шаблоны изменения API в его книге Design and Build Great Web APIs (Pragmatic Bookshelf, 2020).
Время простоя микросервисов Еще одна область изменений, которую мы оптимизировали, — минимизация времени простоя, необходимого при изменении отдельного микросервиса. Это связано с инструментарием и инфраструктурой, которые мы внедрили на уровне платформы. Ключом к снижению этих затрат выступает возможность применения канареечного шаблона развертывания
