Size: a a a

Scala User Group

2020 July 23

λ

λoλzod in Scala User Group
Vyatcheslav Suharnikov
и самое главное - почему это плохо
это не плохо, акторы наверное хорошо подходят для чисто Command Centric приложений, когда нет сильной привязки вызова к ответам, то есть по одному каналу идёт инициирование действий, по другому каналу приходят результаты этих действий, соответственно не нужно выстраивать логику обработки ошибок и ответов соответсвенно вызовам
источник

λ

λoλzod in Scala User Group
но такое двухканальное взаимодейтсвие можно более элегантно так же построить используя стримы
источник

AZ

Alex Z in Scala User Group
λoλzod
это не плохо, акторы наверное хорошо подходят для чисто Command Centric приложений, когда нет сильной привязки вызова к ответам, то есть по одному каналу идёт инициирование действий, по другому каналу приходят результаты этих действий, соответственно не нужно выстраивать логику обработки ошибок и ответов соответсвенно вызовам
А можно пример Command Centric приложения? Типа что-то собирает и обрабатывает данные с тысячи сенсоров и не возвращает им ответ?
источник

AF

Anton Feoktistov in Scala User Group
λoλzod
но такое двухканальное взаимодейтсвие можно более элегантно так же построить используя стримы
Стримы, потому что нет состояния, который актор хранит. Как только появляется стейт становится интереснее
источник

VS

Vyatcheslav Suharnik... in Scala User Group
аналитика та же, ну не дошло 1 событие - фиг с ним
источник

λ

λoλzod in Scala User Group
Anton Feoktistov
Стримы, потому что нет состояния, который актор хранит. Как только появляется стейт становится интереснее
все современные стримы эффектфул, то есть предполагается выполнение каких-то стейтфул операций
источник

AF

Anton Feoktistov in Scala User Group
λoλzod
все современные стримы эффектфул, то есть предполагается выполнение каких-то стейтфул операций
Стейт я имею ввиду пойди в базу - прочитай из бады
источник

AD

Apache DOG™ in Scala User Group
Anton Feoktistov
Какая альтернатива стейту+шардингу есть в скале?
Шардирующие бд и шины сообщения
источник

λ

λoλzod in Scala User Group
Alex Z
А можно пример Command Centric приложения? Типа что-то собирает и обрабатывает данные с тысячи сенсоров и не возвращает им ответ?
ну например какие-нибудь message oriented хабы для телекоммуникаций, где нет развесистой бизнес-логики
ну или да сбор и аггрегирование метрик
или мессенджеры, где все вызовы без ответов, а какие-то результаты доставляются Update-ами
источник

λ

λoλzod in Scala User Group
Anton Feoktistov
Стейт я имею ввиду пойди в базу - прочитай из бады
ну и я про это, мы ведь не про Java streams api
источник

AF

Anton Feoktistov in Scala User Group
Apache DOG™
Шардирующие бд и шины сообщения
И тогда акка будет быстрее
источник

λ

λoλdog in Scala User Group
Anton Feoktistov
И тогда акка будет быстрее
Быстрее чем что
источник

AF

Anton Feoktistov in Scala User Group
λoλdog
Быстрее чем что
Быстрее чем сходить в бд
источник

AD

Apache DOG™ in Scala User Group
Anton Feoktistov
И тогда акка будет быстрее
Быстрее != Лучше. Вся акка система один громадный ГА, оттрассировать траектории которого невозможно человеческими скудными мозгами(да и суперкомпьютеров на это не напасешься). Ну это значит что в акте любая система обречена быть забагованой
источник

λ

λoλzod in Scala User Group
Apache DOG™
Быстрее != Лучше. Вся акка система один громадный ГА, оттрассировать траектории которого невозможно человеческими скудными мозгами(да и суперкомпьютеров на это не напасешься). Ну это значит что в акте любая система обречена быть забагованой
ну нет, мне кажется большинство проблем с аккой это из-за нецелевого использования
источник

VS

Vyatcheslav Suharnik... in Scala User Group
держи медаль по софистике 😄
источник

λ

λoλzod in Scala User Group
и вообще это даже очень просто
чтобы мы не делали получаются сервисы, а сервисы на акторах это так себе затея
если смочь построить несервисную архитектуру, то норм
источник

AF

Anton Feoktistov in Scala User Group
Apache DOG™
Быстрее != Лучше. Вся акка система один громадный ГА, оттрассировать траектории которого невозможно человеческими скудными мозгами(да и суперкомпьютеров на это не напасешься). Ну это значит что в акте любая система обречена быть забагованой
Быстрее != Лучше, согласен, поэтому я бы брал акку когда есть СЛА, и бизнес говорит во сколько нужно уложиться. И только после тестов переписывать на аку
источник

AF

Anton Feoktistov in Scala User Group
λoλzod
и вообще это даже очень просто
чтобы мы не делали получаются сервисы, а сервисы на акторах это так себе затея
если смочь построить несервисную архитектуру, то норм
В чем проблема иметь сервисы, а рядом пару тройку акторов?
источник

Oℕ

Oleg ℕizhnik in Scala User Group
Anton Feoktistov
Какая альтернатива стейту+шардингу есть в скале?
Есть набор жава  решений, которые можно использовать для реализации распределённых систем hazelcast, atomix.
Можно и ту же акку использовать, но только для внутрикластерного общения, а не в качестве базовой либы для конкаренси.
Но чаще эти задачи возлагают просто на внешние сервера, как уже многократно говорили
источник