Создание микросервисов

Роль, которую могут играть принципы, мы рассматривали в главе 2. Принципы складываются из утверждений о том, как все должно делаться, и из разъяснения причин, по которым все должно делаться именно таким образом. Они помогают нам выстроить различные решения, которые приходится принимать при создании наших систем. Конечно же, вы должны определить собственные принципы, но я считаю, что есть смысл изложить мое видение того, как выглядят ключевые принципы микросервисных архитектур, обобщенный вид которых представлен на рис. 12.1. Эти принципы призваны помочь нам в создании небольших автономных сервисов, успешно выполняющих совместную работу. Все они по крайней мере единожды уже были рассмотрены в этой книге, поэтому ничего нового вы здесь не найдете, но ценность рисунка определяется тем, что в нем передана только суть.

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

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

Рис. 12.1. Принципы микросервисов

Модель, построенная вокруг бизнес-концепций

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

Внедрение культуры автоматизации

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

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

Сокрытие подробности внутренней реализации

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

При любой возможности отдавайте предпочтение применению технологически нейтральных API-интерфейсов, чтобы получить свободу использования различных технологических стеков. Подумайте о применении технологии передачи репрезентативного состояния REST, оформляющей разделение подробностей внутренней и внешней реализации which. Те же самые идеи можно принять за основу и при использовании удаленных вызовов процедур (RPC).

Всесторонняя децентрализация