Задумался о подготовке статьи по архитектуре своего нового проекта и понял, что сделать это будет не так-то просто. Поймут ли меня, если я напишу что-то типа «система построена в реактивной парадигме»? Наверное, нужно как-то пояснить что это такое, что это за реактивная парадигма?
Но если давать нормальные полноценные пояснения, тогда статья будет не о моих проектных решениях, а о базовых архитектурных понятиях. В общем мне нужен какой-то фундамент, на который я могу опереться в своих пояснениях. И здесь я начну потихоньку закладывать такой фундамент.
Если вы крутой специалист и/или сталкивались с такими библиотеками как Akka (Java) или ее последователями типа Actix (Rust)*, Proto Actor (Go), то вам ничего объяснять не нужно. Скорее всего, вы уже знаете, что такое реактивное программирование и реактивные системы. Если это не так, то я попробую восполнить этот пробел.
*Actix – в отличие от двух других библиотек не является по настоящему распределённым решением, т.е. акторы работают в одном исполняемом программном модуле, например, в одном сервисе. Это локальные акторы: «Actor communication in a local/thread context». Но суть от этого не меняется, это все равно акторы, которые направляют разработчика в сторону реактивного подхода.
Понятие реактивного подхода, конечно, не ограничивается одними лишь акторами, т.е. говорить о том, что система реактивная или не реактивная, исходя из наличия или отсутствие в ней акторов – не корректно. Однако это хороший пример реактивного подхода, модель акторов наиболее близка к философии реактивного программирования. Сами акторы несмотря на то, что это красивое и зрелое решение до сих пор особой популярности не получили. Пока они воспринимаются в качестве экзотики и применяются не так часто.
Я обращаю ваше внимание, что реактивное программирование – это скорее философия, набор каких-то принципов, идейных установок, до нормальной методологии здесь еще очень далеко. На сегодняшний день есть Манифест Реактивных Систем, который определяет основные признаки реактивных системы и принципы, по которым строятся такие системы.
Если совсем кратко, то реактивные системы:
- Отзывчивые
- Устойчивые
- Гибкие
- Основаны на обмене сообщениями
Первые три характеристики, кстати, обычно формулируют в качестве нефункциональных требований к микросервисным системам. Обмен сообщениями также используют в микросервисах, но в отличие от реактивных систем для микросервисов он не является определяющим. В общем провести четкую грань и отделить один архитектурный подход от другого довольно сложно. Все эти идеи так или иначе давно уже используются.
Я по возможности постараюсь прокомментировать отдельные тезисы манифеста, но пока просто отсылаю к первоисточнику. Единственное, на что хочу обратить внимание: реактивные системы ≠ распределенные системы, они конечно могут быть вместе, жить дружно и счастливо, но так происходит далеко не всегда.
Есть также литература на эту тему: Кун Р., Ханафи Б., Аллен Д., «Реактивные шаблоны проектирования». Полезная книга, рекомендую. Там авторы на многочисленных примерах иллюстрируют реактивный подход, а также предлагают некоторые шаблоны проектирования.
Еще выходила книга по Akka: Рестенбург Р., Баккер Р., Уильямс Р., «Akka в действии», но относительно нее я ничего сказать не могу, не читал. Насколько она полезна без привязки к Java стеку я не в курсе.
На этом пока все, конкретные примеры реактивного подхода я покажу на своем коде. До новых встреч на страницах блога!
Валерий Чугреев, 14.05.2021
