предисловие
Как текущая основная среда микросервисов, Spring Cloud позволяет нам просто и быстро реализовать архитектуру микросервисов. Роли, которые играют различные компоненты Spring Cloud в архитектуре микросервисов, показаны на рисунке ниже. Черная линия представляет описание аннотации, а синяя линия указывает от A к B. Указывает, что B получает услуги от A.
Диаграмма архитектуры микросервиса, состоящая из весеннего облака
Архитектура микросервиса, показанная на рисунке выше, примерно состоит из логической структуры на рисунке выше, которая включает в себя различные микросервисы, обнаружение регистрации, сервисный шлюз, прерыватель цепи, унифицированную конфигурацию, сервис отслеживания и т. д. Давайте поговорим о ролях компонентов в весеннем облаке.
Feign
Feign (вызов интерфейса): микросервисы взаимодействуют друг с другом через интерфейс Rest. Spring Cloud предоставляет инфраструктуру Feign для поддержки вызовов Rest. Feign позволяет изящно выполнять вызовы интерфейса Rest различных процессов. Эта элегантность ведет себя как то же самое. Вызовы процессов одинаковы.
Eureka
Netflix eureka (обнаружение регистрации): в режиме микросервиса большое веб-приложение обычно делится на множество более мелких веб-приложений (сервисов).Маленькие приложения знают друг друга и в это время должны регистрироваться в реестре. Каждое приложение при запуске регистрирует в настроенном центре регистрации свою информацию (ip адрес, номер порта, имя сервиса и т.д. Центр регистрации их сохраняет. Когда сервисы звонят друг другу, их можно найти в центре регистрации через имя службы.Соответствующая служебная информация для связи. Служба регистрации и обнаружения упрощает вызовы между микросервисами и решает проблему жесткого кодирования. Служба может получить услугу другой стороны только через идентификатор службы другой стороны, не зная ее IP и порта.
Ribbon
Лента (балансировка нагрузки). Лента — это балансировщик нагрузки, выпущенный Netflix, который помогает контролировать поведение клиентов HTTP и TCP. После настройки списка адресов поставщиков услуг для ленты лента может автоматически помогать потребителям услуг выполнять запросы на основе определенного алгоритма балансировки нагрузки. Лента по умолчанию предоставляет нам множество алгоритмов балансировки нагрузки, таких как циклический, случайный и т. д. Конечно, мы также можем реализовать собственные алгоритмы балансировки нагрузки для ленты. В SpringCloud, когда Ribbon используется вместе с Eureka, Ribbon может автоматически получать список адресов поставщиков услуг от EurekaServer и запрашивать экземпляр одного из поставщиков услуг на основе алгоритма балансировки нагрузки (для надежности обслуживания микросервис может развернуть несколько экземпляров).
Hystrix
Hystrix (автоматический выключатель): когда поставщик услуг отвечает очень медленно, запрос потребителя к поставщику будет вынужден ждать, пока поставщик не ответит или не истечет время ожидания. В сценариях с высокой нагрузкой, если ничего не предпринимать, такие проблемы могут привести к исчерпанию ресурсов потребителей услуг или даже к краху всей системы (лавинный эффект). Hystrix предназначен для предотвращения возникновения таких проблем. Hystrix — это библиотека задержки и отказоустойчивости с открытым исходным кодом от Netflix, которая используется для изоляции доступа к удаленным системам, службам или сторонним библиотекам для предотвращения каскадных сбоев, тем самым повышая доступность системы и отказоустойчивость. Hystrix в основном обеспечивает задержку и отказоустойчивость за счет следующих моментов.
Запрос пакета:
Используйте HystrixCommand (или HystrixObservableCommand), чтобы обернуть логику вызова зависимостей, и каждая команда выполняется в отдельном потоке. При этом используется «шаблон команды» из шаблонов проектирования.
Механизм отключения:
Когда частота ошибок службы превышает определенный порог, Hystrix может автоматически или вручную отключиться и прекратить запрашивать службу на определенный период времени.
Изоляция ресурсов:
Hystrix поддерживает небольшой пул потоков (или семафор) для каждой зависимости. Если пул потоков заполнен, запросы к зависимости отклоняются немедленно, а не ставятся в очередь, что ускоряет определение сбоя.
монитор:
Hystrix может отслеживать операционные показатели и изменения конфигурации практически в режиме реального времени, такие как успехи, сбои, тайм-ауты и отклоненные запросы.
Резервный механизм:
Выполнение резервной логики при сбое запроса, истечении времени ожидания, отклонении или размыкании прерывателя цепи. Логика резервного копирования может быть указана разработчиком.
Zuul
Zuul (шлюз микросервисов): разные микросервисы обычно имеют разные сетевые адреса, и внешним клиентам может потребоваться вызывать интерфейсы нескольких сервисов для выполнения бизнес-требований. Например, мобильное приложение для покупки билетов в кино может обращаться к интерфейсам нескольких микросервисов для завершения бизнес-процесса покупки одного билета.Если клиент напрямую общается с каждым микросервисом, возникнут следующие проблемы:
Клиент будет запрашивать разные микросервисы несколько раз, что увеличивает сложность клиента.
Существуют междоменные запросы, которые относительно сложно обрабатывать в определенных сценариях.
Аутентификация сложна, и каждая служба требует независимой аутентификации.
Сложность рефакторинга, может потребоваться повторное разбиение микросервисов по мере итерации проекта. Например, можно объединить несколько услуг в одну или разделить одну услугу на несколько. Если клиент напрямую общается с микросервисом, рефакторинг будет сложно реализовать.
Некоторые микросервисы могут использовать протоколы, не совместимые с брандмауэром/браузером, и получить к ним прямой доступ будет сложно.
Вышеперечисленные проблемы можно решить с помощью микросервисного шлюза. Шлюз микросервиса — это промежуточный уровень между клиентом и сервером, и все внешние запросы сначала проходят через шлюз микросервиса. После использования шлюза микросервиса шлюз микросервиса будет инкапсулировать внутреннюю структуру приложения, и клиенту нужно только взаимодействовать со шлюзом, не вызывая напрямую интерфейс конкретного микросервиса. Таким образом, разработка может быть упрощена. Кроме того, использование шлюза микросервисов имеет следующие преимущества:
Легко контролировать. Данные мониторинга можно собирать на шлюзе микросервисов и передавать во внешние системы для анализа.
Легко пройти аутентификацию. Аутентификацию можно выполнить на шлюзе микрослужб перед пересылкой запроса во внутренние микрослужбы без необходимости проверки подлинности в каждой микрослужбе.
Сокращается количество взаимодействий между клиентами и отдельными микросервисами.
Config
Spring Cloud Config (унифицированная служба конфигурации): для традиционных монолитных приложений файлы конфигурации часто используются для управления всеми конфигурациями. Например, отдельное приложение, разработанное SpringBoot, может поместить содержимое конфигурации в файл application.yml. Если вам нужно переключить среду, вы можете установить несколько профилей и указать spring.profiles.active={profile} при запуске приложения. Однако в микросервисной архитектуре управление конфигурацией микросервисов обычно имеет следующие требования:
Централизованное управление конфигурацией. Система приложений, использующая микросервисную архитектуру, может содержать сотни или тысячи микросервисов, поэтому необходимо централизованно управлять конфигурацией.
Разные среды, разные конфигурации. Например, конфигурация источника данных отличается в разных средах (разработка, тестирование, подготовка, производство и т. д.).
Его можно динамически регулировать во время работы. Например, размер пула подключений к источнику данных или порог прерывателя цепи можно динамически регулировать в соответствии с нагрузкой каждой микрослужбы, а сами микрослужбы можно настраивать без остановки конфигурации.
Конфигурация может обновляться автоматически после модификации. Если содержимое конфигурации изменится, микросервис может автоматически обновить конфигурацию. Подводя итог, можно сказать, что для микросервисной архитектуры необходим общий механизм управления конфигурацией, и общепринятой практикой является использование сервера конфигурации для управления конфигурацией. Облачная шина Spring использует Git или SVN для управления конфигурацией и использует шину сообщений, такую как Kafka или RabbitMQ, для уведомления всех приложений, чтобы автоматически обновлять конфигурацию и обновлять конфигурацию всех экземпляров микросервиса.
Zipkin
Sleuth+ZipKin (служба отслеживания): Sleuth и Zipkin можно использовать в сочетании для просмотра задержки запросов микрослужбы и зависимостей каждой микрослужбы через графический интерфейс. Следует отметить, что spring boot2 и более поздние версии не поддерживают настройку Zipkin, вам необходимо загрузить пакет jar, связанный с ZipKin, с официального сайта.
разное
Еще один момент, который следует упомянуть, — это привод Spring Boot, который предоставляет множество конечных точек мониторинга, таких как /actuator/info, /actuator/health, /acutator/refresh и т. д., вы можете просматривать информацию, состояние работоспособности, конфигурацию обновления и т. д. микросервисы.
В конце концов
Приглашаю всех обратить внимание на мой Gong Zonghao [Программист в погоне за ветром], и я собрал более 100 страниц документов в формате pdf с вопросами собеседований по Java от многих компаний в 2019 году. Статьи будут обновляться в нем, а сопоставленные материалы будут также помещаться в него.