Когда ваши микросервисы начинают «прятаться»: решите проблемы обнаружения сервисов

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

Примерно так это выглядит в архитектуре микросервисов, когда сервис обнаруживает проблему.

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

Почему это головная боль?

Я сам с этим столкнулся. Когда система была впервые построена, использовался только простой список конфигурации. Первые два месяца прошли без происшествий. Позже, по мере увеличения объёмов бизнеса, мы начали динамично расширять отдельные услуги. Внезапно вероятность того, что пользователи не смогут разместить заказ, незаметно возросла. Журналы полны ошибок «отказано в соединении» — дело не в том, что служба не работает, а в том, что вызывающий абонент все еще пытается подключиться к старому адресу. Эта служба, очевидно, была перенесена на новый сервер, но другие части об этом не знают.

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

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

Более «живая» система каталогов.

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

Это то, что делает механизм обнаружения служб. Обычно он состоит из двух частей: надежного реестра служб (например, динамического списка) и механизма обнаружения (который позволяет службам запрашивать этот список).

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

Таким образом, даже если платежная служба переместится с одного сервера на другой, при условии, что она снова зарегистрируется в новом месте, другие службы получат новый адрес в следующий раз, когда они запросят. Вся система «живет».

Строим этот мост в мире Java

Существует несколько распространенных инструментов для реализации этого набора логики в Java. Например, Netflix Eureka спроектирован так, чтобы быть легким, и сервис можно легко зарегистрировать и обнаружить. Что касается Consul, помимо обнаружения сервисов, он также включает в себя проверку работоспособности и хранилище значений ключей, которое имеет больше функций. ZooKeeper появился раньше и работает стабильно, но его настройка требует некоторых усилий.

Что вы учитываете при выборе? Знакомство с командой важно. Существует также поддержка сообщества: когда вы сталкиваетесь с ловушкой, много ли информации вы можете найти? Соответствует ли это вашему стеку технологий? Например, семейство Spring Cloud очень удобно интегрирует Eureka. Если вы используете Spring Boot, этот путь может быть более плавным.

Но независимо от того, какой из них вы выберете, некоторые основные модели одинаковы. Ваш сервис должен интегрироваться с клиентской библиотекой, чтобы периодически отправлять сигналы подтверждения: «Я все еще жив». Вызывающему объекту необходимо решить, как сделать выбор: следует ли ему выбрать экземпляр случайным образом или повернуть его? Или выбрать самый быстрый по скорости отклика? Эта часть логики часто скрыта в вашем коде.

Избегайте распространенных ошибок

Когда вы только начинаете, легко попасть в несколько ловушек. Например, ситуация с обслуживанием в автономном режиме не была решена должным образом. Служба крашится, но реестр не выкинул ее из списка. Другие службы могут по-прежнему отправлять ему запросы, пока не истечет время ожидания. Для этого необходимо установить разумные интервалы проверки работоспособности и тайм-ауты на клиенте или в центре регистрации.

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

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

От полезного к полезному: будьте умнее

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

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

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

Итак, вернемся к исходному вопросу

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

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

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

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

Основанная в 2005 году,мощностьбыла посвящена профессиональному производителю компактных приводов со штаб-квартирой в Дунгуане, провинция Гуандун, Китай. Используя инновации в технологии модульных приводов,мощностьобъединяет высокопроизводительные двигатели, прецизионные редукторы и многопротокольные системы управления, обеспечивая эффективные и индивидуальные решения для интеллектуальных систем привода.мощностьпредоставила профессиональные решения в области приводных систем более чем 500 корпоративным клиентам по всему миру, предлагая продукты, охватывающие различные области, такие как системы «умный дом», автоматическая электроника, робототехника, точное земледелие, дроны и промышленная автоматизация.