事件驱动架构：初级篇

点击上方“黑光技术”关注之

完美之道,不在无可增加,而在无可删减！

翻译文章一篇

原文：https://medium.com/high-alpha/event-driven-architecture-a-primer-f636395d0295

从小我就痴迷于各种系统。曾痴迷于其中一个特别系统：校车系统，它设计优雅，完美的执行，可预测的行为。

我对校车系统非常着迷，所以我在家里的地板上重复着校车的行驶。规范的学生交通系统对一个8岁的我来说非常合适，我以此就知道了世界上有各种各样的系统。有些是经过设计的，有些没有。有些比其它的好一点。但是最重要的是，系统的存在就是为了解决问题的。

比如解决这样的问题：如何每年把700个学生从他们家接送到学些182次？

每个上学日，会有三排的校车停着，并且闪着黄灯，发动机开着。铃声响起后，学生们就涌出来跑向他们每天下午上车的地方上车。

车满了之后车门就会关闭，老师会发出信号让第一个车出发，一个载满学生的黄色钢铁队伍出发开向主路，校长会切断其它交通车辆让我们的车顺利出发把孩子们送回家。

我使用这种方式来解释说明本文要说的事件驱动架构。所以我们先说一下这里面提到的几个关键组成。

• 校长作为协调者指挥交通
• 校车和线路是渠道
• 停车场和停止信号就是队列
• 学生就是事件

事件驱动架构

近年来出现的在计算机方面的几个趋势有：大数据，容器，无服务应用，微服务和事件驱动架构。因为公司知道比起单体应用来说开发一个更好管理的可扩展方案会让他们发展更快，这也让这些趋势日益风行。

公司或组织学习的是随着他们系统处理的数据在指数级增长，而传统的关系型数据库（RDBMS）无法处理这么大量的数据。信息处理需要长时间运行批处理的ETL来抽取业务关键信息。对于处理数据仓库批处理的任务来说是没问题的，但是很多公司发现他们需要实时关键信息来达到他们期望的产出。

N-Tier Architecture Example

在2000年中期，N-tier架构师那时最流行的。那时候开发的都是基于关系数据库增删改查的单体代码。组织发现他们应用的复杂性再增加并且依赖关系实际上也变得难以理解。或者是许多点对点片段的集成，这是一种脆弱的解决方式。没有人可以去责备工程师，因为毕竟是面向对象编程鼓励的复用，并且同时我也是只需要服务X访问服务Y。

更好的方式

人们开始从单体架构向微服务架构迁移。从事件处理中把业务和服务解耦降低了架构的复杂性。可以独立的开发和部署服务并且不会影响其它服务。在我看来，在开始之初这种方式是费力气的。一个微服务架构需要一个系统来支持服务和服务之间的通信

自然而然，一个事件驱动架构促进了一个完全的去中心化平台的发展。服务不必再同一个系统或事数据中心中，并且可以不属于同一个组织。如果校车系统需要增加车辆，比如说对于不同校区的课后活动，校车系统需要从其它一个或者多个系统请求增加车辆来处理额外的负载。这种灵活性允许系统按需求扩展。

拓扑

很好，你认定了一个事件驱动架构师有价值的事情。你也准备开始构建你的新平台。现在你需要决定你家架构的通用拓扑。目前有2种流行的拓扑。

协调者拓扑

如下图1所示，协调者拓扑包含了一下内容：

• 事件
• 让所有处理的事件通过的事件队列
• 一个管理事件处理顺序和渠道的协调者
• 处理业务逻辑的服务

这是一个抽象模式，所以记住你使用的队列技术类型，并且你要决定怎么来实现这个协调者（也被称为控制器或协调器）。我们使用GCP的发布/订阅作为队列服务并且使用以运行在k8s引擎和google计算引擎上的node.js微服务作为控制器。我们当时有N多个服务独立的来处理数据。

对照校车系统，想象一下一辆车需要更换刹车和加油，有人就会负责把这辆车给到为之更换刹车的技工那里。修好后，她应该通知协调者，由协调者把车给到负责换油的技工那里。

代理拓扑

在代理拓扑中，如图2所示，不像有中心化的协调者来分派事件和服务，而是服务自己订阅消息，执行他们自己的业务逻辑并且发布其它服务订阅的新消息。这种实现的一个好处是通过移除对协调者 的依赖，让系统的复杂性降低了。不好的地方就是执行顺序的协调和强制执行就没法处理了。同样这个模式不设计具体技术实现。

对照同样的校车系统，如果一辆车需要更换刹车再换油，在一个代理拓扑中个，车会被丢给更换刹车的技工，在做完之后，他再把车放在换油技工可以知道的停车场，他会把车拖进车库去换油。我认为这个例子稍微有点夸张，但是你能理解的。

性能

在一个事件驱动架构中，有两个重要的性能因素：吞吐和时延。时延越大吞吐越小。所有有两种方式来改善系统的性能：通过代码优化或者配置优化降低时延，或者通过增加额外资源来增加吞吐。

在需要测试性能时，我建议你的团队对你平台上的每个服务定义服务级别目标和服务级别指标。我们采用这种方法，这种方法不仅可以监控测量产品的成功，而且可以给我们指导，让我们通过分析基准和性能测试结果来决定未来开展的新功能。

如果你没有读过这篇文章，我强烈推荐这本又Google出版的叫做《网站可靠性工程》的书。《Site Reliability Engineering》

我从学习构建可扩展性平台中学习到一件事，就是每毫秒都很重要，1毫秒对于少量数据来说没什么关系，但是对100万条消息，每条消息增加1毫秒，那么你要额外增加15分钟的处理事件，对10亿数据，每条增加1毫秒，就要增加277小时。

每毫秒都很重要，对10亿条数据每条增加1毫秒，就要增加277小时处理时间。

以下是根据我的经验的一些建议：

• 对你要处理数据的负载要非常小心
• 对你要处理的数据负载加上限制来控制性能和费用
• 绝对不要把交易数据库作为队列来使用，特别是你要处理大数据量时。SQL类数据库时把每个交易写入交易日志。等待把数据写入交易日志会降低性能。同样从同一张表中读取写入数据时一定会加锁而导致让IO等待急剧增加。
• 有两种日期会影响一个事件驱动系统：事件的实际事件和处理事件。事件的时间事件是用户或者系统动作发生的时间。处理事件通常是事件被系统读取处理的事件。这个区别是很重要的，因为你的架构如果使用了窗口处理逻辑的话就要管理未来进入的事件。

最后一点，想象一下校长要向统计一下当天到校的所有学生人数。她花了20分钟等所有的校车都到了，最后统计出620个学生。那他就停止统计。窗口关闭了，但是有一辆车应为交通灯的问题迟到了10分钟。校长就要再回头把这另外的80上加上去。这有点像出现你们系统中的对账。

长柄大锤综合症

最后，事件驱动架构不是针对所有应用的银弹。相反这样的模式有它的的复杂之处。

可不要陷入长柄大锤综合症

事件驱动架构对于只需要你一个螺丝刀的问题就非常像一个长柄大锤。所以你要首先算算你的开发维护成本再来决定着是不是一个对你合适的解决方案。

在考虑方案的复杂性和是否值得你投入时，考虑一下如何处理下面的问题：

1. 服务抽象的准确级别是什么
2. 你有事件消息定义还是没有
3. 你的系统如何处理错乱的数据，放入服务还是队列
4. 你怎么处理吵闹邻居问题（硬件共享问题）
5. 在系统中你是怎么调试和理解事件流的
6. 如何处理非幂等数据
7. 系统如检测和何避免环处理和
8. 对分布式事务回滚如何处理

结论

总结起来EDA就是

• 高扩展能力和去中心化的
• 可以处理事件和执行函数，例如对收取数据时进行聚合，
• 消除了点到点的集成

以下情况可以考虑使用EDA：

• 你需要一个低延时大数据量的处理
• 你需要在窗口事件内对实时数据聚合或者处理
• 多个服务需要处理同一个事件
• 你需要水平扩张一个分布式系统
• 你需要实现一个微服务架构

看完本文有收获？请分享给更多人

关注「黑光技术」加星标，关注大数据+微服务