Разбивка монолитного приложения на микросервисы

с помощью Amazon Elastic Container Service, Docker и Amazon EC2

Контейнеризация монолитного приложения

Развертывание монолитного приложения

Разбивка монолитного приложения

Модуль 4. Развертывание микросервисов

В этом модуле вы выполните развертывание приложения node.js в виде набора взаимосвязанных сервисов на базе балансировщика нагрузки приложений Application Load Balancer (ALB). Затем вы используете балансировщик ALB, чтобы легко переместить трафик с монолитной архитектуры на микросервисы. Начать разработку

Обзор архитектуры

Это процесс для развертывания микросервисов и безопасного переноса трафика приложения с монолитной архитектуры.

Переключите трафик
Это начальная конфигурация. Монолитное приложение node.js запущено в контейнере сервиса Amazon ECS.
Начните работу с микросервисами
Используя три образа контейнера, созданные и отправленные в Amazon ECR в предыдущем модуле, вы запустите три микросервиса в существующем кластере Amazon ECS.
Настройте целевые группы
Как и в модуле 2, вы добавите целевую группу для каждого сервиса и обновите правила ALB, чтобы подключить новые микросервисы.
Завершите работу монолитного сервиса
Изменяя одно правило в ALB, вы начнете распределять трафик на работающие микросервисы. Проверьте правильность перенаправления трафика и завершите работу монолитного сервиса.

Время выполнения: 30 минут

Используемые сервисы:

Инструкции по внедрению

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

Шаг 1. Запись определений задач для сервисов
Вы выполните развертывание трех новых сервисов в кластере, запущенном в модуле 2. Как и в модуле 2, вы запишете определения задач для каждого сервиса.

⚐ ПРИМЕЧАНИЕ. К одному определению задачи можно добавить несколько контейнеров. Это означает, что все три микросервиса можно запустить из одного сервиса в виде разных контейнеров. Однако этот подход все еще монолитный, поскольку каждый контейнер должен линейно масштабироваться с сервисом. Ваша цель – создать три независимых сервиса. Для каждого сервиса требуется отдельное определение задачи по запуску контейнера с образом для этого сервиса.

Вы можете создать эти определения задач в консоли Amazon ECS или ускорить процесс, записав их в формате JSON. Чтобы записать определение задачи в виде файла JSON, выполните шаги, указанные ниже.

В консоли Amazon Container Services в разделе Amazon ECS выберите Определение задач.

На странице Определения задач нажмите кнопку Создать новое определение задачи.

На странице Выбор совместимости типа запуска выберите вариант EC2 и нажмите кнопку Следующий шаг.

Прокрутите страницу настройки определений задач и контейнеров до раздела Тома и нажмите кнопку Настроить с помощью JSON.

Скопируйте и вставьте следующий фрагмент кода в поле JSON, заменив существующий код.
Не забудьте заменить заполнители [имя сервиса], [идентификатор аккаунта], [регион] и [тег].

⚐ Примечание. Для определения задачи используются следующие параметры.

Имя = [имя сервиса: posts, threads, users]

Образ = [URL-адрес образа в репозитории Amazon ECR]:latest

ЦПУ = 256

Память = 256

Порт контейнера = 3000

Публикация на хосте = 0
```
{
    "containerDefinitions": [
        {
            "name": "[service-name]",
            "image": "[account-id].dkr.ecr.[region].amazonaws.com/[service-name]:[tag]",
            "memoryReservation": "256",
            "cpu": "256",
            "essential": true,
            "portMappings": [
                {
                    "hostPort": "0",
                    "containerPort": "3000",
                    "protocol": "tcp"
                }
            ]
        }
    ],
    "volumes": [],
    "networkMode": "bridge",
    "placementConstraints": [],
    "family": "[service-name]"
}
```
♻ Повторяйте шаги, чтобы создать определение задачи для каждого сервиса:

posts (публикации)

threads (потоки)

users (пользователи)
Шаг 2. Настройка целевых групп для Application Load Balancer
Как и в модуле 2, настройте целевую группу для каждого сервиса (posts, threads и users). Наличие целевой группы позволяет трафику правильно достигать указанного сервиса. Вы настроите целевую группу с помощью интерфейса командной строки AWS. Но прежде чем продолжить, убедитесь, что у вас есть правильное имя VPC, которое используется для этого обучения.

Перейдите в раздел балансировщика нагрузки в консоли EC2.

Установите флажок рядом с demo, перейдите на вкладку Описание и найдите атрибут VPC (в этом формате: vpc-xxxxxxxxxxxxxxxxx).
⚐ Примечание. Атрибут VPC потребуется вам при настройке целевых групп.

Настройте целевые группы

В терминале введите следующую команду, чтобы создать целевую группу для каждого сервиса (posts, threads и users). Кроме того, вы создадите целевую группу, отвод трафика (drop-traffic), чтобы трафик не достигал монолитного сервиса после полного запуска микросервисов. Не забудьте заменить следующие заполнители: [регион], [имя сервиса] и [атрибут vpc].

Имена сервисов: posts, threads, users и drop-traffic
```
aws elbv2 create-target-group --region [region] --name [service-name] --protocol HTTP --port 80 --vpc-id [vpc-attribute] --healthy-threshold-count 2 --unhealthy-threshold-count 2 --health-check-timeout-seconds 5 --health-check-interval-seconds 6
```
Шаг 3. Настройка правил прослушивателя
Прослушиватель проверяет наличие входящих запросов на подключение к вашему балансировщику ALB для правильной маршрутизации трафика.

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

Установите доступ к правам прослушивателя

Перейдите в раздел балансировщика нагрузки в консоли EC2.

Найдите балансировщик нагрузки с именем demo и чтобы отобразить сведения о нем, установите рядом флажок.

Перейдите на вкладку Прослушиватели.

Обновите правила прослушивателя

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

В столбце Правила выберите запись Просмотр/редактирование правил.

На странице Правила нажмите кнопку со знаком «плюс» (+).
На странице отобразится параметр Вставка правила.

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

IF Path = /api/[имя сервиса]* THEN Forward to [имя сервиса]
Пример: IF Path = /api/posts* THEN Forward to posts

Вставляйте правила в следующем порядке:

api: /api* перенаправление к api

users: /api/users* перенаправление к users

threads: /api/threads* перенаправление к threads

posts: /api/posts* перенаправление к posts

Нажмите кнопку Сохранить.

Нажмите на стрелку возврата в левом верхнем углу страницы, чтобы вернуться к консоли балансировщика нагрузки.
Шаг 4. Развертывание микросервисов
Выполните развертывание трех микросервисов (posts, threads и users) в своем кластере. Повторяйте указанные ниже шаги для каждого из трех микросервисов.

Перейдите в консоль Amazon ECS и в расположенной слева строке меню выберите пункт Кластеры.

Выберите кластер BreakTheMonolith-Demo, перейдите на вкладку Сервисы и выберите пункт Создать.

На странице Настройка сервиса измените указанные ниже параметры (а для параметров, не указанных ниже, оставьте значения, используемые по умолчанию).

Для параметра Тип запуска выберите значение EC2.

Для параметра Определение задачи нажмите кнопку Ввод значения, чтобы автоматически выбрать максимальное значение изменения.
Пример: api:1

В параметре Имя сервиса введите имя сервиса (posts, threads или users).

Для параметра Количество задач введите значение 1.

Нажмите кнопку Следующий шаг.

На странице Настройка сети в разделе Балансировка нагрузки выполните указанные ниже действия.

Для параметра Тип балансировщика нагрузки выберите значение Application Load Balancer.

Для параметра Роль IAM сервиса выберите значение BreakTheMonolith-Demo-ECSServiceRole.

Убедитесь, что для параметра Имя балансировщика нагрузки выбрано значение demo.

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

Для параметра Порт прослушивателя рабочей среды выберите значение 80:HTTP.

Для параметра Имя целевой группы выберите соответствующую группу: (posts, threads или users)

Нажмите кнопку Следующий шаг.

На странице Настройка Auto Scaling нажмите кнопку Следующий шаг.

На странице Проверка выберите пункт Создать сервис.

Нажмите кнопку Просмотреть сервис.

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

Перейдите в раздел балансировщика нагрузки в консоли EC2.

Установите флажок рядом с элементом demo, чтобы отобразить сведения об этом балансировщике нагрузки.

Перейдите на вкладку Прослушиватели.
В списке должен быть только один прослушиватель.

В столбце Правила выберите запись Просмотр/редактирование правил.

В главном меню на странице Правила нажмите кнопку со знаком «минус» (–).

Удалите первое правило (/api* forwards to api). Для этого установите флажок рядом с ним.

Нажмите Удалить.

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

Для этого в меню вверху нажмите кнопку редактирования (карандаш).

Нажмите пиктограмму редактирования (карандаш) рядом с правилом, используемым по умолчанию (HTTP 80: default action).

Нажмите пиктограмму редактирования (карандаш) в столбце THEN, чтобы изменить значение Forward to.

В поле Целевая группа выберите пункт drop-traffic.

Нажмите кнопку Обновить.

На следующем снимке экрана показан пример обновленных правил.
Отключите монолитный сервис. Поскольку трафик теперь поступает на микросервисы, монолитный сервис можно отключить.

Вернитесь в кластер сервиса Amazon ECS BreakTheMonolith-Demo-ECSCluster.

На вкладке Сервисы установите флажок рядом с пунктом api и нажмите кнопку Обновить.

На странице Настройка сервиса найдите параметр Количество задач и введите значение 0.

Нажмите кнопку Перейти к проверке.

Нажмите кнопку Обновить сервис.

После этого сервис Amazon ECS очистит соединения от контейнеров, развернутых сервисом в кластере, а затем остановит работу контейнеров. Если обновить списки развертываний или задач примерно через 30 секунд, можно увидеть, что количество задач снизилось до значения «0». Сервис по-прежнему активен. Если по какой-либо причине требуется выполнить откат, можно просто обновить его, чтобы развернуть дополнительные задачи.

При необходимости можно удалить сервис api. На вкладке Сервисы установите флажок рядом с пунктом api, нажмите кнопку Удалить и подтвердите удаление.

Теперь вы полностью переместили свое приложение node.js с монолитного сервиса на микросервисы без каких-либо простоев!
Шаг 6. Проверка правильности развертывания
Найдите URL-адрес сервиса. Такой же URL-адрес уже использовался в модуле 2 этого учебного пособия.

Для этого перейдите в раздел балансировщика нагрузки в консоли EC2.

Установите флажок рядом с элементом demo, чтобы отобразить сведения об этом балансировщике нагрузки.

На вкладке Описание найдите пункт Имя DNS и нажмите пиктограмму копирования после URL-адреса.

Вставьте имя DNS в новую вкладку или окно браузера.

Отобразится сообщение «Готов к приему запросов».

Просмотрите значения для каждого микросервиса. Ваш балансировщик ALB маршрутизирует трафик на основании URL-адреса запроса. Чтобы просмотреть каждый сервис, просто добавьте имя сервиса в конец имени DNS:

http://[DNS-имя]/api/users

http://[DNS-имя]/api/threads

http://[DNS-имя]/api/posts
⚐ ПРИМЕЧАНИЕ. Эти URL-адреса работают точно так же, как и в архитектуре монолитного приложения. Это очень важно, поскольку внесенные вами изменения не повлияют на интерфейсы API или клиентов, которые ожидают подключения к этому приложению. Переход от монолитного сервиса к микросервисам не требует изменений в других частях инфраструктуры.

Для тестирования интерфейса API также можно использовать инструмент Postman.