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

Чаще всего для этого я пользуюсь Fabric, библиотекой языка Python, предназначенной для отображения вызовов командной строки на функции, наряду с такой хорошей поддержкой задач обработки на удаленных машинах, как SSH. Соедините это с такой клиентской библиотекой AWS, как Boto, и у вас будет все необходимое для полной автоматизации очень крупных сред AWS. Для Ruby в некотором роде аналогом Fabric может послужить Capistrano, а для Windows можно воспользоваться PowerShell.

Определение среды. Разумеется, чтобы все это заработало, нужен способ определения того, на что похожа наша среда и на что похож наш сервис в заданной среде. Определение среды можно представить себе как отображение микросервиса на вычислительные ресурсы, сетевые ресурсы или ресурсы хранилища. Раньше я делал это с помощью YAML-файлов и для помещения в них данных использовал свои сценарии. В примере 6.1 показана упрощенная версия той работы, которую я делал года два назад для проекта, использующего AWS.

Пример 6.1. Пример определения среды

development:

nodes:

—ami_id: ami-e1e1234

size: t1.micro (1)

credentials_name: eu-west-ssh (2)

services: [catalog-service]

region: eu-west-1

production:

nodes:

—ami_id: ami-e1e1234

size: m3.xlarge (1)

credentials_name: prod-credentials (2)

services: [catalog-service]

number: 5 (3)

1. Размер используемых экземпляров варьируется с целью получения более высокого экономического эффекта. Для исследовательского тестирования не нужна 16-ядерная стойка с 64 Гбайт оперативной памяти!

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

3. Мы решили, что по умолчанию, если у сервиса имелось более одного сконфигурированного узла, для него будет автоматически создаваться система обеспечения сбалансированности нагрузки.

Некоторые детали для краткости были удалены.

Информация о сервисе каталога была сохранена в другом месте. Как видно из примера 6.2, от среды к среде она не изменяется.

Пример 6.2. Пример определения среды

catalog-service:

puppet_manifest: catalog.pp (1)

connectivity:

—protocol: tcp

ports: [8080, 8081]

allowed: [WORLD]

4. Это было имя запускаемого Puppet-файла. Так уж получилось, что в данной ситуации мы использовали только Puppet, но теоретически могли бы воспользоваться и поддержкой альтернативных систем управления настройками.

Вполне очевидно, что многие моменты поведения были основаны на соглашениях. Например, мы решили нормализовать используемые сервисом порты, где бы он ни запускался, и автоматически настроили систему обеспечения сбалансированности нагрузки в том случае, если у сервиса имеется более одного экземпляра (в AWS с этим довольно легко справляется ELB).

Создание систем, подобных этой, требует существенного объема работы. Усилия зачастую нужно прикладывать на начальном этапе, но они могут иметь большое значение для управления возникающими сложностями развертывания. Я надеюсь, что в будущем вам не придется делать это самим. Уже есть новейшее средство под названием Terraform от Hashicorp, которое работает именно в этой области. Я, как правило, уклоняюсь от упоминания в книге подобных новых средств, поскольку она посвящена скорее идеям, а не технологиям, но попытки создания средств с открытым кодом, работающих в данном направлении, предпринимаются. Хотя говорить об этом еще слишком рано, но уже существующие возможности представляются весьма интересными. Имея возможность нацеливания развертываний на различные платформы, в будущем вы можете сделать это средство своим рабочим инструментом.

Резюме

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

Затем, если есть такая возможность, перейдите к схеме, предполагающей размещение одного сервиса на каждом хосте или в каждом контейнере. Чтобы удешевить и облегчить управление перемещаемыми частями, обратите внимание на альтернативные технологии, такие как LXC или Docker, но при этом отнеситесь с пониманием к тому, что, какую бы технологию вы ни взяли на вооружение, ключом к управлению всеми аспектами служит культура автоматизации. Автоматизируйте все, что можно, и если используемая вами технология не позволяет этого сделать, перейдите на новую технологию! Когда дело дойдет до автоматизации, огромные преимущества вам даст возможность использования платформы, подобной AWS.