День 1546. #Microservices
12 Способов Улучшить Монолит Перед Переходом на Микросервисы. Продолжение
Начало

6. Установите API-шлюз или обратный HTTP-прокси.
По мере развёртывания микросервисов необходимо разделять входящий трафик. Мигрированные функции предоставляются новыми сервисами, а старая функциональность обслуживается монолитом. Существует несколько способов маршрутизации запросов в зависимости от их характера:
- API-шлюз https://t.me/NetDeveloperDiary/1106 позволяет перенаправлять вызовы API на основе таких условий, как аутентифицированность пользователя, файлы cookie, флаги функций или шаблоны URI.
- Обратный HTTP-прокси делает то же самое, но для HTTP-запросов.
В большинстве случаев монолит реализует пользовательский интерфейс, поэтому большая часть трафика будет идти туда, по крайней мере, поначалу.
Используйте API-шлюзы и обратные прокси для маршрутизации запросов к соответствующей конечной точке. Вы можете переключаться между монолитом и микросервисами на очень мелком уровне. После завершения миграции шлюзы и прокси-серверы останутся: они являются стандартным компонентом любого микросервисного приложения, поскольку обеспечивают переадресацию и балансировку нагрузки. Они также могут функционировать как автоматические выключатели, если сервис выходит из строя.

7. Рассмотрите паттерн «монолит в коробке» (monolith-in-the-box)
Это применимо только в том случае, если вы планируете использовать контейнеры или Kubernetes для микросервисов. В этом случае контейнеризация может помочь вам гомогенизировать вашу инфраструктуру. Паттерн «монолит в коробке» заключается в запуске монолита внутри контейнера.
Если вы никогда раньше не работали с контейнерами, это хорошая возможность познакомиться с этой технологией. Нужно многому научиться, поэтому спланируйте обучение:
1) Изучите Docker и контейнеры.
2) Запустите свой монолит в контейнере.
3) Разрабатывайте и запускайте микросервисы в контейнере.
4) После завершения миграции и освоения контейнеров изучите Kubernetes.
5) По ходу работы можно масштабировать микросервисы и постепенно переводить на них трафик.

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

9. Используйте флаги функций
Флаги функций — это программный метод изменения функциональности системы без её повторного развёртывания. Вы можете использовать флаги функций, чтобы включать и выключать части монолита по мере их миграции, экспериментировать с альтернативными конфигурациями или проводить A/B-тестирование. Типичный рабочий процесс для миграции с флагом функции:
1) Определите часть функциональности монолита для переноса на микросервис.
2) Оберните функциональность флагом функции. Повторно разверните монолит.
3) Создайте и разверните микросервис.
4) Протестируйте микросервис.
5) Когда всё будет готово, отключите функцию на монолите, выключив флаг.
6) Повторяйте, пока миграция не будет завершена.
Поскольку флаги функций позволяют развёртывать неактивный код в рабочей среде и включать/выключать его в любое время, мы можем отделить выпуски функций от фактического развёртывания. Это даёт разработчикам огромную степень гибкости и контроля.

Окончание следует…

Источник: https://semaphoreci.com/blog/monolith-microservices