Несмотря на то, что Hystrix больше не поддерживается, его все равно стоит изучить!

Java
Несмотря на то, что Hystrix больше не поддерживается, его все равно стоит изучить!

Эта статья написанаyanglbmeНачалось вДокументы технического сообщества GitHub, текущие звезды превысили 30k.
адрес проекта:GitHub.com/ohohgenerate/advpress…

stars

Что такое Хайстрикс?

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

Hystrix позволяет нам контролировать вызовы между сервисами в распределенной системе, добавляя некоторыезадержка вызоваилисбой зависимостиизОтказоустойчивость.

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

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

История Хайстрикс

Hystrix — это фреймворк для обеспечения высокой доступности. Команда API Netflix (которую можно считать зарубежным видеосайтом, таким как Youku или iQiyi) с 2011 года проделала определенную работу по повышению доступности и стабильности системы, и с тех пор Hystrix был разработан.

В 2012 году Hystrix стал более зрелым и стабильным, в Netflix, помимо команды API, многие другие команды начали использовать Hystrix.

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

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

Принципы дизайна Hystrix

  • Выполнять задержки вызовов и сбои вызовов при вызове зависимых службКонтроль и защита от отказов.
  • В сложной распределенной системе предотвратите распространение сбоя зависимой службы по всей системе. Например, если одна служба дает сбой, другие службы также не работают.
  • поставкаfail-fast(Fail fast) и поддержка быстрого восстановления.
  • Обеспечивает поддержку изящного отката.
  • Поддерживает мониторинг в режиме реального времени, аварийную сигнализацию и операции O&M.

Возьмите каштан.

Есть такая распределенная система, сервис А зависит от сервиса Б, а сервис Б зависит от сервиса С/D/Е. В такой зрелой системе, скажем, может быть максимум 100 ресурсов потоков. Обычно 40 потоков одновременно вызывают службу C и по 30 потоков одновременно вызывают D/E.

Для вызова службы C требуется всего 20 мс. Теперь из-за сбоя службы C, например задержки или зависания, поток будет зависать примерно на 2 с. Застряли все потоки 40. Из-за постоянного притока запросов другие потоки также используются для вызова службы C и также зависают. Это приводит к истощению ресурсов потоков службы B, невозможности получать новые запросы и даже может привести к собственному простою из-за непрерывной работы большого количества потоков. Служба А тоже зависает.

Hystrix может выполнять на нем изоляцию ресурсов, например, ограничивая службу B только 40 потоками для вызова службы C. Когда 40 потоков зависают, остальные 60 потоков все еще могут вызываться и нормально работать. Это гарантирует, что вся система не будет перетащена вниз.

Hystrix более подробные принципы проектирования

  • Предотвратите исчерпание всех ресурсов любой зависимой службой, например, всех ресурсов потока в tomcat.
  • Избегайте очередей и невыполненных запросов, используйте текущее регулирование иfail fastдля контроля неисправности.
  • Предоставляет резервный механизм перехода на более раннюю версию для устранения сбоев.
  • Используйте методы изоляции ресурсов, такие какbulkhead(технология изоляции переборок),swimlane(техника плавания по дорожке),circuit breaker(метод отключения цепи), чтобы ограничить влияние любого отказа, зависящего от обслуживания.
  • Повысьте скорость обнаружения неисправностей с помощью функций статистики/мониторинга/предупреждения в режиме, близком к реальному времени.
  • Благодаря свойствам и конфигурации почти в реальном времениГорячая модификацияфункции для повышения скорости обработки ошибок и восстановления.
  • Защищает все сценарии сбоев, основанные на вызовах службы, а не только сценарии сетевых сбоев.

Добро пожаловать в мою общедоступную учетную запись WeChat «Сообщество открытого исходного кода Doocs». ​​Оригинальные технические статьи будут опубликованы как можно скорее.