async turtles all the way

[Palych]

В копилку:
http://www.infoq.com/presentations/clojure-core-async
https://skillsmatter.com/skillscasts/42 ... async-4233

[Сабина]

Вопрос назрел про Акку, сама с ней знакома поверхностно, вопрос возможно совсем dummy

Вижу что ее все чаще используют в reactive pipelines для back pressure handling etс. Но это обычно на той стороне паплайна где идет сборка данных - ставишь свои сервера с Аккой, пишешь сервисы и все с ними говорят сливая данные через те сервисы в Кафку например.
У меня немного другой случай. Из warehouse народ хочет совать данные в Кафку и потом из нее вычитывать и посылать на вские разные rest endpoints ( для dashboards, charts, etc).
По простому - можно писать Джава код, который можно запустить как background process, расспараллелив по числу Kafka partitions. Он будет из Кафки вычитывать сообщения и посылать на remote REST endpoints ( каждый процесс на свой endpoint).
Я насмотрелась Akka-HTTP презентаций и мне уж очень нравится библиотека - приятные очень http коннекторы, абстракция мощная, позволяет регулировать HTTP calls back pressure( если receiving side is getting slow и так далее) на уровне TCP.

Вопросы:
- а не есть ли overkill использовать Акку, если задача просто посылать HTTP REST calls на удаленные сервера ? There are obvious scaling needs
- что нужно с точки зрения infrastructure/provision ? Akka server ставить для этого ? Или можно просто как библиотеку использовать из свой Джава/Scala программы ? Они хоть и пишут что есть server and client side libraries, Но везде подчеркивают что это не фреймфорк, а целая infrastructure. Возможно есть опция испольщвать их client side code как библиотеки, понимая что каких то фичей при этом не будет ?

PS. Вот например. С одной стороны то что нужно, с другой стороны если что-то не учтешь - пострадаешь https://doc.akka.io/docs/akka-http/curr ... ntity.html

[Palych]

Мне племянник показал Spring 5 reactive... Внушает: просто и сердито..

[Сабина]

Мне племянник показал Spring 5 reactive... Внушает: просто и сердито..

Мне reactive непринципиально, просто ищу что больше подойдет.
В моем случае нужна технология чтобы написать scalable Kafka consumer, который будет прочитанное посылать на remote endpoint.
То есть надо чтобы можно было горизонтально скейлить, грубо говоря налепить кучу такх с минимальным усилием чтобы они делили load если он растет.

Я примерно такие вижу плюсы минусы всех существующих вариантов:

Option 1: написать самой ( конечно используя только библитеки Кафка и REST (Jackson например). Запаковать в jar с dependencies и потом запускать обычный java процесс каким нибудь scheduler. Несколько таких можно запихать в Кафка консьюмер группу. Но минусы следующие:
- под каждый такой консьюмер нужен отдельный хост (consumer group etc)
- когда пишешь все сам шансов накосячить больше, особенно с concurrency
- orchestration всего процесса нулевая практически

Option 2: Springboot
- small footprint, comes with it's own container
- интеграция с Кафкой, библиотеки для REST, секьюрити и прочий web services staff out of the box
- можно запускать в докерконтейнерах, то есть по нескольку на хосте
- встроенные heartbeat, мониторинг, logging

Option 3: Akka ( тут чисто из теоретических познаний потому и спрашиваю)
- small footprint ( 1 actor - 400K), can deploy 10K actors on a single laptop
- concurrency is handled by framework, you program your business logic as it is singlethreadded
- integration with Kafka
- Akka http allows you to treat http connection as socket connection which stays open and actor can constantly send messages there ( like streaming)
- handles backpressure, can control traffic/slow packages at TCP level if needed

То есть последняя опция вроде бы супер для streaming application, кроме того что я вообще с этим не работала . Попробовала бы наверное, но не совсем пойму как это дело деплоится ? Тоже в docket container каждая копия ? Смотрю есть примеры с Play server, но у нас конечно никто не будет под каждый консьюмер ставить Play, скорее всего есть варианты попроще, но какие XЗ. Собственно это и спрашиваю , весь мануал прочитать не успеваю, из того что пока просмотрела - непонятно. Думала может тут кто работает - подскажет

[Palych]

Option 2: Springboot
- small footprint, comes with it's own container
- интеграция с Кафкой, библиотеки для REST, секьюрити и прочий web services staff out of the box
- можно запускать в докерконтейнерах, то есть по нескольку на хосте
- встроенные heartbeat, мониторинг, logging

Голосую за (2), хотя ни с чем не знаком близко.
Мне любопытно что значит выделенное.
Зачем нужно запускать по нескольку на хосте, и почему для этого нужен докер?

[Сабина]

Option 2: Springboot
- small footprint, comes with it's own container
- интеграция с Кафкой, библиотеки для REST, секьюрити и прочий web services staff out of the box
- можно запускать в докерконтейнерах, то есть по нескольку на хосте
- встроенные heartbeat, мониторинг, logging

Голосую за (2), хотя ни с чем не знаком близко.
Мне любопытно что значит выделенное.
Зачем нужно запускать по нескольку на хосте, и почему для этого нужен докер?

Чтобы запускать Kafka consumer group, а не единичный нод с кучей тредов например - resilience, scaling etc.
Докер чтобы не делать по отдельному хосту на instance
https://www.opsclarity.com/understandin ... sumer-lag/

[Palych]

Зачем нужно запускать по нескольку на хосте, и почему для этого нужен докер?

Чтобы запускать Kafka consumer group, а не единичный нод с кучей тредов например - resilience, scaling etc.
Докер чтобы не делать по отдельному хосту на instance
https://www.opsclarity.com/understandin ... sumer-lag/

(Можно я побрюзжу? Спасибо.)
"Что-то не так в этом мире, сынок..."
Сначала берём Java Virtual Machine, изолируем код от ОС.
Потом рисуем изящные функциональные фреймвёрки чтобы изолировать логику от многопоточности.
С другой стороны - добавляем средства управления потоками (executers, FJP, etc.)
Заодно избегаем ненужного изменения общего состояния за счёт IoC/

Далее - строим на всём этом приложение, которое избегает множественных потоков.
А поскольку нужно выполнять работу параллельно - вместо потоков запускаем отдельные процессы (каждый - внутри JVM).
Потом каждые процесс оборачиваем во отдельную виртуальную машину (контейнер).

"...а теперь господа - пристегните ремни, и попробуем со всей этой фигнёй взлететь..."

[Сабина]

Я извиняюсь наверное запутала вас своей фразой . Треды они никуда не деваются и у единичного нода , имелось в виду что когда большой поток данных (в ту же Кафку) , то в какой то момент одного нода станет мало, даже если грамотно сделать concurrency и выжать макс из имеющейся системы. Ведь современные системы на том и построены - horizontally scaled architecture deplyed to low commodity systems.
Ну и когда сей момент наступит то выбора два:
(1) посадить нод (кафку консьюмера как пример) на отдельный бокс (хост в EC2 скажем) и сконфигурировать кучку таких же как consumer group, чтоб разделили работу.
(2) Или еще вариант насовать их в контейнеры вроде докера, где можно больше одного на хост. Но там насколько я помню «немного влазит» и оно как бы противоречит идее failure proof на одну машину пихать

Ну и подитожить ... Фреймворки они нужны чтобы plumbing code не писать. Потому что когда сам - то скорее всего будет глюкавое, если еще и не серое вдобавку. Это вам не известный опенсорс фреймворк под Apache license

[Сабина]

чета я такие вещи открываю на новом месте что в шоке иногда . Сегодня узнала что Kafka messages larger than few KB ( like 5-10) can blow up cluster

[Palych]

чета я такие вещи открываю на новом месте что в шоке иногда . Сегодня узнала что Kafka messages larger than few KB ( like 5-10) can blow up cluster

А что конкретно подрывает понятно?

[Сабина]

чета я такие вещи открываю на новом месте что в шоке иногда . Сегодня узнала что Kafka messages larger than few KB ( like 5-10) can blow up cluster

А что конкретно подрывает понятно?

lag большой. мессадж большой тоже конечно может, но это скорее 20MB+, а не 5КВ