开发者学堂课程【事件总线 EventBridge 生态集成课程： EventBridge EDA (事件驱动):架构场景实践】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1235/detail/18407
EventBridge EDA (事件驱动)：架构场景实践
3.EDA 架构实现解析
下面简单看一下 EDA 现在的实现架构的解析，会发现一个问题，它中间是有一个环节，然后这块是事件生产者，可能会有很多生产者，然后同时发布给 eventbus 或者叫 EDA 架构 broker 的底层，这个底层它可能需要具备几个能力。
第一个能力是事件捕获。即一定有一些能力可以把事件拉到 bus 层。这样之前谈的架构才会有可能性。
第二个能力是路由能力，即这个东西发送给你之后，你一定要向下去fill out 的能力。这个事件是要做最大的，可能要去针对下游端做一些更精细化或者是更精确的路由。这是路由能力，即传统的 fill out。
下面叫事件的处理能力，可以在上图看到，包括中间节点，包括转发逻辑，包括订单变更，包括状态变更，所有理论基础都是建立在 bus 一定是有处理能力的，即 bus 应该是挑出来哪个事件下发到哪个端。是真的去理解这个事件里面的东西到底是什么然后才能做下游端的转发。这是事件的处理能力，bus 一定要理解事件，并且可以把事件准确地交付给下游,这是现在 EDA 架构的实现解析。
每一块儿拆起来都非常复杂。尤其是最后一个事件处理。事件处理有很多 message，消息文件没法去满足的。因为非常定制化的这种录由方案，没法去满足事件处理的诉求。因为事件是无时不在的，没法去申明东西,这个事发送过来后可以去路由，这是事件和消息的另一个显著区别,现在其实很多 message 没有事情处理，过滤一些能力。这是 EDA 架构的解析。
3. EDA 架构优势/劣势
优势：
（1）松耦合
事件驱动架构是高度松耦合且高度分布式的架构模型，事件的创建者（来源）只知道发生的事件，并不知道事件的处理方式，也关心有多少相关方订阅该事件。
（2）异步执行
EDA 架构是异步场景下最适合的执行工具，我们可以将需要事件保留在队列中，直到状态正常后执行。
（3）可扩展性
事件驱动架构可以通过路由＆过滤能力快速划分服务，提供更便捷的扩展与路由分发。
（4）敏捷性
事件驱动架构可以通过将事件分发至任何地方，提供更敏捷高效的部署方案。
劣势：
（1）架构复杂
事件驱动架构复杂，路由节点多，系统结成复杂，功能要求多。
（2）路由分发难
事件路由及分发难，灵活的事件路由需要依赖强大的实时计算能力，对整体分发系统要求较高。
（3）无法追踪
事件追踪是整个 EDA 架构保证， EDA 架构中往往很难追踪到事件处理状态，需要大量的定制化开发。
（4）可靠性差
事件驱动由于需要多系统集成，可靠性通常较差，且交付无法保障。
再看一下优劣，有优势就一定有劣势。首先来看优势，因为这讲主要是以 EDA 架构的优势为主。
（1）EDA 架构，第一个优势是松耦合。比如 A 端和 B 端，中间有中间节点把它们调节起来，这样它的 A 端 B 端的操作，B 端不用依赖 A 端服务的稳定性，A 端也不用依赖 B 端服务的稳定性，只要管好自己是不是可以正常发到 bus 上面。这就是松耦合，很简单。
（2）异步执行，其实 EDA 架构是义步执行下最合适的一个执行工具，所以异步执行也一定是 EDA 的优势，它可以将事件保留在队列中，直到下游正常再做执行，这和松耦合互相相辅相成。
（3）可扩展性，事件驱动里面最大的好处或者最大的应用性在于它可扩展。即这个事件发送到总线上不只有固定的端可以接受事件，而是后续的所有系统都可以依赖 bus 来做下游的处理。这是现在很多系统没法满足的一点，因为它得快速做事件的接收。
（4）敏捷性是它可以把事件下发给任何地方，然后提供更高效的部署方案或者系统对接，它最大的特点在于事件是可以打破系统孤岛的。系统孤岛怎么理解呢？在 HR 系统里面会发现很简单的一点，即 HR 系统可能要跟财务系统、仓储系统，甚至是可能要跟其它的 HR 的一些招聘系统做 match。那对接的时候会发现每一个对接、每一个小系统都是一个孤岛，可以通过事件把孤岛给打通掉，比如 HR 可以发送给任何部门，任何部门事件也可以下发给 HR 部门。所以这是显著的一个优势。
劣势也比较明显，从刚刚的架构分析，包括架构图，可以总结出几点。（1）第一点是 EDA 架构架构起来特别复杂，节点多，复杂多，系统集成复杂多，功能要求多。其实之前那张图已经讲得非常明确了，它确实是非常复杂，像蜘蛛网一样，有一个中间节点把各个蜘蛛网连起来。所以它的架构一定是非常复杂的。而且它的路由节点也非常多，路由起来也会比较困难，如果自建，这套系统基本上可以完成，但代价会非常高。
（2）路由分发难这个问题需要有一些计算能力，对整体分发的系统的稳定性要求会特别高。
（3）无法追踪是整个EDA 架构的老大难问题。它可能需要 trace ID。从源端到目标端都可以采到 trace ID，然后把 trace ID 连接起来做事件的跟踪，一般情况下，接入成本也是非常高的。
（4）其次，可靠性差，因为它要跟很多系统做集成，通常情况下，基本上如果只是开发系统，可能只开发一两个系统，但要对那么多系统集成，交付和可能都没保证。
这是优势和劣势，针对于这些劣势，阿里也推出了一款产品，现在开始讲产品做的一些东西，即 eventbridge。
5.EventBridge 组件支持
Eventbridge 其实很好的把前面的一些架构复杂，路由难，无法追踪，可靠性差等问题给解决掉。首先，它是现在阿里云整体的事件生态的集成工具，可以理解为阿里云现在所有的云产品事件的底层全都是依赖 eventbridge 完成的，比如 ACS 是依赖 eventbridge 这个中间节点完成的，所以会发现有很多阿里云的服务在 eventbridge 上面有接入。
其次它可以有效地解决追踪难的问题，即事件处理，可能会对事件过滤、转换、追踪、接入防控制流量，目标接入可能会有目标类型注册，目标管理。工具链会非常成熟，基本公司应用注册。比如解决上下游部门间的通信或业务对接问题，可以直接通过 skima 解决，注册一个 skima，然后直接把 skima 交付给下游系统。
其次，事件分析能力，把事件采集到之后，也可以对事件做一些分析，然后查询能力可以根据事件 ID 查询到事件的整体的状态变更是怎样的。事件仪表盘是直接针对于云产品的，有一个非常强劲的事件仪表盘可以把现在全部的云事件做一个压缩包，告诉大家这个账号下面发生了哪些事件，仪表盘后续也会考虑支持自建的系统的展示。这是 eventbridge 的整体介绍。
四、事件驱动架构实施
下面会讲到比较关键的点，即事件驱动架构的实施。
动手实践：配置 HR 新员工工作流
依然以配置 HR 新员工工作流程为例，在这里会给大家演示一下，在 eventbridge 控制台怎么可以把新员工工作流完整地串起来。当然大家也可以跟着操作，或者看一下它的一些主要分工，包括流程是怎样的。首先，发现 HR 系统有三块。第一块是事件源，即发送事件的一方。第二块是 eventbus，这是产品的主体。然后第三块是路由分发的一些目标端，一步一步配置。首先看一下事件源，得给大家详细讲一下。
1.动手实践：配置事件源
事件源可以分为三块，第一块叫 web hook 接入，web hook 接入适用于什么场景呢？可以给大家讲一下什么情况下会用到 web hook。首先，看 HR系统，通常情况下，会发现在实际应用中，会把一些 HR 系统用一些 saas 解决方案，会发现一搜 HR,有很多 HR 的系统或者 SAAS软件。
比如随便找一篇文章，大家可以看。
