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

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

6. Развертывание

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

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

Краткое введение в непрерывную интеграцию

Понятие непрерывной интеграции (continuous integration (CI)) существует уже несколько лет. Но на объяснение ее основ все же стоит потратить немного времени, особенно при обдумывании отображений между микросервисами, сборок и хранилищ управления версиями, требующем рассмотрения нескольких разных вариантов.

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

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

Вскоре мы рассмотрим, какого именно сорта артефакты можно будет использовать для микросервисов, а о тестировании более подробно поговорим в главе 7.

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

А вам приходилось этим заниматься? Подозреваю, что вы уже использовали непрерывную интеграцию в своей организации. Если нет, то пора приступить к ее применению. Дело в том, что это основной способ, позволяющий быстрее и легче вносить изменения, и без него путь к микросервисам будет слишком труден. Мне приходилось работать с командами, которые, несмотря на заявления о применении CI, вообще ею не пользовались. Они путали применение CI-инструментария с внедрением практического использования CI. Инструментарий — лишь средство, позволяющее применить сам подход.

Мне нравятся три вопроса, которые Джез Хамбл (Jez Humble) задает людям, чтобы проверить, правильно ли они понимают, что такое CI.

• Вы проходите ежедневную проверку в основной программе?

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

• Имеется ли у вас набор тестов для проверки правильности вносимых вами изменений?

Без тестов мы просто знаем, что синтаксически интеграция работает, но не знаем, не нарушим ли поведение системы. CI без ряда проверок, подтверждающих ожидаемое поведение кода, — это не CI.

• Служит ли исправление неисправной сборки главным приоритетом команды?