Вот эта статья от Яндекса на Хабре: "Архитектура сервиса распределённых очередей сообщений в Яндекс.Облаке". И картинка оттуда, демонстрирующая наличие акторов:
К сожалению, про самих акторов там рассказывается не очень много. Имхо, основное про акторов там рассказано в следующих двух фрагментах.
№1:
YMQ Actor system – акторная система. В ней одновременно запущены тысячи различных акторов, обменивающихся информацией. Акторная система каждого хоста — это часть кластера. Все акторы кластера живут и действуют как единое целое. Бизнес-логика YMQ реализована в различных акторах, осуществляющих запросы-транзакции к YDB.
№2:
Мастер очереди – актор, который в обычных условиях существует в кластере в единственном экземпляре и пропускает через себя все запросы, связанные с конкретной очередью. Если запрос к очереди приходит на сервер, где нужный мастер отсутствует, специальный прокси-актор перенаправляет запрос, а затем транслирует обратно полученный от мастера ответ.
Из чего я могу предположить, что акторы в YMQ используются для реализации если не всей логики обслуживания очередей, то изрядной части этой логики.
И, как по мне, сама по себе задача разработки системы, вроде YMQ, является отличным примером ниши, для которой могут применяться инструменты вроде Akka, SObjectizer, CAF, Actix и пр. По крайней мере наверняка могу сказать, что заложенные в SObjectizer проектные решения (вроде использования динамической памяти и исключений) не будут стоп-фактором для использования SObjectizer-а в разработке подобного проекта. В отличии от проектов, связанных с настоящими системами жесткого реального времени.
Другой вопрос, нужно ли такого рода системы разрабатывать на C++.
Ну а почему бы и нет? Вообще, список подходящих кандидатов окажется небольшой: Java (или альтернативы для JVM, вроде Scala, Kotlin, Ceylon), C#, C++ и Rust. Можно, конечно, взять в рассмотрение еще и чистый C, а так же Go. Но, имхо, стартовать сейчас что-либо на чистом C за пределами системной Linux-овой хардкорщины -- это крайняя степень изощренного мазохизма. Тогда как Go, опять же имхо, не очень хорош для разработки больших и долгоживущих проектов (просто в силу убогости заложенных в этот язык выразительных возможностей).
Так что, по сути, имеем список из Java, C#, С++ и Rust. При этом и у C++, и у Rust-а есть то преимущество, что в погоне за максимальной производительностью можно без проблем опускаться на сколь угодно низкий уровень.
Вот и получается, что есть резоны как для выбора C++, так и для отказа от C++. Посему почему бы и нет?
PS. Динамику, вроде Erlang-а, я не рассматривал. Ибо делать большие системы на динамике -- это другая крайняя степень мазохизма, имхо. Но, наверняка, Erlang или какой-нибудь Elixir можно будет использовать в разработке такого рода системы. Тут вопрос лишь в итоговой ее стоимости. Впрочем, как и в случае C++.
