事件驱动架构

为何要引入事件驱动架构(Event-Driven Architecture)

  • 解耦合：事件驱动架构是高度松耦合且高度分布式的架构模型，事件的创建者（来源）只知道发生的事件，并不知道事件的处理方式，也不关心有多少相关方订阅该事件。解耦合在微服务中只需要单次调用其他微服务，剩余的微服务调用只需要通过事件总线bus执行即可。
  • 异步执行：EDA 架构是异步场景下最适合的执行工具，我们可以将需要事件保留在队列中，直到状态正常后执行。
  • 可扩展性：事件驱动架构可以通过路由&过滤能力快速划分服务，提供更便捷的扩展与路由分发。
  • 敏捷性：事件驱动架构可以通过将事件分发至任何地方，提供更敏捷高效的部署方案。

事件驱动架构重点的地方在于哪里

  • For Event Capturing（事件收集）：具备采集事件的能力
  • For Routing（事件路由）：通过事件内容将事件路由分发至于下游的能力的（交给Pulsar处理）
  • For Event Processing（事件过滤/替换）：对事件进行脱敏或初步过滤&筛选的能力（哪些事件需要执行，哪些事件需要丢弃，哪些事件的数据需要脱敏）

事件驱动架构的劣势

  • 架构复杂：事件驱动架构复杂，路由节点多，系统结成复杂，功能要求多。（比较吃运维能力）
  • 路由分发难：事件路由及分发难，灵活的事件路由需要依赖强大的实时计算能力，对整体分发系统要求较高。（交给Pulsar处理）
  • 无法追踪：事件追踪是整个 EDA 架构保证，EDA 架构中往往很难追踪到事件处理状态，需要大量的定制化开发。（内在解决方法：Pulsar支持查看发送事件流; 外在解决方法：接入es）
  • 可靠性差：事件驱动由于需要多系统集成，可靠性通常较差，且交付无法保障。（Pulsar客户端API支持 java、go、python和c++）

为何使用Pulsar作为消息队列

  • 主要原因：云原生分布式消息系统，天然支持k8s，这是其他消息队列所无法实现的。

  • 次要原因：当k8s里伸缩时（多pod），其他消息队列无法支持多发送，多接受，且多Pod的负载均衡（pulsar的原理是通过Zookeeper机制流转事件的）