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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ускорение программы с помощью параллельных вычислений на нескольких процессорах ограничено размером последовательной части программы. Например, если можно распараллелить 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)

Закон Амдала

Внимание! Этот перевод, возможно, ещё не готов.
Его статус: перевод редактируется

Переведено на Нотабеноиде
http://notabenoid.org/book/42381/163324

Переводчики: 2heoh