事件驱动架构

为何要引入事件驱动架构(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机制流转事件的)