EA
в целом, внешние очереди более mature technology
Size: a a a
2017 October 03
EA
другое дело что акторы уже под капотом имеют очереди
EA
и по-хорошему, они могут решить проблему сложности кода - вместо паттерна поставил в очередь, кто-то забрал и обработал у вас ясный и понятный - акторпрокси.вызовметодаактора
VS
вы описываете решение которое вы придумали. А неплохо бы начать с проблемы, которую нужно решить
Проблема - построение микросервисной архитектуры в ажуре =) Решение с сервисбасом на практике и в теории проигрывает локальным очередям
VS
Но локальные очереди конечно же ненадежные и их надо персиситить
VS
Вот и хочется понять какое же хорошее решение использовать
EA
Вроде как это не проблема. Не видно бизнес значения. Что касается вывода, то он тоже очень спорный - я делал решения и с сервисбасом, и просто с Azure Queues и все было хорошо. Другой вопрос, что я не делал сферическую архитектуру в вакууме, а решал некую бизнес-задачу
EA
Очередей много разных, в service fabric можно хоть rabbitmq запустить, и использовать
VS
Они все равно будут не локальные =) Я имею ввиду совсем локальные, на той же машине чтобы лейтенси уменьшить) Сколько у вас с сервисбасом средняя лейтенси и RPS?
EA
я что-то не понимаю ) вы хотите чтобы на каждой машине было по локальной очереди, но чтобы одновременно она была с общим стейтом? :) и вас напрягает latency 10-50ms на сетевой вызов внутри локального кластера SF?
То что делал я не упиралось в латентность очереди, но из важных метрик которые помню навскидку, 2000 одновременно загруженных jpg обрабатывалось за 2-3 минуты
То что делал я не упиралось в латентность очереди, но из важных метрик которые помню навскидку, 2000 одновременно загруженных jpg обрабатывалось за 2-3 минуты
VS
я что-то не понимаю ) вы хотите чтобы на каждой машине было по локальной очереди, но чтобы одновременно она была с общим стейтом? :) и вас напрягает latency 10-50ms на сетевой вызов внутри локального кластера SF?
То что делал я не упиралось в латентность очереди, но из важных метрик которые помню навскидку, 2000 одновременно загруженных jpg обрабатывалось за 2-3 минуты
То что делал я не упиралось в латентность очереди, но из важных метрик которые помню навскидку, 2000 одновременно загруженных jpg обрабатывалось за 2-3 минуты
Да, внутри кластера не напрягает, но c ASB это же уже не локальный кластер или как-то можно его туда поместить? Общий стейт не нужен, нужны акторы с доступом только ко своим очередям
EA
просто вызывайте актор через прокси, вызов будет сделан через внутренний механизм с очередями
EA
ASB нет, а rabbitmq можно сделать guest exe сервисом и положить в тот же кластер
EA
но если какой-то воркфлоу упирается в латентность сетевого вызова к очереди, нужно бы провалидировать дизайн :) кажется что очереди применяются как раз тогда когда время обработки задачи на несколько порядков выше взятия задачи из очереди
AK
Хочется сделать модель микросервисов-акторов с персистент входящими очередями
А почему сразу не взять Azure Service Fabric?
VS
просто вызывайте актор через прокси, вызов будет сделан через внутренний механизм с очередями
звучит очень неплохо, не подскажете ссылку почитать? хочется же все сделать надежно, чтобы сообщене не удалилось если актор упал, а также иметь возможность просматривать очередь
VS
но если какой-то воркфлоу упирается в латентность сетевого вызова к очереди, нужно бы провалидировать дизайн :) кажется что очереди применяются как раз тогда когда время обработки задачи на несколько порядков выше взятия задачи из очереди
пока ничего еще не упирается, просто страшно юзать ASB когда на тестах лейтенси больше секунды)
VS
А почему сразу не взять Azure Service Fabric?
про него и речь)
AK
Точно :) просто увидел где-то там раньше про функции)
VS
Да, на функциях это у меня лейтенси больше секунды выходит, на фабрике не проверял