The Reactive Manifesto / Реактивный Манифест: Resilient

Почему это важно

2heoh 26.07.13 в 15:56

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

2heoh 29.07.13 в 13:01

Мериэм-Вебстер определяет устойчивость как:

2heoh 29.07.13 в 13:01

способность вещества или объекта восстанавливать свою форму

2heoh 29.07.13 в 13:02

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

2heoh 29.07.13 в 13:03

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

2heoh 29.07.13 в 13:12

Основные блоки

2heoh 26.07.13 в 15:57

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

2heoh 29.07.13 в 13:19

Переборки

2heoh 26.07.13 в 15:57

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

2heoh 29.07.13 в 13:23

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

2heoh 29.07.13 в 13:29

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

2heoh 29.07.13 в 13:31