Обмен технологиями

SpringCloud

2024-07-12

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

1. Что такое микросервисы?

1. Основные понятия

Микросервисы — этоархитектурный стиль(В отличие от монолитной архитектуры, вертикальной архитектуры, распределенной архитектуры и архитектуры SOA) приложения делятся на более мелкие сервисы, управляемые процессами.

2. Характеристики микросервисов

  1. Легкость: сложные системы или службы разделены по вертикали, и каждый микросервис ориентирован на решение особых задач.
  2. Низкая связанность: каждая разделенная служба независима друг от друга с точки зрения кода, ресурсов и среды и может разрабатываться, тестироваться, развертываться и обслуживаться независимо, что положительно влияет на стабильность системы (влияние снижается при возникновении проблем). происходят) и экспансия (расширение ресурсов) оценка ресурсов более удобна и менее рискованна).
  3. Кроссплатформенность: разные микросервисы могут использовать разные языки разработки и работать в разных средах.

2. Что такое SpringCloud?

1. Основные понятия:

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

2. Часто используемые компоненты:

1)Весеннее облако Netflix:

Эврика: центр регистрации

Лента: балансировка нагрузки

Притвориться: удаленный вызов

Hystrix: сервисный автоматический выключатель

Зуул/Врата: Врата

2)Spring Cloud Config: инструмент централизованного управления конфигурацией, внешнее хранилище конфигурации приложения, может использоваться для приложений Spring или сторонних приложений.

3)Spring Cloud Bus: шина событий и сообщений, используемая для распространения изменений состояния или событий изменения конфигурации в кластере.

4)Spring Cloud Consul: инструмент обнаружения и настройки сервисов, легко интегрированный с контейнерами Docker.

5)Spring Cloud Security: набор инструментов безопасности, обеспечивающий поддержку безопасности и аутентификации приложений.

6)Spring Cloud Sleuth: распределенная трассировка цепочки вызовов, совместимая с трассировкой Zipkin, HTrace и ELK.

7)Кластер Spring Cloud: выборы лидеров, реализованные посредством абстракции Zookeeper, Redis и Consul.

8)Spring Cloud Data Flow: оркестровка микросервисов, простая в использовании через интерфейс перетаскивания или REST API.

9)Spring Cloud Stream: легкая управляемая событиями платформа микросервисов для быстрого создания приложений, подключающихся к внешним системам.

10)Spring Cloud Task: краткосрочная платформа микросервисов для быстрого создания приложений, выполняющих задачи пакетной обработки данных.

3. Шаги по использованию компонентов SpringCloud

Учебное пособие по Springcloud — 3. Микросервисный механизм автоматического выключателя, подробное объяснение использования автоматического выключателя hystrix_Как настроить Java-выключатель — блог CSDN

Учебное пособие по Springcloud — 4. Подробное объяснение использования шлюза zuul_zuul — блог CSDN.

1. Hystrix (предохранитель, понижение мощности, ограничение тока)

1) Что он делает?

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

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

2) Это происходит на стороне клиента или на стороне сервера?

Сервисный выключатель:в целом Это происходит на стороне сервера (цель состоит в том, чтобы позволить вызывающей стороне быстро выйти из строя, когда время ожидания службы истекает или происходит аномальная ситуация, это приводит к срабатыванию предохранителя, аналогичному предохранителю в реальной жизни). (Иногда на клиенте также можно настроить быстрый сбой при обнаружении исключения при вызове определенной службы);
Деградация службы: обычно происходит на стороне клиента. Учитывая общую нагрузку на веб-сайт, когда служба отключается или завершает работу, она больше не вызывается (иногда это также можно настроить на стороне сервера, когда система отключена); внезапный трафик, это приведет к понижению версии основных функций для защиты основных функций);

Ограничение тока: обычно происходит на стороне сервера;

3) Как использовать

  • Крах:

@EnableCircuitBreaker: включено в приложениипредохранитель

@HistrixCommand(fallbackMethod="xxxFallback",commandProperties = {
}): аннотация о слиянии добавляется к аннотации о понижении версии. Заполните условия слияния в команде CommandProperties = {}. Щелкните, чтобы просмотреть конкретные условия слияния.HystrixPropertiesManagerПроверять.

  1. @HystrixCommand(fallbackMethod = "xxxFallback",commandProperties = {
  2. //20秒内出现3个请求,失败率为30%,就会触发熔断,30秒内不再发送调用
  3. // 条件一: 请求数量达到3个
  4. @HystrixProperty(name = HystrixPropertiesManager.CIRCUIT_BREAKER_REQUEST_VOLUME_THRESHOLD, value = "3"),
  5. // 条件二: 每20秒一个判断单位
  6. @HystrixProperty(name = HystrixPropertiesManager.EXECUTION_ISOLATION_THREAD_INTERRUPT_ON_TIMEOUT,value = "20000"),
  7. // 条件三: 失败率30%
  8. @HystrixProperty(name = HystrixPropertiesManager.CIRCUIT_BREAKER_ERROR_THRESHOLD_PERCENTAGE, value = "30"),
  9. // 结果: 熔断后, 30秒内不再请求远程服务
  10. @HystrixProperty(name = HystrixPropertiesManager.CIRCUIT_BREAKER_SLEEP_WINDOW_IN_MILLISECONDS, value = "30000")
  11. })
  • Понижение версии:

Создайте новый класс xxxFallbackFactory для реализации FallbackFactory и переопределите метод create. Метод понижения версии определен в create.

@FeignCliend(fallbackFactory=xxxFallbackFactory.class): Histrix интегрирован в Feign

Или укажите резервный метод непосредственно в методе: @HistrixCommand(fallbackMethod="xxxFallback")

  • Ограничение:

        1、Текущая стратегия ограничения:

1), ограничение тока семафора

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

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

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

  1. @HystrixCommand(
  2. commandProperties= {
  3. @HystrixProperty(name="execution.isolation.strategy", value="SEMAPHORE"),
  4. @HystrixProperty(name="execution.isolation.semaphore.maxConcurrentRequests", value="20")
  5. },
  6. fallbackMethod = "errMethod"
  7. )

2), ограничение тока пула потоков

  1. @HystrixCommand(
  2. commandProperties = {
  3. @HystrixProperty(name = "execution.isolation.strategy", value = "THREAD")
  4. },
  5. threadPoolKey = "createOrderThreadPool",
  6. threadPoolProperties = {
  7. @HystrixProperty(name = "coreSize", value = "20"),
  8. @HystrixProperty(name = "maxQueueSize", value = "100"),
  9. @HystrixProperty(name = "maximumSize", value = "30"),
  10. @HystrixProperty(name = "queueSizeRejectionThreshold", value = "120")
  11. },
  12. fallbackMethod = "errMethod"
  13. )

Здесь обратите внимание: вjavaВ пуле потоков, если количество потоков превышаетcoreSizeзапросы на создание потоков будут поступать в очередь первыми. Если очередь заполнена, потоки будут продолжать создаваться до тех пор, пока количество потоков не достигнет максимального значения.maximumSize , а затем примите стратегию отклонения.Но в пуле потоков, настроенном hystrix, есть дополнительный параметр.queueSizeRejectionThreshold,еслиqueueSizeRejectionThreshold < maxQueueSize, количество очередей достигаетqueueSizeRejectionThresholdпримет стратегию отказа, поэтомуmaximumSize неуспешный.еслиqueueSizeRejectionThreshold > maxQueueSize, количество очередей достигаетmaxQueueSizeчас,maximumSizeдействителен, система продолжит создавать потоки, пока их число не достигнетmaximumSize

      2. Разница между ограничением тока семафора и ограничением тока пула потоков:

1) Уровень производительности: семафор использует исходный поток и имеет низкое потребление производительности;

2) Уровень стабильности системы: пулы потоков изолированы, и проблемы сами по себе не влияют на другие пулы потоков;

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

        3. Текущие сценарии использования лимитирующей стратегии:

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

4) В чем разница между этими тремя?

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

  • разные концепции

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

  • Различные механизмы запуска

По умолчанию, если Hystrix обнаруживает, что частота отказов запросов превышает 50% в течение 10 секунд, он запускает механизм автоматического выключателя. После этого запрос к микросервису повторяется каждые 5 секунд. Если микросервис не может ответить, механизм автоматического выключателя продолжает работать. Если микросервис доступен, механизм автоматического выключателя отключается и восстанавливаются обычные запросы.

По умолчанию hystrix запускает механизм перехода на более раннюю версию при следующих 4 условиях:

  1. Метод выдает исключение HystrixBadRequestException
  2. Тайм-аут вызова метода
  3. Включите автоматический выключатель, чтобы перехватить звонок
  4. Пул потоков, очередь или семафор заполнены.
  • Различные отношения собственности

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

2. Шаблон «Притворись и отдохни»

Краткое содержание ссылки:

  1. Добавить начальную зависимость;
  2. Добавьте аннотацию: @EnableFeignClients;
  3. Создайте интерфейс Feign:

@FeignClient(name="eureka-HA",fallbackFactory=DeptClientServiceFallbackFactory.class)

Учебное пособие по Springcloud — 1. Быстро создайте демо-версию начального уровня, просто прочитайте эту статью_Ye Juyan-GitCode сообщество открытого исходного кодаБез лишних слов, следуйте за мной и начните свой первый опыт работы с Spring Cloud. Сначала просмотрите основные компоненты микросервисов: [Изображение здесь] Производитель: предоставление услуги Потребитель: потребление услуги Центр регистрации/обнаружения службы: регистрация службы, обнаружение, мониторинг Итак, сначала. понимать архитектурную основу микросервисов Springcloud: производитель (клиент), потребитель (клиент), центр регистрации/обнаружения услуг (сервер) Е Цзюян Сообщество открытого исходного кода GitCodeзначок-по умолчанию.png?t=N7T8https://gitcode.csdn.net/65e840841a836825ed78b9d0.html?dp_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpZCI6MzI1MTQ3NiwiZXhwIjoxNzIxMTM0MjcwLCJpYXQiOjE3MjA1Mjk0NzAsInVzZXJuYW1lIjoicXFfMTk5NTIwMjkifQ.7co5oRDfDrxtdqIsV-9AjJacdbURh-cikj5Rtxt7Z1c

3. Использование Зуула

Ссылаться на:

Практическая реализация архитектуры проекта SpringBoot «Строительство шлюза zuul» — блог CSDN

4. Использование регистрационного центра Эврика

Ссылаться на:

Архитектура проекта SpringBoot в реальном бою «создание родительского проекта и строительство центра регистрации»_java Construction Стартап родительского проекта Springboot — блог CSDN

4. Как работает SpringCloud

1. Принцип работы Эврики:

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

  2. Обнаружение службы: когда потребителю службы необходимо вызвать другие службы, он отправляет запрос на обнаружение службы на сервер Eureka, чтобы получить список экземпляров необходимых служб. После получения запроса сервер Eureka вернет список экземпляров соответствующего сервиса, включая IP-адрес, номер порта и другую информацию сервиса. Потребитель службы выбирает один из экземпляров службы для вызова (балансировка нагрузки) на основе возвращенного списка экземпляров.

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

5. Базовый исходный код SpringCloud

1. Исходный код шлюза Zuul

Практическая реализация архитектуры проекта SpringBoot «Строительство шлюза zuul» — блог CSDN Статью просмотрели и прочитали 227 раз. Глава 3. Конструкция шлюза Zuul Предисловие: 1. Основные функции Zuul в основном обеспечивает динамическую маршрутизацию (встроенная ленточная реализация) и фильтрацию (может использоваться в качестве фильтра унифицированной аутентификации, фильтра публикации в оттенках серого, фильтра IP-адресов черного и белого списка, фильтра ограничения тока службы). (Может быть реализовано с помощью функции Sentinel)) 2. Отличие от Spring Cloud GateWay заключается в том, что это шлюзовое решение, предоставляемое двумя разными организациями с открытым исходным кодом. Spring Cloud GateWay использует неблокирующий API, встроенный фильтр ограничения тока, поддерживает длинные соединения (например, веб-сокеты) и лучше, чем Zuul, в сценариях с высоким уровнем параллелизма и медленным ответом серверной службы...https://blog.csdn.net/qq_19952029/article/details/124285479

2. Исходный код регистрационного центра Эврика

3. Исходный код автоматического выключателя Histrix

4. Исходный код конфигурации центра конфигурации.

5. Исходный код ленты балансировки нагрузки

6. Микросервис вызывает имитацию исходного кода

6. Как SpringCloud реализует распределенные транзакции

Практика режима Seata TCC (Часть 2) — Сообщество разработчиков облаков AlibabaРеальный бой в режиме Seata TCC (Часть 2)значок-по умолчанию.png?t=N7T8https://developer.aliyun.com/article/1053737?spm=5176.26934562.main.1.799c6a03T45SJ9Приведенное выше сообщение в блоге не решает проблему приостановки, о чем можно судить по различным индикаторам состояния.

https://www.cnblogs.com/lilpig/p/16613226.htmlзначок-по умолчанию.png?t=N7T8https://www.cnblogs.com/lilpig/p/16613226.html

1. Роль режима TCC

TM: менеджер транзакций, созданный с помощью аннотации @GlobalTransaction.

ТК: Координатор

РМ:Участник

Весь процесс:

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

2. Значение резервирования, отправки и отката ресурсов TCC.

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

3. Преимущества и недостатки TCC

Преимущества режима TCC

  1. Прямая подача в один этап, без блокировок БД, без других блокировок, хорошая производительность
  2. Логика резервирования и восстановления пишется самостоятельно и не зависит от базы данных. Может использоваться в нетранзакционных базах данных.

Недостатки режима TCC

  1. Кодирование — это сложно
  2. Слабо согласованный
  3. потому чтоConfirmиCancelОн также может выйти из строя, и вам нужно разобраться с этим процессом.
  4. Некоторым предприятиям модель TCC не подходит. Например, размещение заказа — это процесс добавления новой строки. Использовать TCC невозможно или необходимо.

4. Режим ХА

Высокая согласованность за счет координации фиксации и отката локальных транзакций каждого участника.

Преимущества режима XA

  1. Легко реализовать, поскольку большинство баз данных уже поддерживают транзакции XA, Seata достаточно выполнить простую упаковку.
  2. сильная консистенция

Недостатки режима XA

  1. Каждой транзакции приходится ждать завершения всей обработки транзакций, занимая блокировки базы данных, что приводит к снижению производительности и низкой доступности.
  2. Его нельзя использовать, если база данных не поддерживает транзакции XA.

5. Режим АТ

слабая консистенция