«Это 8-й день моего участия в ноябрьском испытании обновлений, ознакомьтесь с подробностями события:Вызов последнего обновления 2021 г."

Привет, я смотрю на гору.

существуетРабота с инфраструктурой для микросервисовКак упоминалось выше, в эпоху облачных сервисов и микросервисов практически невозможно вручную изменить адрес службы, необходим механизм для завершения автоматической отчетности и компоненты поддержки для получения адреса службы, которые могут обеспечить быстрый онлайн и offline of services.line, это компонент регистрации/обнаружения службы.

Для облегчения презентации от размера определенных системных фаз:

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

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

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

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

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

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

В микросервисах есть еще одна роль, которая определяется в соответствии с отношением вызова:

Клиентская служба (клиент для краткости): Экземпляры, которые вызывают другие службы.
Серверная служба (называемая серверной): экземпляр, вызываемый другими экземплярами службы.

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

Реестр услуг

Когда дело доходит до обнаружения сервисов, необходимо упомянуть один важный компонент:Реестр услуг, который является ядром обнаружения служб. Это база данных, которая содержит сетевое расположение и состояние мониторинга всех экземпляров служб. Компонент регистрации служб записывает информацию в реестр служб, а компонент обнаружения служб получает информацию о сетевом расположении действительных экземпляры службы. В настоящее время часто используемые реестры сервисов: Eureka, etcd, Consul, Zookeeper, Kibernetes и другие сервисы зеркального планирования не имеют четкого компонента реестра сервисов, а реализуются через встроенную функцию регистрации сервисов. Для прокси-серверов, таких как F5 и Nginx, исходная конфигурация также относится к реестру службы.

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

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

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

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

Как правило, существует два режима обнаружения служб: режим обнаружения на стороне клиента и режим обнаружения на стороне сервера.

Режим обнаружения клиента

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

Архитектура этого режима показана на рисунке:

Конкретный процесс:

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

В Spring Cloud (или компонентах с открытым исходным кодом Netflix) компонент Eureka Server эквивалентен реестру служб, компонент Eureka Client реализует реестр служб, а лента реализует алгоритм балансировки нагрузки и стратегию повторных попыток.

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

Режим обнаружения сервера

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

Архитектура этого режима показана на рисунке:

Конкретный процесс:

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

Существует два способа реализации компонента обнаружения службы в режиме обнаружения сервера:

Первый тип, централизованный прокси, компонент обнаружения службы представляет собой отдельный экземпляр службы, этот экземпляр представляет собой системный компонент высокой доступности и высокой пропускной способности, а экземпляр серверной службы прокси представлен F5 и Nginx.
Второй — агент хост-процесса. Компонент обнаружения служб предоставляется системной средой и интегрируется на хост или в операционную систему.Представителем является Istio ServiceMesh.

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

регистрация службы

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

режим саморегистрации

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

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

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

Сторонняя модель регистрации

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

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

Продолжение следует

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

Существуют клиентские службы Discovery Discovery Discovery Discovery Rode и режим сервера, режим регистрации регистрации самообслуживания и режим регистрации стороннего регистрации. Услуги обнаружения и регистрации услуг через реестр услуг связаны вместе.

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

Возможное решение для регистрации и обнаружения сервисов в микросервисах