6952
правки
Изменения
м
Нет описания правки
{{Conf-Ref}} В конце июня прошла конференция [https://highload.ru/spb/2023 '''Saint Highload-2023'''] в Питере. Как обычно, на конференции было много интересных докладов про современные технологии. Вообще я пользуюсь конференциями Highload чтобы держать руку на пульсе технологического развития. Правда, на мой взгляд, никаких вау-изменений не происходит, идет поступательное развитие технологий. Но навести фокус всегда полезно.
А еще в этот раз было много докладов про архитектуру приложений и ее реинжиниринг для решения различных задач. Правда, часть из них была в режиме story telling, хотя и со схемами: у нас была задача, мы ее решили. Это несколько огорчает. Потому что такие доклады любопытны, но всегда есть прагматичный вопрос: какой из этой истории можно извлечь позитивный опыт для собственного применения? Высший пилотаж, когда был анализ этого опыта, выделены какие-то классы задач и полезные шаблоны для них. Менее интересно, но тоже содержательно, когда просто выделен некоторый полезный шаблон. Но во многих докладах этого нет. Там идет рассказ о решении распространенных задач, и используются понятные и известные шаблоны. Это не значит, что задача была тривиальной, были исследования и эксперименты, пробовали разное. Но при этом ничего принципиально нового - нет.
Актор - примитив параллельного, вернее, конкурентного, вычисления, который обрабатывает сообщения из своей входной очереди и посылает их другим акторам. При этом в статье были важные полагания: одно сообщение обрабатывается полностью, нет гарантий порядка отправки сообщений, сообщения могут теряться и нет никаких синхронных вызовов. У актора есть состояние, которое влияет на обработку сообщений, при обработке он может посылать сообщения другим, менять состояние, создавать других акторов. И, кроме обмена сообщениями, никакого взаимодействия между акторами нет, что как раз обеспечивает возможности масштабирования.
Модель отношений акторов: иерархическая и одноранговая. В иерархической - родитель создает, решает что делать при ошибке, можно восстановить, в том числе с сохранением очереди. В одноранговой акторами управлет управляет run-time, создавая акторы по необходимости для обработки сообщений и удаляя при отсутствии активности.
Usecase: pipeline proicessingprocessing, transaction application, стриминг данных (реактивные системы, event-based, чаты), multi-user concurencyconcurrency, приложения с распределенным состояниям, для которых не хватает одной машины, IoT - сообщения от датчиков и состояния, Timers - много таймеров по разным условиям.
И дальше был их пример. Dodo работает в 20 странах и в каждой надо интегрироваться с местным эквайрингом для приема платежей, никакого стандарта нет. Они использовали Microsoft Orleans, фреймворк появился в 2015, потом заснул и перспективы были неясны, но сейчас вроде проснулся и будет развиваться. Дальше было ряд рекомендаций: не забыть про observability (логи метрики трейсы); помнить что ресурсы не бесконечны, хотя актор и легковесен, и mailbox не бесконечный. Продумать восстановление состояния и балансировку нагрузки. А еще написание в синхронном стиле async/await приводит к тому, что между потоками могут возникать deadlock.