Вот эта статья от Яндекса на Хабре: "Архитектура сервиса распределённых очередей сообщений в Яндекс.Облаке". И картинка оттуда, демонстрирующая наличие акторов:
К сожалению, про самих акторов там рассказывается не очень много. Имхо, основное про акторов там рассказано в следующих двух фрагментах.
№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++.
В данном случае С++ и акторы - вещи ортогональные. Можно писать на С, Go, Java, и даже Erlang и использовать акторы. В Яндексе своя специфика - много С++ программистов, поэтому был выбран соответствующий инструмент. Инфраструктура под это хорошо заточена.
ОтветитьУдалить> Можно писать на С, Go, Java, и даже Erlang и использовать акторы.
ОтветитьУдалитьРечь не о том, что вне C++ акторы нельзя использовать. Речь про то, что делать большую и сложную систему на акторах, но при этом писать на C или Go -- это глупо. Просто в силу ущербности данных языков. И, если по поводу Go еще можно поспорить, то привести какие-то веские аргументы в пользу C вряд ли получится.
> но при этом писать на C или Go -- это глупо
ОтветитьУдалитьТы заблуждаешься.
> Ты заблуждаешься.
ОтветитьУдалитьНу расскажи, при каких условиях в современном мире ты сочтешь выгодным делать большую систему на акторах и на чистом C?
А можно поподробнее про Go, а точнее про "в силу убогости заложенных в этот язык выразительных возможностей"?
ОтветитьУдалитьЧто хотелось бы иметь в языке, чтобы можно было реализовать Ваши идеи?
И какие именно идеи хотелось бы реализовать?
На мой взгляд, Акторная модель не слишком требовательная к "выразительным способностям языка", и все необходимые примитивы в языке Go уже есть, все остальное - надо добавлять библиотеками (которых, хороших, пока нет, к сожалению, но это отдельный вопрос).
@gliush
ОтветитьУдалить> Что хотелось бы иметь в языке, чтобы можно было реализовать Ваши идеи?
Да все, что давно уже существует в более-менее мощных и предназначенных для широкого круга задач языках: полноценный ООП, шаблоны или дженерики, исключения. И того, что пришло в мейнстрим недавно и еще не во все мейнстримные языки проникло: алгебраические типы данных и паттерн-матчинг. Желательно бы еще и иметь перегрузку операторов.
И речь не столько о том, что нужно в языке, чтобы иметь возможность реализовать модель Акторов. А в том, чтобы затем, когда Акторы (или, скажем task-based подход или data-flow подход) уже есть, на языке можно было бы решать сложные задачи минимизируя свои усилия. А не выписывая частокол из if err.