Посоветуйте литературу по проектированию асинхронных приложений.
Интересует абсолютно все — "правильное" разбиение на слои, обработка ошибок, конкаренси, мониторинг операций, проектирование UI, ... Аналог Фаулервской "Архитектуры корпоративных приложений", но с упором на специфику асинхронные приложения.
Здравствуйте, Lloyd, Вы писали:
L>Привет,
L>Посоветуйте литературу по проектированию асинхронных приложений.
L>Интересует абсолютно все — "правильное" разбиение на слои, обработка ошибок, конкаренси, мониторинг операций, проектирование UI, ... Аналог Фаулервской "Архитектуры корпоративных приложений", но с упором на специфику асинхронные приложения.
Сам перелопатил кучу всяких статей об этом, но не видел ничего достаточно исчерпывающего в одном месте, так что ссылку дать, увы, не могу.
Стоит искать инфу на тему EDA (Event Driven Architecture), т.к. асинхронные приложения, чтобы использовать параллелизм на 100%, должны быть событийно-управляемыми.
Готовых и законченных фреймворков (по крайней мере для .NET) не встечал, придется велосипедировать.
Конечно, можно программировать параллелизм напрямую (http://parallelpatterns.codeplex.com/ и т.п.), но это не наш метод
Вероятно, нет ничего удобнее, чем писать код в стиле
[EventDriven]
public class BigBoss
{
[EventPublisher(Topic = "App\Work\Start")]
public EventHandler<string> StartWork;
public void Start()
{
StartWork("Всем работать!!!");
}
}
...
[EventDriven]
public class Worker
{
[EventSubscriber(Topic = "App\Work\Start")]
private void StartWorkHandler(string message)
{
Console.WriteLine("Не рагайся, насяльникэ...");
}
}
Здравствуйте, Sinix, Вы писали:
L>>Посоветуйте литературу по проектированию асинхронных приложений.
S>Кмк, общих рекомендаций будет мало, т.к. оно слишком зависит от используемого фреймворка/специфики проекта. Вон на stackoverflow советуют F#. А так люди больше стараются изобрести свой plinq и посматривают в сторону rx.
S>К.О.: что вполне очевидно — пока не будет дешёвых потоков, многопоточность ради неё самой заводить никто не будет.
S>Вы поделитесь конкретной задачей — а то рекомендаций можно надавать от простого load-балансера с wait-пулом до изобретения своего workflow-движка.
Имхо, многопоточность с воркфлоу имеет весьма отдаленное отношение к асинхроности, эти понятия ортогональные.
Приведу пример, что имено я имел в виду.
Пусть у нас есть магазин по продаже товаров. Заказчик оформляет заказ и сабмитит его. В ответ система должна зарезервировать товар на складе (или дозаказать у поставщика) и оформить доставку. Доставщиком может быть внешняя фирма и офрмление доставки может быть достаточно продолжительным.
В таких случаях для интеграции разных подсистем обычно рекомендуют использовать очереди сообщений (например, MSMQ). В описываемом примере в ответ на сабмит заказа в очередь сообщений склада будет поставлена заявка на резервирование товара, а в доставщику — заявка на доставку. В случае когда обе эти заявки успешно обработаны, эти подсистемы уведомят исходную подсистему о завершении работы и та в свою очередь сможет изменить статус заказа и проинформироваь об этом пользователя.
В описаном примере есть промежуток времени между совершением операции и получением результата и в этот промежуток времени может произойти много инетересного: внешняя система может быт не в состоянии обработать заявку или вовсе по каким-то причинам потерять ее,заказ может быть изменен до того, как заявку начали обрабатывать, пользватель может отменить заказ и т.д. и т.п.
Я ищу литературу, в которой были бы собраны рекомендации по проектированию подобного типа приложений. Имхо задача достаточно распространенная и такая литераура должна существовать.
Здравствуйте, Lloyd, Вы писали:
L>Имхо, многопоточность с воркфлоу имеет весьма отдаленное отношение к асинхроности, эти понятия ортогональные.
Ну тут уж как посмотреть. Для хитрой многопоточности придётся заводить свой диспатчер + вводить понятие операций. Отсюда до воркфлоу уже рукой подать.
L>Приведу пример, что имено я имел в виду. L>Пусть у нас есть магазин по продаже товаров.
А это вы описали прям классический бизнес-вокфлоу. И классический же способ — НКА с воркером в каждом узле. Детали под капотом — типа отката состояния, оповещений и прочее — это уже вопрос реализации.
Message-driven хорош для систем с малым количеством узлов, но крайне тяжёл в отладке, т.к. состояние размазано по куче компонент (+ они должны быть stateful, что очень плохо для асинхронных задач). Зато оно живучее и простое (пока у нас нет постоянного взаимодействия).
Классический воркфлоу c воркерами и шедулером дебажить и сопровождать ненамного проще. Там главная грабля — отобразить бизнес-процесс в как можно более примитивный алгоритм, чтобы не возиться с простынёй из наноблоков.
L>Я ищу литературу, в которой были бы собраны рекомендации по проектированию подобного типа приложений.
Можно смотреть в сторону durable бизнес-транзакций и temporary database.
Здравствуйте, Sinix, Вы писали:
L>>Имхо, многопоточность с воркфлоу имеет весьма отдаленное отношение к асинхроности, эти понятия ортогональные. S>Ну тут уж как посмотреть. Для хитрой многопоточности придётся заводить свой диспатчер + вводить понятие операций.
Но этот диспатчер может работать как синхронно (fork and join), так и асинхронно (fire and forget). Потому я и написал про ортогональность.
S>Отсюда до воркфлоу уже рукой подать.
То же самое верно и для воркфлоу.
L>>Приведу пример, что имено я имел в виду. L>>Пусть у нас есть магазин по продаже товаров. S>А это вы описали прям классический бизнес-вокфлоу. И классический же способ — НКА с воркером в каждом узле. Детали под капотом — типа отката состояния, оповещений и прочее — это уже вопрос реализации.
S>Message-driven хорош для систем с малым количеством узлов, но крайне тяжёл в отладке, т.к. состояние размазано по куче компонент (+ они должны быть stateful, что очень плохо для асинхронных задач). Зато оно живучее и простое (пока у нас нет постоянного взаимодействия).
Не вижу связи между наличием состояния и асинхронностью. Или ты имеешь в виду паралельность?
Здравствуйте, Lloyd, Вы писали:
S>>Message-driven хорош для систем с малым количеством узлов, но крайне тяжёл в отладке, т.к. состояние размазано по куче компонент (+ они должны быть stateful, что очень плохо для асинхронных задач). Зато оно живучее и простое (пока у нас нет постоянного взаимодействия).
L>Не вижу связи между наличием состояния и асинхронностью. Или ты имеешь в виду паралельность?
* пытаюсь разбудить мозг и вспомнить что же хотел сказать. Кажется, имелись в виду грабли с согласованием состояний при взаимодействии нескольких узлов. Приходится изобретать механизм координации, от которого мы только что ушли.
Здравствуйте, Lloyd, Вы писали:
L>Приведу пример, что имено я имел в виду. L>Пусть у нас есть магазин по продаже товаров. Заказчик оформляет заказ и сабмитит его. В ответ система должна зарезервировать товар на складе (или дозаказать у поставщика) и оформить доставку. Доставщиком может быть внешняя фирма и офрмление доставки может быть достаточно продолжительным. L>В таких случаях для интеграции разных подсистем обычно рекомендуют использовать очереди сообщений (например, MSMQ). В описываемом примере в ответ на сабмит заказа в очередь сообщений склада будет поставлена заявка на резервирование товара, а в доставщику — заявка на доставку. В случае когда обе эти заявки успешно обработаны, эти подсистемы уведомят исходную подсистему о завершении работы и та в свою очередь сможет изменить статус заказа и проинформироваь об этом пользователя. L>В описаном примере есть промежуток времени между совершением операции и получением результата и в этот промежуток времени может произойти много инетересного: внешняя система может быт не в состоянии обработать заявку или вовсе по каким-то причинам потерять ее,заказ может быть изменен до того, как заявку начали обрабатывать, пользватель может отменить заказ и т.д. и т.п. L>Я ищу литературу, в которой были бы собраны рекомендации по проектированию подобного типа приложений. Имхо задача достаточно распространенная и такая литераура должна существовать.
Я бы смотрел по ключевым словам — длинные транзакции, распределенные транзакции, распределенные базы данных.
Основы concurrency control я думаю вы знаете, у того же Фаулера они есть.
Может быть что-то из этого вам окажется не совсем в тему, но это некоторое из того, что я качал и читал, когда были похожие задачи и когда решил разобраться в теме.
Здравствуйте, Lloyd, Вы писали:
L>Я ищу литературу, в которой были бы собраны рекомендации по проектированию подобного типа приложений. Имхо задача достаточно распространенная и такая литераура должна существовать.
Не видел таких книг ибо подобные задачи решаются adhoc и нету централизованных подходов.
Сейчас подобные системы строятся на таких компонентах:
1)Очереди сообщений, обязательно reliable
2)Workflow-движок (часто с описанием сценария в виде XML)
3)Сами приложения, выполняющие действия
4)WS-* вебсервисы для того чтобы приводить в движение все это
5)Распределенные системы логгирования для отладки
Каждый вендор предлагает свои фреймворки, приложения, а некоторые умудряются даже свои вебсервисы изобретать.
[Skipped]
В принципе, можно посмотреть статью Уди Дахана в MSDN Magazine "Создание масштабируемых систем с обработкой сбоев без потери данных" или его библиотеку NServiceBus как воплощение решений проблем, описанных в статье. Все в том же русле EDA, MSMQ и т.п.
