Я вам точно говорю, что-то не так с тестами у вас :) ASB вполне взрослое решение. Насколько я понимаю идея в следующем - вы хотите надежно вызвать актор и для этого хотите использовать очередь, чтобы либо актор ее мониторил либо она пушила задачу в актор
Инфраструктура акторов уже такая, т.е. актор точно будет вызван (ну или он просто не запустится внутри сервиса и вы это увидите) Вызов асинхронный, т.е. не нужно самому проксировать его через очереди
Т.е. просто пишете актор, пишете внутри него обработку ошибок, чтобы если ваш код падает вы понимали что с этим делать. Со всем остальным справится SF при вызове актора через ActorProxy
Только навскидку не помню, есть ли доступ ко внутренним очередям

Смотреть надо в разделе reliable actors документации, есть книжка про SF сейчас найду название и автора

вот такая

Ясно, спасибо)

масштабированием занимается Azure VmSS под кластером service fabric
вам придется его увеличивать и уменьшать как-то самому, этим SF не занимается
но как только вы дадите под нужный node type больше виртуалок (тут тоже надо аккуратно, если есть stateful акторы, просто делать scale down нельзя, надо сначала вывести ноды из кластера) то SF развернет там экземпляры ваших сервисов и запустит в них акторы

Насчет тестов - ASB в NorthEurope, AzureFunction там же, запускаю консольку через WebJob (там же) которая посылает сообщение в ASB, вывожу время в AzureFunction, почти всегда около секунды весь процесс занимает от начала посылки сообщения до вывода

может, не в ASB дело? :) напишите консольку которая мониторит ASB

Да, нужно проверить)

А если кролик повалится, SF запустит новый инстанс? Что будет с сообщениеями, которые остались поваленном инстансе, он перезапустится на той же машине и их подхватит?

Запустит, см. про guest executable в Service Fabric
Дальше сложнее. Самы простой сценарий - держать его на одной ноде, но тогда есть шанс что он повалится и пока не перезапустится будут проблемы
Сложный - сделать кластер rabbitmq запуская на каждой ноде SF по инстансу и используя например rabbitmq-autocluster. Тогда нужно будет придумать как дискаверить живой инстанс - можно попробовать что-то соорудить на основе SF naming service

Спасибо за развернутый ответ)

Еще один вопрос небольшой, никак не могу найти в документации, можно ли в одном SF кластере запускать и стейтфул и стейтлесс сервисы и акторы?

можно конечно

Отлично)

еще если вам прям очень нужны очереди, попробуйте просто azure queue (а не сервис бас) сделать в том же дц где и серфисфабрик кластер и потестировать. Кажется что будет самое простое, дешевое и удобное решение.

очереди не обязательно) прямо сейчас нужно просто предоставить примерное reliable и scalable решение для самых различных сценариев на основе ажура где будет много разных микросервисов использующих друг друга. Ну и чтобы разумные были latency и througput.

Пока что я больше всего склоняюсь к Kubernetes кластеру на ACS чтобы было больше гибкости

как раз у кубернетес будет меньше гибкости :) потому что он умеет только контейнеры
и не факт что прямо сейчас он умеет windows контейнеры (хотя тут не поручусь)
когда речь идет об оркестрации контейнеров, очень большой головной болью становятся вопрос нетворкинга.
SF умеет оркестрировать контейнеры (вин и линукс одновременно пока нет, но будет вот вот), гест сервисы, свои сервисы стейтфул и стейтлесс, и свои акторы.
Больше того можно на SF положить другой актор фреймворк, типа prohect orleans или AKKA.Net

так что насчет гибкости это вопрос такой...
что касается универсального reliable и scalable решения подходящего под все задачи мне такое неизвестно :) Разве что можно придумать типовое :)