Пожалуйста, простите меня за использование значка Chain Home, я действительно не рекламирую агентов по недвижимости.
Что такое обнаружение службы?
Обнаружение служб не так непостижимо, его принципы не могут быть проще. Просто слишком много статей на рынке демонизируют сложность открытия сервисов, а читатели, окруженные облаками и туманами, вдруг чувствуют, что их IQ низок и не смеют лезть высоко.
Что такое поставщик услуг Проще говоря, это HTTP-сервер, который предоставляет услуги API и имеет IP-порт в качестве адреса службы. Что такое потребитель услуг? Это простой процесс, который хочет получить доступ к услуге, предоставляемой поставщиком услуг, чтобы что-то сделать. HTTP-сервер может быть поставщиком услуг, который предоставляет услуги внешнему миру, или потребителем, которому требуются услуги, предоставляемые другими поставщиками услуг.Это зависимость от услуг.Без вас я не я. Сложные сервисы даже имеют несколько сервисных зависимостей.
Обнаружение услуг имеет три роли: поставщик услуг, потребитель услуг и посредник услуг. Сервисный посредник — это мост между поставщиками услуг и потребителями услуг. Поставщик услуг регистрирует адрес услуги, предоставленный им самим, у посредника услуг, а потребитель услуг находит адрес услуги, которую он хочет, у посредника услуг, а затем пользуется услугой. Посредник услуг предоставляет несколько услуг, и каждая услуга соответствует нескольким поставщикам услуг.
Посредник службы — это словарь, в словаре много пар ключ/значение, ключ — это имя службы, а значение — список адресов поставщика службы. Регистрация службы заключается в вызове метода словаря Put для заполнения вещей, а поиск службы — в вызове метода словаря Get для получения вещей.
Когда узел поставщика услуг зависает, требуется, чтобы служба могла вовремя отменить регистрацию, чтобы вовремя уведомить потребителя о повторном получении адреса службы.
Когда новый поставщик услуг присоединяется, сервисный посредник должен вовремя сообщить потребителю услуги, хотите ли вы попробовать новую услугу.
Redis как сервисный посредник
В Redis есть богатые структуры данных, которые идеально подходят для хранения служебных словарей. Для каждого имени службы мы сохраняем строку IP:Port службы в заданной структуре. Если поставщик услуг присоединяется, вызовите команду sadd, чтобы добавить адрес службы.Если служба зависает, вызовите команду srem, чтобы удалить адрес службы. Для потребителей службы используйте команду smembers, чтобы получить все адреса службы, а затем случайным образом выберите один из них в процессе потребителя, или используйте команду srandmemember, чтобы напрямую получить случайный адрес службы.
На данный момент вы можете скептически относиться к тому, действительно ли обнаружение сервисов так просто? Ответа почти нет, есть несколько вопросов об этом решении выше.
Первый вопрос: что делать, если процесс поставщика услуг насильственно убит командой kill -9 и не может активно вызывать команду srem?
В это время черный адрес в списке услуг указывает на несуществующую услугу и потребитель ее вообще не знает, в это время сервисный посредник становится черным посредником. Так что делать?
Мы внедряем механизмы поддержки и проверки сервисов, а также заменяем структуры данных. Поставщик услуг должен каждые 5 секунд сообщать сервисному посреднику о выживании, а сервисный посредник записывает адрес сервиса и время отчета в значение и оценку структуры данных zset. Сервисный посредник должен проверять структуру данных zset каждые 10 секунд или около того и выбрасывать элементы адресов сервисов, время отчетов которых серьезно отстает. Таким образом, действительность адресов услуг в списке услуг может быть гарантирована в квазиреальном времени.
Вторая проблема заключается в том, как уведомить потребителей об изменении списка услуг. Есть два решения.
Первый — это опрос, когда потребителю необходимо каждые несколько секунд проверять, не изменился ли список услуг. Если есть много сервисов, большой список сервисов и много потребителей, Redis будет иметь определенное давление. Таким образом, в настоящее время может быть введен механизм номера версии списка служб, и каждая служба снабжена ключом/значением для установки номера версии службы, то есть при изменении списка служб номер версии увеличивается. . Потребителям нужно только опросить изменения этого номера версии, чтобы узнать, изменился ли список служб. Поскольку список сервисов относительно стабилен и часто меняется только тогда, когда сеть сильно дрожит, Redis почти не оказывает давления.
Второй — использовать pubsub. Своевременность этого метода значительно лучше, чем опрос. Недостатком является то, что каждый pubsub будет занимать один поток потребителя и одно дополнительное соединение redis. Чтобы сократить потери потоков и подключений, мы используем единый pubsub для трансляции изменений глобального номера версии. Так называемый глобальный номер версии означает, что при изменении любого списка служб номер версии будет увеличиваться. Потребители, получившие изменение версии, проверяют, не изменился ли номер версии их списка зависимых служб. Этот глобальный номер версии также можно использовать в первой схеме опроса.
Третья проблема заключается в том, что redis — это одна точка, а если он зависнет?
Это большая проблема. Именно из-за этой проблемы популярные системы обнаружения служб используют распределенные базы данных, такие как zookeeper/etcd/consul, в качестве сервисных посредников.Они распределенные и многоузловые.Не имеет значения, если нода зависнет, система все равно может нормально работать Работа.
Действительно ли Redis ненадежен в качестве сервисного посредника? На самом деле, существует также Redis-Sentinel, который может устранить проблему единственной точки Redis.Redis-Sentinel может автоматически обновлять подчиненный узел до главного узла, когда главный узел зависает. Так что это также возможно сделать с помощью Redis. Обнаружение сухого сервиса с помощью Redis очень просто, хотя и очень непопулярным.
Поставщики услуг — это не только HTTP-сервисы.
Упомянутый выше поставщик услуг — это просто HTTP-сервер, на самом деле существует множество видов услуг. Это может быть служба базы данных, это может быть служба RPC, это может быть служба UDP и так далее.
Если это база данных MySQL, как зарегистрировать службу MySQL у посредника службы? Родной MySQL не предоставляет такой функции. Общей практикой является предоставление агента для регистрации. В дополнение к регистрации адреса службы у посредника службы этот агент также должен отслеживать работоспособность MySQL, чтобы он мог переключаться на новый адрес службы MySQL вовремя, когда MySQL выходит из строя. Как правило, этот агент не только отслеживает одну базу данных для экономии ресурсов, он может отслеживать несколько баз данных или даже несколько баз данных одновременно.
Перезагрузка конфигурации службы
Обнаружение служб обычно представляет собой относительно простую функцию для регистрации и поиска списков служб. Однако современные системы обнаружения служб также интегрируют возможности управления конфигурацией служб. Это позволяет перезагружать конфигурацию службы в реальном времени. Принцип также очень прост, то есть для каждого элемента услуги посредник службы также будет хранить отдельный ключ/значение для хранения информации о конфигурации службы. Когда этот элемент конфигурации изменяется в фоновом режиме, посредник службы уведомляет соответствующий сервер об изменении информации о конфигурации в режиме реального времени. Например, изменение адреса базы данных, изменение бизнес-параметров и т. д.
Фон управления услугами
Чтобы облегчить управление службами, общее обнаружение служб также предоставляет менеджерам фон управления службами для просмотра состояния кластеров служб. Если во время регистрации службы и составления отчетов предоставляется избыточная информация о конфигурации, в фоновом режиме управления службами может быть представлена более подробная информация о службе. Фон управления службами также может организовать все зависимости служб, чтобы представить красивое дерево зависимостей служб.
Простая реализация обнаружения сервисов
Xiaobian внедряет простую систему обнаружения сервисов на основе Redis в свободное время.Captain. Читатели могут перейти на github, чтобы загрузить этот проект для обучения. Помимо написания сервера для обнаружения служб, я также разработал клиентский sdk, который может быть нестабильным, надеюсь, читатели поймут и не будут использовать его для систем онлайн-бизнеса.
существуетCaptainВ этом проекте мой сервер обнаружения служб инкапсулирует службы, предоставляемые Redis, и предоставляет HTTP API для регистрации и поиска служб без использования упомянутой выше функции pubsub.
Читайте статьи по теме, обратите внимание на общедоступный номер [кодовая дыра]