Это продолжение цикла статей про разработку архитектуры. Ссылки на статьи:
Event driven architecture (EDA)
Ещё одна из популярных архитектур — Event driven architecture (EDA), что в переводе на русский означает “архитектура на основе событий”. Суть данной архитектуры состоит в том, что приложение работает с событиями (эвентами), которые генерируются пользователем или другими системами.
Предположим, у нас есть метод для обновления локации пользователей в нашей базе данных. В таком случае стандартный запрос будет выглядеть следующим образом:
Юзер послал запрос на сервер, который в свою очередь сходил в базу данных и обновил в ней данные. И всё бы хорошо, но если у нас процесс обновления локации будет содержать сложные проверки и вычисления, то это негативно повлияет на общую скорость работы системы и, как следствие, на user experience. В таком случае наши пользователи просто начнут отваливаться и не обновят запросы в базе данных. Если у нас процесс занимает какое-либо время, то лучше это спроектировать, используя паттерн эвентной архитектуры. В таком случае на запрос пользователя будет создан только эвент, говорящий о том, что пользователь хочет обновить определенные данные в базе. Однако все проверки и само обновление будет выполняться уже позже и другим сервисом. На схеме это будет выглядеть так:
Юзер сделал запрос на сервер и создал эвент о том, что хочет обновить данные в базе. Этот эвент кладется либо в очередь сообщений, либо в Kafka, это уже дело вкуса.
После этого отдельный сервис видит, что у нас появился новый эвент, и начинает его выполнять все необходимые проверки, после чего обновляет данные в базе данных и в этот момент эвент считается выполненным.
То есть, если вы хотите, чтобы ваши микросервисы общались в архитектуре EDA, то выглядеть у вас это будет примерно так:
На самом деле, данная архитектура несёт в себе много недостатков, хотя есть и преимущества. Давайте, по классике, начнём с недостатков:
Появляется новая шина сообщений, которую тоже нужно поддерживать, чтобы она была стабильной, а также масштабировать вместе с проектом и бэкапить или шардировать данные.
Появляется дополнительная задержка и отложенная синхронизация. Это может привести к тому, что запрос может выполняться дольше требований и пользователь не сразу видит свои изменения.
Требуется больше вычислительных ресурсов на создание эвентов и их чтение. При неоптимальном подходе эвентная архитектура может занимать до 50% вашего процессорного времени сервера, хотя конечно, как правило, если такую архитектуру использовать правильно и в нужном месте, то использование накладных ресурсов не будет превышать 10-15% мощности сервера.
Также появляется единая точка отказа — это наша шина. К счастью, сейчас шины надёжные, но об этом всё равно нужно помнить.
Требуется много памяти для хранения самих эвентов.
Окей, с недостатками разобрались. Что там по преимуществам?
Мы сохраняем все данные о том, что делал пользователь. В двадцать первом веке данные крайне важны, и при сохранении небольших эвентов мы имеем много информации о пользователе, которую потом можно использовать для машинного обучения.
При правильной настройке шины вы сможете восстановить все действия пользователя досконально. Это очень удобно при тестировании и отлавливании багов, ведь теперь вы всегда чётко знаете, когда и что пользователь делал в системе.
Вы также можете отследить любой момент времени и откатить продукт к состоянию на любую дату.
Становится намного проще распределять нагрузку на сервер по времени суток. Если в системе есть пиковые часы нагрузок, а в остальное время сервер простаивает, то в пиковые часы вы можете просто создавать эвенты, а сервер, предназначенный для их обработки, будет просто постепенно их обрабатывать, не сильно думая о том, что ему это нужно сделать за 10 секунд пока http request пользователя не закрылся.
Наконец, довольно удобно масштабировать сами сервисы, которые занимаются обработкой эвентов: при правильном и достаточно общем подходе у вас может быть написан отдельный сервис, который будет можно просто продублировать.
Как мы видим, эвентная архитектура, или архитектура на основе событий, имеет свои преимущества и недостатки, но в нужный момент она может очень сильно облегчить жизнь проекта и упростить его понимание и написание.
Я так же оставлю ссылку на статью об антипатернах в эвентной архитектуре: "Антипаттерны событийно-ориентированной архитектуры".
Со статьёй помогала @Ethera, за что ей большое спасибо и плюсик в карму, если кто может.)
