Что такое SEDA (поэтапная архитектура, управляемая событиями)?

Этап аналогичен «Событию». Чтобы упростить идею, представьте SEDA как серию событий, отправляющих сообщения между ними.

Я думаю, что одна из причин для использования такой архитектуры заключается в том, что вы фрагментируете логику и можете подключить ее и отделить каждое событие, в основном для высокопроизводительных сервисов с требованиями к низкой задержке.

Если вы используете Java TPE, вы можете отслеживать работоспособность, пропускную способность, ошибки, задержку на каждом этапе и быстро находить узкое место в производительности. И, как приятный побочный эффект, с небольшими фрагментами кода вы можете легко протестировать их и увеличить покрытие кода (это был мой случай).

Для справки, это внутренняя архитектура Cassandra (NoSQL) и Mule ESB (AFAIK).

Рекомендую прочитать исходную статью (извините, повторяющаяся ссылка):

• https://github.com/mdwelsh/mdwelsh.github.io/blob/master/papers/seda-sosp01.pdf.

Вот структура, которую я создал для моделирования SEDA для Java EE: http://code.google.com/p/seide/

Архитектура потоков и поэтапная архитектура событийного привода в реальной жизни:

Представьте, что у вас есть ресторан. Как это будет работать?

с «Архитектурой потока»:

1. Приходит покупатель
2. Официант (а) идет к нему / к ней
3. Официант (а) ведет его за один свободный столик.
4. Официант (а) принимает заказ
5. Официант (а) готовит заказ
6. Официант (а) проводит к столу.
7. Официант (а) ждет, пока клиент закончит свою трапезу, чтобы заплатить
8. Официант (а) проводит клиента

В этом случае официант находится с клиентом на протяжении всего процесса. Если на сервере 10 потоков, он может одновременно обрабатывать 10 подключений.

с SEDA:

1. Приходит покупатель
2. Официант (а) идет к нему / к ней
3. Официант (а) ведет его за один свободный столик (и возвращается за другим клиентом)
4. Официант (b) принимает заказ (много операций ввода-вывода, требуется время)
5. Повар готовит заказ
6. Официант (с) подносит заказ к столу
7. Официант (d) ждет, пока клиент закончит свою трапезу, чтобы заплатить
8. Официант (е) проводит клиента

В этом случае действия выполняют разные актеры. Это помогает повторно использовать участников в действиях, которые занимают меньше времени, а результат более эффективен. Действительно, так работает ресторан (возможно, несколько экземпляров официанта - это один и тот же человек, но повар определенно нет).

Это крайний пример, и, конечно, с многопоточными серверами можно выполнять некоторые асинхронные задачи. Это только теоретический пример.

Документы доступны по адресу github

SEDA, как упоминается в документе: «Основной единицей обработки в SEDA является этап. Этап - это автономный компонент приложения, состоящий из обработчика событий, очереди входящих событий и пула потоков. .. Каждый этап управляется контроллером, который влияет на планирование и распределение потоков. Потоки этапа работают, извлекая пакет событий из очереди входящих событий и вызывая обработчик событий, предоставляемый приложением. Обработчик событий обрабатывает каждый пакет событий и отправляет ноль или более событий, помещая их в очереди событий других этапов ".

На мой взгляд, вы могли бы спроектировать свою сцену как логическую модуляцию потока приложения. Он может быть основан на функциональности, на разделении задач, на производительности, на эксплуатации и обслуживании.

Я бы попросил вас прочитать прикрепленный PDF-файл, поскольку в нем упоминается необходимость в очереди событий для разделения материалов, логической компенсации для достижения максимальной эффективности компонента, как эффективно повторно использовать существующие ресурсы, над которыми работает приложение, например, сеть, хранилище и т. Д. Циклы ЦП и т. Д.,

Чтобы провести параллель, есть исследования, проведенные на рабочих сборочных конвейерах, которые работали последовательно, собирая что-то от начала до конца, и достигли меньшей производительности, но когда они были изолированы и вынуждены выполнять одну работу и передавать частично собранное устройство следующей группе, каждый из них научился эффективно управлять своей работой. По сути, процесс сборки чего-либо был разбит на несколько этапов, и каждый из них или их группа отвечали за работу на этапе.

Все, что здесь было сделано, - это включить и настроить структуру вокруг каждого человека или группы и способ общения от одного человека / группы к другому. Теперь мы можем сравнить каждого человека / группу и структуру вокруг него со сценой.

Чтобы добавить измерение событий в SEDA, подумайте о том, как группы людей общаются друг с другом и о количестве участвующих событий. Скажем, например, у ребят на этапе 1 закончились гайки и болты для завершения этапа, и они немедленно информируют менеджера отдела заказов о гайках и болтах. Не исключено, что менеджер отдела заказов получил аналогичный запрос от других парней с 6-го этапа, у которых закончились гайки и болты. Теперь он видит запросы в центральной точке (он подобен контроллеру в SEDA) и лист Excel, который у него есть, где все записи, которые он хранит, запросы размещаемых заказов (похожи на очередь в SEDA), он объединяет их и заказывает их вместе за один раз вместо отправки двух запросов заказа (управление потоками и расписанием в SEDA).

Теперь, если у вас есть такой механизм в вашей программной архитектуре, который состоит из нескольких компонентов, отправляющих различные события друг другу и имеющих контроллеры, потребляющие их и действующие соответствующим образом, то у вас, вероятно, есть очень хорошая поэтапная настройка, управляемая событиями.