Управление микросервисами | Редис

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

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

Стратегии развертывания микросервисов

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

Контейнеры

Контейнеры — это предварительно упакованные пакеты программного обеспечения, состоящие из всех компонентов, необходимых для запуска программного обеспечения, что может означать что угодно: от автономного приложения до базы данных в среде системы оркестрации. Поддержка контейнеров инфраструктура как код и популярны среди команд DevOps. Функции операционной эффективности контейнеров помогают автоматизировать частые команды, расширяя базы данных, включая Конфигурация «активный-активный»и создание протоколов автоматического переключения при отказе для кластеров или узлов, которые переходят в автономный режим. Если каждый микросервис работает в своем собственном контейнере, команды могут запускать свои собственные выпуски и устранять зависимости рабочих процессов от других команд.

> Посмотрите, как команды используют операторы, чтобы получить максимальную отдачу от Kubernetes.

А/Б тестирование

A/B-тестирование — это средство тестирования нескольких версий приложения или службы микросервисов путем контролируемого добавления в каждую версию различных переменных — функций, различий в пользовательском интерфейсе, конфигурации сервера и т. д. — чтобы определить, какие элементы обеспечивают наибольший успех в производительности. термины – как бы ни выглядел успех в соответствующей области. Чтобы оценить несколько подходов, веб-трафик разделяется между тестом A и тестом B, чтобы отслеживать, как пользователи реагируют и взаимодействуют с новыми реализациями или удаленными функциями каждого изолированного тестируемого продукта, используя журналы, трассировки и мониторинг.

> Узнать Как создать инструмент A/B-тестирования в реальном времени с помощью Redis.

Сине-зеленое развертывание

Сине-зеленое развертывание — это полезная стратегия для миграции данных, их тестирования, реагирования на изменения с ограниченным воздействием и сокращения времени простоя. Как поясняется в Прием данных: 6 способов ускорить работу вашего приложения, сине-зеленое развертывание — это способ выполнить миграцию данных. Согласно этой предпосылке, вы принимаете данные параллельно. Приложение продолжает использовать «синюю» устаревшую базу данных, в то время как новая «зеленая» облачная база данных развертывается параллельно для тестирования в реальном времени и отключения этого нового конвейера данных с гарантией отката.

> У команд DevOps есть множество способов перенести данные. Корпоративные облачные сервисы Redis готовы помочь вам унифицировать гибридные и мультиоблачные уровни данных.

Канарские релизы

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

Непрерывная интеграция и непрерывное развертывание (CI/CD)

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

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

Непрерывное развертывание (CD) обычно обеспечивает новое развертывание в производственной среде после прохождения автоматизированных тестов.

> Узнайте, как Redis Developer Hub расширяется для поддержки потребностей команд DevOps сделав базы данных частью конвейера CI/CD.

Управление конфигурацией микросервисов

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

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

При настройке архитектуры микросервисов перед DevOps стоит задача применить рекомендации, которые заставляют микросервис функционировать определенным образом в общей инфраструктуре приложения. Эти настройки могут включать сведения о подключении к базе данных, конечные точки API, уровни ведения журнала, конфигурации среды выполнения и переключатели функций, также известные как «флаги функций».

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

Централизованное управление конфигурацией

Централизованное хранилище конфигурации — это сервер или репозиторий, с которого можно управлять конфигурациями всех микросервисов независимо от их среды. Функции конфигурации от одного микросервиса к другому могут сильно различаться, и манипулирование таким разрозненным набором параметров и секретов без единой глобально доступной записи «может очень быстро усложнить задачу». Помимо того, что он является выделенным центром настройки, он упрощает и ускоряет процесс бесперебойной работы новых выпусков.

Динамические обновления конфигурации

Управление динамической конфигурацией (DCM) учитывает изменения конфигурации в приложении без инициирования повторного развертывания. Прикосновение к коду приложения автоматически вызывает необходимость запуска полного набора регрессионных тестов со всеми функциональными и интеграционными тестами.

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

Безопасность и управление секретами

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

В Kubernetes секреты «по умолчанию хранятся в незашифрованном виде в базовом хранилище данных сервера API (etcd). Любой, у кого есть доступ к API, может получить или изменить секрет, как и любой, у кого есть доступ к etcd. Кроме того, любой, кто имеет право создавать Pod в пространстве имен, может использовать этот доступ для чтения любого секрета в этом пространстве имен; это включает в себя косвенный доступ, например, возможность создания развертывания».

Для обеспечения безопасной аутентификации пользователей группы разработчиков могут использовать внешний оператор секретов, например HashiCorp Vault, для обеспечения безопасной аутентификации пользователей. Операторы секретной информации разрешают любой доступ, прежде чем передавать конфиденциальную информацию.

Управление версиями и изменениями

Управление версиями способ для команд DevOps отслеживать исторические изменения конфигурации, внесенные в атрибуты микросервиса.включая «пары ключ-значение, спецификации программного обеспечения (SBOM), распространенные уязвимости и уязвимости (CVE), лицензии, детали развертывания, потребляющие приложения и метаданные развертывания».

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

Service Mesh, обнаружение сервисов и балансировка нагрузки

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

Сервисная сетка

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

Сервисная сетка состоит из плоскости данных и плоскости управления. Разница между обоими самолетами в том, что «плоскость управления решает, как данные управляются, маршрутизируются и обрабатываются., в то время как плоскость данных отвечает за фактическое перемещение данных». Ethernet, Wi-Fi, сотовые и спутниковые сети являются примерами плоскостей передачи данных. Плоскость управления, которая отслеживает несколько сервисов, также известна как «обнаружение сервисов».

Обнаружение службы

Обнаружение служб облегчает взаимодействие между службами, выделяя доступные экземпляры, готовые к обмену данными без изменения конфигурации. Реестр служб, в котором хранятся IP-адреса, порты и состояние работоспособности доступных служб, становится централизованным узлом для определения того, какие службы готовы к обмену данными.

Балансировка нагрузки

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

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

Автомасштабирование микросервисов

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

Обработка сбоев микросервисов

Иногда случаются сбои в системе, и жизненно важно быть готовым к возможному выходу из строя узла или кластера.

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

Дополнительную информацию о возможной согласованности см. Объяснение согласованности базы данных.

Хотите найти дополнительную информацию о микросервисах? Откройте для себя наш специальный плейлист микросервисов на нашем Youtube-канале.