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

Событийно-ориентированное ПО

2heoh 26.07.13 в 11:11

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

2heoh 26.07.13 в 11:11

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

2heoh 26.07.13 в 13:49

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

2heoh 26.07.13 в 13:50

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

2heoh 26.07.13 в 14:00

Ключевые блоки

2heoh 26.07.13 в 14:01

В событийно-ориентированном приложении компоненты взаимодействуют друг с другом через создание и принятие событий - отдельные кусочки информации описывающие факты. Эти события отсылаются и принимаются в асинхронном неблокирующем стиле. Событийно-ориентированные системы имеют склонность полагаться на _push чем на pull или poll_, другими словами они push'ат данные потребителям когда возможно вместо того чтобы потреблять ресурсы постоянно обращаясь через потребителей за данными или ожидая их(данных) получения.

2heoh 26.07.13 в 14:57

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

2heoh 26.07.13 в 15:02

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

2heoh 26.07.13 в 15:04

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

2heoh 26.07.13 в 15:18

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

2heoh 26.07.13 в 15:23

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

2heoh 26.07.13 в 15:28

Приложение должно быть реактивным с начала до конца (сверху вниз)

2heoh 26.07.13 в 15:29

Тяжело предсказать где могут возникнуть узкие места в приложении к которому предъявляют требования высокой доступности и большой масштабируемости. Тем не менее важно чтобы готовое решение было асинхронное и неблокируемое. В типичном примере это означает что дизайн приложения должен быть событийно-ориентированным начиная от запроса пользователя из интерфейса (в браузере, REST-клиенте или еще где-то) к разбору запроса и его перенаправлению на web-уровень для его обслуживания компонентами в промежуточном ПО (middleware) через кеширование и далее к запросам в БД. Если один из этих уровней не отвечает, выполняя блокирующий вызов к БД, полагаясь на рапределенное изменяемое состояние, вызывая дорогостоящие синхронные операции, тогда весь канал заглохнет и пользователи будут страдать из-за увеличения времени отклика и снижения масштабируемости.

2heoh 26.07.13 в 15:41

Приложение должно быть реактивным с начала до конца (сверху вниз)

2heoh 26.07.13 в 15:41

Нужда в избавлении слабых звеньев хорошо проиллюстрирована законом Амдала который, согласно wikipedia гласит:

2heoh 26.07.13 в 15:44

Ускорение программы с помощью параллельных вычислений на нескольких процессорах ограничено размером последовательной части программы. Например, если можно распараллелить 95% программы, то теоретически максимальное ускорение составит 20×, невзирая на то, сколько процессоров используется.
(http://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%BA%D0%BE%D0%BD_%D0%90%D0%BC%D0%B4%D0%B0%D0%BB%D0%B0)

2heoh 26.07.13 в 15:45

Закон Амдала

2heoh 26.07.13 в 15:45