День 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