Event Driven Architecture (EDA) Событийно ориентированная архитектура

• Event Driven Architecture (EDA) Событийно ориентированная архитектура
  • Зачем
  • Плюсы и минусы
  • Паттерны
  • Технологии
  • TODO

Зачем

Архитектурный стиль.

• Multiple subsystems must process the same events
• Real-time processing with minimum time lag
• Complex event processing, such as pattern matching or aggregation over time windows
• High volume and high velocity of data, such as IoT
• Background Jobs: Sending background messages, emails, or notifications to loads of users.
• Asynchronous Messaging: Messaging queues are the best way to implement asynchronous programming.
• High Response Time: When the response time of a request is too much. For example, calculations, searching or pdf creation, etc.

Плюсы и минусы

Критерии

Плюсы

• Слабая связность. Подсистемы получают независимые представления потока событий.
• Масштабируемость. Производительность
• Отправители и получатели независимы друг от друга
• Нет интеграции “точка — точка”. Очень легко добавлять в систему новые объекты-получатели.
• Объекты-получатели могут реагировать на события сразу при их поступлении.
• Гибкость

Минусы

• Обеспечить последовательность событий
  • RMQ не гарантирует порядок сообщений, как вариант, для этого таймметка и ключ идемпотентности и порядок обработки на стороне ИС потребителя реализовать
• Асинхронный обмен сообщениями и итоговая согласованность
• Управляемость
• Взаимодействие между службами
• Гарантированная доставка
• Сложность реализации
• Сложность тестирования

Паттерны

• two main topologies
  • The mediator topology is commonly used when you need to orchestrate (оркестрация) multiple steps within an event through a central mediator
  • broker topology (хореография) is used when you want to chain events together without the use of a central mediator
• Событие Event driven
  • Publish-subscribe
    • event-base
    • shared-data space
  • Подходы к передаче событий
    • событие
    • состояние
  • Слабая связанность (Low Coupling) — одно из основных преимуществ обработки, управляемой событиями. Это позволяет производителям событий создавать события, не зная о том, кто будет потреблять эти события. Точно так же потребители событий не должны знать об источниках событий. Из-за слабой связанности модули, потребляющие события, и модули, создающие события, могут быть реализованы на разных языках или использовать разные технологии, подходящие для конкретных задач.
• Команда Command driven
  • Task (Worker) Queue
  • RPC (команды)
• Запросы CQRS - command query request segregation
• Event sourcing
• Распределенные транзакции (лучше не делать)
  • SAGA
  • 2PC двухфазный комит
• Versioning Message
  • EasyNetQ by message type

Технологии

• Шины сообщений\событий Event\Message Bus (брокер обмена сообщениями Message Broker) можно выбрать одну из нескольких технологий (траспорт) обмена сообщениями
• Реализации шин сообщений (фреймворк)
  • .NET
    • NServiceBus
    • MassTransit или Brighter
    • EasyNetQ
    • abp.io
  • Python
    • Celery
  • PHP
• MS Обмен сообщениями

TODO

• https://habr.com/ru/company/itsumma/blog/416629/
• https://habr.com/ru/post/422151/
• https://habr.com/ru/post/150134/
• https://docs.microsoft.com/ru-ru/azure/architecture/guide/architecture-styles/event-driven
• pattern TODO
  • https://github.com/plantuml-stdlib/EIP-PlantUML
  • https://medium.com/@objectzen/content-enricher-pattern-in-rabbitmq-eae504a8504e
  • http://rubyamqp.info/articles/patterns_and_use_cases.html
  • https://www.enterpriseintegrationpatterns.com/patterns/messaging/MessageRoutingIntro.html
  • https://www.rabbitmq.com/tutorials/tutorial-two-python.html
  • https://blog.rnds.pro/019-poison2
  • https://alexandrugris.github.io/distributed/systems/2017/06/03/rabbitmq-patterns.html
  • https://www.cloudamqp.com/docs/delayed-messages.html
  • https://solace.com/blog/messaging-patterns-for-event-driven-microservices/
• naming
  • https://solace.com/blog/designing-and-naming-topics-for-event-driven-architecture-with-pubsub/?mkt_tok=MDcyLUNCSS05MjUAAAGDJ7N-6jFCOwXRBzE_4Ku_niXJQniSVNAJ-nNBD0JvROkzqo3tQbzDTFFx5PHlhTJj16lqF8xZCHb8IIy_29iOyZFYViJCWwpsU1X393ljZGzf&ю
  • https://docs.solace.com/Best-Practices/Topic-Architecture-Best-Practices.htm
  • https://codeopinion.com/message-naming-guidelines/
  • https://stackoverflow.com/questions/32220312/rabbitmq-amqp-best-practice-queue-topic-design-in-a-microservice-architecture
  • http://thoai-nguyen.blogspot.com/2012/05/rabbitmq-exchange-queue-name-convention.html