В последние годы модель акторов переживает очередную волну интереса со стороны разработчиков. С одной стороны -- это хорошо, т.к. при разумном применении в подходящих для этого нишах, модель акторов позволяет сократить сложность и стоимость разработки. С другой стороны, любой хайп, любая мода на что-нибудь, ведет к образованию большого количества "пены", которая скрывает суть вещей. Применительно к разработке софта это означает появление некоторого числа "евангелистов", проталкивающих модель акторов в массы, но при этом имеющих смутное представление о том, что же это такое.
Еще более усугубляет дело наличие материально заинтересованных "евангелистов", которым кровно необходимо продать свой продукт и/или услуги, построеные вокруг модели акторов. В частности, таковыми являются товарищи из небезызвестной в узких кругах конторы Lightbend. Эти товарищи стоят, в частности, за разработкой фреймворка Akka. Они же приложили руку и к небезызвестному в тех же кругах Reactive Manifesto. И все бы ничего, но продавцы услуг из Lightbend-а очень плотно увязывают Actor Model и Reactive Manifesto в своих маркетинговых материалах.
В частности, недавно они выпустили white-paper под названием "Modernization: The End Of The Heavyweight Era. Why Actor Model Matters for Could Infrastructure". В котором повествование идет приблизительно в таком ключе: разработка больших монолитных приложений на Java EE -- это отстой, прошлый век и в приличных домах Ландона и Парижу вспоминать о таком уже не комильфо. Сейчас, как-никак, XXI-ый век на дворе, поэтому есть Reactive Manifesto, а значит ваши волосы будут мягкими и пушистыми приложения должны быть отзывчивыми, эластичными и устойчивыми. Для чего вам всего лишь нужно использовать не просто модель акторов вообще, а конкретно Akka от Lightbend-а.
Причем описано все это вполне серьезно, красиво и убедительно. Можно только поучиться тому, как следует писать маркетиновые материалы, наполняя их технической шелухой для придания солидности. Однако, есть две проблемы.
Во-первых, в самих маркетинговых материалах от Lightbend-а практически нет никаких доводов, которые подтверждали бы озвученные в white-paper-ах тезисы. Т.е. если при чтении white-paper-а ты включаешь критическое мышление и пытаешься понять, как какое-то свойство реактивной системы проистекает из свойств модели акторов, то остаешься слегка озадаченным. Ну, например, дабы не быть голословным, можно рассмотреть один из тезисов из раздела с заголовком "Prioritize resilience before thinking about elastic scaling in the cloud". Там идут несколько абзацев текста, из которых я выделю один из заключительных:
The key to achieving this is message-driven service interaction, which automatically provides the core building blocks that enable systems to be resilient against failures at many different levels. In turn, these building blocks serve as a rock-solid foundation that is capable of scaling in and out elastically across all system resources.
Т.е. один из ключевых моментов в достижении устойчивости приложений (т.е. обеспечения resilience из Reactive Manifesto) является использование интеграции сервисов на базе обмена сообщениями. Такая интеграция автоматически представляет базовые строительные блоки, которые позволяют системам переживать сбои на разных уровнях абстракции. Так же эти строительные блоки могут стать прочным фундаментом, на котором можно выстроить эластичное масштабирование на все имеющиеся в системе ресурсы.
Пока все нормально, давно известная банальность о том, что асинхронное взаимодействие через обмен сообщениями лучше переживает нештатные ситуации и лучше масштабируется, чем синхронный RPC. Правда, за это нужно платить свою цену, но мы сейчас не об этом. А об одном из тезисов, который приводится в качестве уж не знаю чего: доказательства или же просто резюме по теме resilience. А именно:
Master resilience and elasticity to achieve system responsiveness. Modern applications must be resilient at their core in order to scale and remain responsive under a variety of real-world, less than ideal conditions. The result is a consistently responsive system ready for business.
Т.е. вы должны озаботиться отказоустойчивостью и эластичностью для того, чтобы система была отзывчивой. Современные приложения должны быть отказоустойчивыми по своей сути для того, чтобы иметь возможность масштабироваться и оставаться отзывчивыми в различных условиях реального мира, которые далеки от идеала. В результате получится устойчиво отзывчивая система, готовая для применения в деле.
Если вдуматься в то, что здесь написано, то легко увидеть, что это обычный банальный призыв за все хорошее и против всего плохого "будьте богатыми и здоровыми, а не бедными и больными".
На мой взгляд, на 18 страницах этого white-paper-а можно найти всего пару-тройку абзацев, которые действительно как-то увязывают тезисы продавцов от Lightbend-а с возможностями и/или особенностями модели акторов. Причем, если не ошибаюсь, это уже не первый такой white-paper. Т.е. настоятельное вливание в уши публики информации о тесных взаимосвязях Reactive Manifesto и модели акторов происходит давно. И это не могло не дать своих результатов.
Тут-то как раз можно поговорить и про "во-вторых". Во-вторых, народ уже начинает путать Reactive Manifesto и Actor Model. Яркий пример всплыл намедни на Хабре: Microservices и Модель Акторов (Actor Model). Там большое видео, речь по Actor Model заходит где-то после 30-й минуты. Но докладчик просто-напросто начинает рассказывать про свойства модели акторов через перечисление свойств реактивных систем, скопипащенных из Reactive Manifesto. Вот уж, действительно, смешались в кучу кони, люди...
Т.е. люди уже говорят о модели акторов не сильно понимая что это и зачем. Ну а для чего понимать? Вот, большие дяди из Twitter-а используют модель акторов для решения своих проблем, значит все нормально.
Все это мне не нравится. Потому, что я сам являюсь продавцом продуктов и услуг, построенных на эксплуатации модели акторов. Но, в отличии от успешных товарищей из Lightbend, у меня нет цели гнать маркетинговую пургу. Потому что инструментарий для работы с акторами -- это как опасные в эксплуатации бензопилы или электросварочные агрегаты. Если у вас нет опыта работы с ними и/или вы не понимаете зачем и для чего нужна бензопила или электросварка, то вы себя просто покалечите или убьете нахрен (еще неизвестно, что лучше). Точно так же и с использованием акторов в разработке: если вы не представляете, что это такое, чего от них ждать и как их лучше использовать, то просто угробите свой проект. А потом еще раструбите на весь Интернет о том, какое говно вообще модель акторов, а уж конкретная реализация от продавца X -- просто говняное говнище.
Лично я бы хотел играть в долгую и мне не выгодно рассказывать небылицы о модели акторов дабы получить быстрый сбыт, вскоре после которого пройдет мощная волна негатива. Поэтому мне интереснее рассказывать о том, что есть, называя вещи своими именами. Пусть в итоге наши разработки будут использовать реже, но зато положительная отдача в каждом из внедрений будет выше. Имхо, 10 счастливых клиентов из 10 лучше, чем 10 счастливых клиентов из 100.
Так вот, не стоит думать, что свойства реактивных систем (т.е. перечень из responsive, resilient, elastic и message-driven) являются свойствами модели акторов. Они такими не являются. Как и свойства модели акторов не являются свойствами реактивных систем.
Реактивные системы вполне можно строить и без использования акторов. Например, запросто может быть message-driven взаимодействие на базе модели publish-subscribe плюс task-based parallelism для обработки прикладных сообщений.
На базе акторов легко построить систему, которая не будет реактивной от слова совсем. Т.е. она не будет ни отзывчивой, ни отказоустойчивой, ни масштабируемой. Да, она будет message-driven, но для реактивности системы одного message-driven свойства недостаточно.
Использование акторов может вам упростить разработку реактивной системы. Может. Поскольку message-driven уже является частью модели акторов и если вы научились успешно использовать подход на базе обмена сообщениями с акторами, то вам будет проще строить реактивную систему поверх акторов. Так же сама возможность создавать в приложении большое количество акторов, отсутствие разделяемого состояния между акторами, а так же, обмен сообщениями, открывает вам более простые пути для масштабирования своего приложения. Например, отсутствие разделяемого состояния и обмен сообщениями позволяют разделять приложение на компоненты, каждый из которых будет работать в своем процессе, может быть даже эти процессы будут запущены на разных нодах. Да и внутри одного процесса разные группы акторов можно привязывать к разным рабочим контекстам, дабы акторы, выполняющие длительные синхронные операции, не блокировали легковесных акторов, обрабатывающих свои сообщения за доли миллисекунд.
Ключевое слово: может. Может упростить. А может и усложнить.
А может быть и так, что разрабатываемое вами приложение вообще не будет реактивной системой, но при этом будет использовать у себя внутри модель акторов для упрощения распараллеливания обработки потоков данных. Например, если ваше приложение перегоняет видеопоток из одного формата в другой.
В общем, в сухом остатке: Reactive Manifesto и Actor Model -- это совершенно разные вещи. Actor Model может использоваться в реализации реактивных систем. Может даже приносить пользу в этом деле. Но может и не приносить. И, более того, может и не использоваться. Так что, повторюсь: Reactive Manifesto != Actor Model. И, соответственно, свойства реактивных систем (как то: responsive, resilient, elastic и message-driven) не являются свойствами модели акторов (и наоборот).
Контрразведчик Разработчик должен знать всегда, как никто другой, что верить в наше время нельзя никому. Порой даже самому себе продавцам волшебных пилюль от Lightbend. Мне можно! ;)
Комментариев нет:
Отправить комментарий