Комментарии 29
Интересно! Не подскажите ли примеры открытых проектов с использованием Akka? Было бы любопытно посмотреть… Жду продолжения статьи.
Насколько сильна поддержка security в akka? Это всё так же хорошо как и в resteasy или spring или нет?
Да, это, наверное первый момент, remote actors as protected resources, что-то такое, поддержка oauth, например.
Ну и возможно секурные аннотации by Akka?
Ну и возможно секурные аннотации by Akka?
Похоже я не совсем так объяснил что это и для чего. Акторы это внутренние объекты, из которых строится в основном ядро бизнес логики. Remote actor позволяют размазывать это ядро по нескольким машинам. Но это никак не относится к уровню представления, например rest сервисам.
Безусловно rest api позволяет дергать actor для выполнения каких-то действий, но oauth и подобное, полностью ортогонально концепции actor и никак с ними не пересекается.
Безусловно rest api позволяет дергать actor для выполнения каких-то действий, но oauth и подобное, полностью ортогонально концепции actor и никак с ними не пересекается.
Очень интересно, но High Load как мотивации для ознакомления и ограничение возможности масштабирования из-за использования внутри VM как-то между собой не срастаются. Может все-таки JMS (с MesageBeans) более подходящий инструмент?
Не совсем понял где я написал что ограничена возможность масштабирования из-за использования jvm? Jms это как вариант, но если вы заставите все классы вашего приложения для каждого вызова метода дергать jms, то ваше приложение умрет смертью храбрых. Кроме того насколько я помню надо будет быть очень аккуратным с выбором сервера и драйвера к нему, потому что очень многие драйвера на каждый listener создают новый поток для обработки, что черевато.
Не использование jvm, а изспользования внутри jvm. Вы же написали, что очередь сообщений живет внутри JVM. Разве это не накладывает естественное ограничение одной машины?
Каждый listener в своем потоке — есть такое, по крайней мере ActiveMQ так делает. А чем черевато? Я просто только что перенес логику одного проекта на jms, пока проблем не вылезло. Может я недосмотрел или недодумал чего-то?
Каждый listener в своем потоке — есть такое, по крайней мере ActiveMQ так делает. А чем черевато? Я просто только что перенес логику одного проекта на jms, пока проблем не вылезло. Может я недосмотрел или недодумал чего-то?
Во-первых авторы могут взаимодействовать между разными jvm — на одной машине надо просто импортировать актор с другой машины.
Про один поток на листенер это черевато вот чем — что будет когда у вас система будет работать с 1000 листнеров? Или с 10000? Так как акторы работают в пуле то для них это не имеет значения
Про один поток на листенер это черевато вот чем — что будет когда у вас система будет работать с 1000 листнеров? Или с 10000? Так как акторы работают в пуле то для них это не имеет значения
А не расскажите какие есть варианты использования акторов? Для highload, как мне казалось, наиболее актуальны stateless системы в силу простоты обеспечения отказоустойчивости и масштабируемости (state в таком случае хранится в отдельном от подсистемы БЛ хранилище, где проблемы отказоустойчивости и масштабируемости решаются уже отдельно).
Наверное, stateful архитектура актуальна для систем в которых происходит активное взаимодействие между пользователями. В «классических» stateless системах это приводит к огромной нагрузке на запись на БД. Примером могу служить многопользовательские игры. В таком случае применение акторов было бы, как мне кажется, более уместным, чем обмен сообщениями через сервисы-посредники. Я прав? :)
Наверное, stateful архитектура актуальна для систем в которых происходит активное взаимодействие между пользователями. В «классических» stateless системах это приводит к огромной нагрузке на запись на БД. Примером могу служить многопользовательские игры. В таком случае применение акторов было бы, как мне кажется, более уместным, чем обмен сообщениями через сервисы-посредники. Я прав? :)
Акторы сами по себе могут быть stateful или stateless, это как вы захотите и как вам будет удобно. Создать новый актор это легкая операция и создавать их можно по мере необходимости из других акторов.
У самих акторов есть методы postStart preStop чтобы сохранять-восстанавливать состояние по необходимости.
А игры наиболее интересный с точки зрения пример, где любые другие подходы не тянут. Например, если у нас есть ферма, то для каждого объекта можно создать актор для обработки событий для него. Т.е. для каждого деревца, каждого кустика будет свой concurrent обработчик, который реагирует на действия разных игроков, и при этот система не умрет от огромного количества потоков.
У самих акторов есть методы postStart preStop чтобы сохранять-восстанавливать состояние по необходимости.
А игры наиболее интересный с точки зрения пример, где любые другие подходы не тянут. Например, если у нас есть ферма, то для каждого объекта можно создать актор для обработки событий для него. Т.е. для каждого деревца, каждого кустика будет свой concurrent обработчик, который реагирует на действия разных игроков, и при этот система не умрет от огромного количества потоков.
>и при этот система не умрет от огромного количества потоков
Вот с этого момента можете по подробнее? Как акторы связаны с потоками? На каждый актор создается свой поток или как? Что будет если таких акторов надо 100к создать?
Вот с этого момента можете по подробнее? Как акторы связаны с потоками? На каждый актор создается свой поток или как? Что будет если таких акторов надо 100к создать?
Концепция акторов она как бы надпоточна, т.е. сообщения к одному актору должны обрабатываться последовательно и независимо. Поэтому по умолчанию создаются пулы процессов, которые обрабатывают сообщения. Есть возможность настроить akka так чтобы под какие-то акторы выделялся отдельный поток для обработки.
А евент ориентированные библиотеки типа Drools или Esper для этой цели не подойдут?
Я думаю актор это примитив чуть более низкого уровня. Акторы используются для построения многопоточных систем, как например для этого используются блокировки и STM.
Т.н. «актеры» — основа API в Windows и существуют еще с незапямятных времен (кто помнит обмен сообщениями WM_).
Каждый актер — это single-threaded объект, доступ к которому осуществляется через очередь сообщений (и различные враперы типа TypedActors). Т.о. не болит голова о синхронизации и блокировках. Все, что внутри объекта используется им эксклюзивно.
У архитектуры, построенной на актерах есть одно преимущество в то же время недостаток — она асинхронная. То есть в заданный момент времени нельзя определить четко состояние всей системы, что становится проблемой например при ее остановке. Не совсем ясно в какой последовательности останавливать актеров, т.к. они могут зависеть друг от друга. И если актер уже остановлен, а другой пытается послать ему сообщение, он вылетит с ошибкой. Поэтому у асинхронной архитектуры очереди сообщений обычно делают persistent и выносят в отдельный леер (JMS,MQ), чтобы при рестарте компонентов сообщения не терялись.
Также у асинхронной архитектуры есть пробемы для реализации сложной атомарной операции между актерами (транзакция), поскольку их состояние ни в какой момент несинхронизровано. В Akka для этой цели используют механизм транзакторов, которые могут координировать работу нескольких актеров. Другое решение — использовать Software Transaction Memory, реализация которой в Akka очень примитивна.
P.S. Еще замечание: использование синхронного request-reply в асинхронной архитектуре, равно как и «request-reply-with-future» — это 99% DEADLOCK. Единственное safe-решение — это request-with-callback.
Каждый актер — это single-threaded объект, доступ к которому осуществляется через очередь сообщений (и различные враперы типа TypedActors). Т.о. не болит голова о синхронизации и блокировках. Все, что внутри объекта используется им эксклюзивно.
У архитектуры, построенной на актерах есть одно преимущество в то же время недостаток — она асинхронная. То есть в заданный момент времени нельзя определить четко состояние всей системы, что становится проблемой например при ее остановке. Не совсем ясно в какой последовательности останавливать актеров, т.к. они могут зависеть друг от друга. И если актер уже остановлен, а другой пытается послать ему сообщение, он вылетит с ошибкой. Поэтому у асинхронной архитектуры очереди сообщений обычно делают persistent и выносят в отдельный леер (JMS,MQ), чтобы при рестарте компонентов сообщения не терялись.
Также у асинхронной архитектуры есть пробемы для реализации сложной атомарной операции между актерами (транзакция), поскольку их состояние ни в какой момент несинхронизровано. В Akka для этой цели используют механизм транзакторов, которые могут координировать работу нескольких актеров. Другое решение — использовать Software Transaction Memory, реализация которой в Akka очень примитивна.
P.S. Еще замечание: использование синхронного request-reply в асинхронной архитектуре, равно как и «request-reply-with-future» — это 99% DEADLOCK. Единственное safe-решение — это request-with-callback.
мне кажется или все эти чудесные концепции появились очень и очень давно?
мне показалось что абсолютно аналогичный концепт я видел в CORBA, когда логика завязана на EventService.
мне показалось что абсолютно аналогичный концепт я видел в CORBA, когда логика завязана на EventService.
Ну так это постмодернизм — ничего нового, только обсасывание старых концепций :)
что то в последнее время я начинаю охреневать, от того что концептуальные и прорывные вещи оказываются таковыми только на словах, а на деле, это просто хорошо забытое старое.
всегда жутко интересно слушать самозабвенные рассуждения об очередной супернавороченой архитектуре, а потом обнаружить полную копию одного из тех 9000+ сервисов CORBA, которые были описаны еще в конце 90-х. может просто у меня старость подкрадывается :)
опять же, с экторами была чудесная ситуация, когда в самом начале очередной лекции о новомодности экторов, весь полет мысли апологета, был сбит фразой о том что это все было еще в Simula-67 :)
всегда жутко интересно слушать самозабвенные рассуждения об очередной супернавороченой архитектуре, а потом обнаружить полную копию одного из тех 9000+ сервисов CORBA, которые были описаны еще в конце 90-х. может просто у меня старость подкрадывается :)
опять же, с экторами была чудесная ситуация, когда в самом начале очередной лекции о новомодности экторов, весь полет мысли апологета, был сбит фразой о том что это все было еще в Simula-67 :)
Где же продолжение? :)
Это первый, который уже не так актуален + я в самой akka разочаровался :)
В чем причина разочарования?
Сложность разработки не компенсируется возможностям или масштабированием. Это подходит для систем, которые не надо останавливать, потому тогда нет проблемы с потерями сообщений. А если решать проблему потери сообщений при остановке (хранение или внешние транзакции), то от акторов остается только фасад, а все кишки обычным синхроном.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Akka для Java разработчика (часть 1)