咱们在探讨微服务时，通常避不开服务的颗粒度和服务之间的松耦合。也就是说服务应该是可能自治的，可能掌控服务所有的依赖，并且尽量升高同步通信的频率。明天咱们来探讨一下实现分布式服务松耦合的事件驱动架构模式，以及异构语言零碎如何实现事件驱动架构设计。

事件驱动架构

事件驱动架构（EDA）是一个提倡在散布式微服务零碎中应用事件生产和生产的软件架构范式。一个事件代表一个具备重大影响的行为，一个事件产生通常意味着一个实体的创立或者状态产生变更，例如电商零碎中创立一笔订单或者订单状态发生变化。

对于事件的特别之处在于他们没有显示的与可能关怀他们是否产生的服务间接产生通信。事件就是“仅仅产生过”而已，而不会去思考是否有特定的服务对他们的产生感兴趣，这也正是事件弱小的起因——事件转换为自蕴含的一条记录，从根本上与他们的处理程序解耦。事实上，事件的生产者通常不晓得谁是事件的消费者，或者消费者可能基本就不存在。
事件须要作为记录被长久化，一条记录应该蕴含形容一个事件所有必要的信息，事件的生产者应该确保潜在的消费者可能获取到处理事件须要的所有数据。

如上图所示，实现事件驱动架构有四个次要组件：

  • 事件生产者：开始整个工作流的初始事件发布者。
  • 事件代理：代理保护一个channel/queue/topic来公布事件。
  • 事件消费者：事件记录音讯的订阅者，并依据事件来执行特定行为。
  • 处理事件：让整个零碎通晓事件消费者在生产事件之后而采取行为所带来的影响，这通常是另一个工作流的初始事件。

通过异步和通用解耦

耦合其实就是一个组件受其余组件影响的水平，耦合有两个维度：空间维度——组件在结构上相干；工夫维度——他们的关系受工夫影响的水平，例如，同步调用一个REST API。如果两个服务必须同时可操作，那么它们之间存在肯定水平的工夫耦合。如果组件之间存在很强的互相依赖性，咱们就称它们为紧耦合，否则就称它们为松耦合。

那么，EDA如何克制耦合？

  1. 事件不是通信，他们仅仅是产生而已。组件产生了一个事件并公布一条记录，而不关怀事件的生产组件是否存在。因而，如果消费者不可用，也不会影响到生产者。
  2. 在代理上事件记录的持久性在很大水平上打消了工夫的概念。生产者在T1公布了一个事件，消费者可能在T2读到这条音讯，至于T1和T2之间的工夫窗口可大可小。

然而EDA并没有齐全打消耦合，事件代理对于生产者和消费者解耦都是至关重要的，他们必须依赖一个代理来实现信息传递，这也减少了零碎架构的复杂性，并引入了一个新的故障点。这就是为什么要求代理必须具备高性能和高容错能力的起因。

事件的类型

  1. 事件告诉。该类型的事件通常在一个组件发送事件音讯告诉其余的组件在各自畛域内产生变更时应用。事件告诉的关键因素就是事件起源组件不关怀告诉音讯的响应。
  2. 事件溯源。事件溯源的核心思想是当组件状态发生变化时，组件将状态变更记录为一个事件，并且咱们能够在将来的任何时候通过从新处理事件来重建零碎状态。事件存储成为假相的次要起源，组件状态纯正从它派生而来，例如版本控制系统。
  3. 携带状态的事件传输。当事件的消费者组件状态变更不须要申请生产者组件以获取数据时，能够应用这种模式。事件记录蕴含了所有必要的数据。

事件处理的模式

事件处理通常有三种格调的定义，这三种实现格调在很大水平上并不是互斥的，在一个大型事件驱动零碎中通常是相互合作独特发挥作用的。

离散事件处理
离散事件处理的特色是通常事件之间彼此是互相独立不相干的，能够被独立解决。例如，订单领取后物流发货和赠送积分。

事件流解决
对无边界的相干事件流解决，事件记录依照肯定程序被公布和解决。消费者能够依照生产者规定的程序处理事件记录并在本地数据库中保留一个实体的正本。离散地解决这些更改记录不会缩小它，因为程序很重要。多个消费者还须要留神资源竞争，因为在这种状况下可能产生多个消费者试图并发地批改数据库中同一条记录，因为无序更新导致数据不统一。
能够借助Kafka之类的事件流平台来放弃实体更新的程序，Kafka的程序队列通过数据键值和partition来保障一组音讯在同一个队列中的程序，从而解决资源竞争问题。

复合事件处理
复合事件处理是从一组简略事件标识的复合事件模式。这种解决形式通常更简单，要求事件处理器跟踪先前的事件并提供查问和聚合这些事件的办法。假如咱们有一个服务弹性扩容事件，扩容条件是CPU使用率大于80%并且内存使用率大于85%，那么扩容事件就能够定义为由CPU使用率高于80%警报和内存使用率高于85%警报两个简略事件标识的复合事件。

EDA的劣势

  1. 缓冲和高容错。
  2. 事件生产者和消费者解耦，防止了广泛的点到点故障。
  3. 高可伸缩性。无论是代理的规模还是消费者的数量，都具备很高的可伸缩性。

EDA的毛病

  1. 仅限于异步解决。
  2. 为零碎引入了额定的复杂度——代理。
  3. 故障屏蔽——不像紧耦合零碎那样可能疾速间接地获取零碎里各组件的故障，尽管有时这个故障的影响是很重大的。松耦合零碎尽量避免一个组件的故障对其余组件的稳定性带来影响，然而有时候这也覆盖了本应该及时引起咱们留神的问题。通常须要依附各个组件的监控和日志来解决，但这又减少了复杂性。
  4. 在设计事件时，首先须要思考跨零碎的事件回滚，这将减少数据库的复杂性。

什么时候应用EDA

  1. 不通明生产的零碎。生产者通常不晓得消费者的状况。后者甚至可能是短暂的过程，可能在短时间内呈现和隐没!
  2. 高扇出。一个事件可能由多个不同的消费者解决的场景。
  3. 简单的模式匹配。将简略事件串在一起以推断出更简单的事件。
  4. 命令-查问责任拆散。CQRS是一种拆散数据存储的读取和更新操作的模式。实现CQRS能够进步应用程序的可伸缩性和弹性，但须要在一致性方面进行一些衡量。此模式通常与EDA相关联。

Commond和Event

Commond，其目标是在特定的边界内调用与业务逻辑相干的行为,Commond只有一个消费者，表述动作行将产生然而还未产生。相较于事件驱动的异步解决模式，Commond通常是通过REST API来实现的同步调用。
事件是对曾经产生的事件的纯正形容，它没有规定应该如何处理事件。而Commond是指向特定组件的间接指令。因为Commond和事件都是某种类型的音讯，所以很容易混同，将指令谬误地示意为事件。
通常在组件数量比拟少，与其余组件通信也比拟少的状况下，事件驱动还是比拟可控的，然而随着组件或者微服务的数量越来越多，难度也会随之减少。如果咱们不通过粗疏的设计，全程应用命令驱动将会带来不必要的耦合。同样如果全程应用事件驱动，不仅会减少开发难度和业务边界不清晰，而且也有可能设计出一个紧耦合的服务，导致建设一个分布式单体服务，这将比一个纯正的单体服务更蹩脚。
Commond和Event的抉择应该依据理论应用场景灵便抉择，如果消费者是业务逻辑”执行“的一部分，则应该应用Common模式；如果消费者是业务逻辑执行后的”告诉“局部，则比拟适宜Event。

异构语言零碎的事件驱动设计

异构语言零碎实现实现事件驱动设计，面临着诸多挑战

  1. 反复工作。无论事件记录的公布、生产，事件记录的长久化，还是事件代理组件的对接，可能不同语言服务都要反复开发一次。这不仅大大增加工作量，而且还会为零碎整体品质带来了很多不确定性，毕竟康威定律在微服务畛域还是有实际意义的。
  2. 组件抉择的限度。尽管各个云平台对于存储和stream服务都尽可能全面地提供规范API和通用SDK。然而因为语言个性的差别，不可避免在技术选型上有所限度。
  3. 可移植性。无论是运行云平台的迁徙，还是组件的迁徙，都是一个微小而又冒险的工作。零碎的可移植性很大水平上依赖引入组件的可移植性。
  4. 配置信息管理。大规模分布式服务中，配置管理自身就是一个麻烦事。

那么有没有更优雅一些的形式，为事件驱动设计的落地提供助力。

对于Dapr（分布式应用运行时）

Dapr是由微软开源的一个可移植的、事件驱动的分布式运行时框架。Dapr除了自托管运行模式外，还能够运行在kuberneets云原生平台上，以边车模式为应用服务提供多种代理模式。在kuberneets对分布式服务资源形象的根底上，Dapr实现了分布式服务能力形象的跃迁，它能够使开发人员从简单根底服务组件的治理中解放出来，更专一于畛域业务逻辑的开发，轻松构建出弹性的、无状态和有状态、可迁徙的应用程序。上帝的归上帝，凯撒的归凯撒。对Dapr感兴趣的同学，能够去Dapr官网上理解更具体的信息。

为什么Dapr

Dapr通过凋谢、灵便、独立的构建块，将服务调用、输入输出绑定、状态存储、公布订阅和配置管理等能力形象为规范API，API反对http和grpc两种通信协定。因为Dapr是可移植和跨平台的，开发者就可能用他们喜爱的语言和框架来构建可移植的应用程序。

公布订阅
Dapr提供了一个可扩大的Pub/Sub服务（保障音讯至多生产一次），容许开发者公布和订阅主题。 Dapr为Pub/Sub提供各种实现组件，使操作者可能应用他们所喜爱的基础设施，例如 Redis Streams 和 Kafka等。从而实现了应用程序和基础设施的解耦，应用程序只须要接入Dapr SDK，而不须要对接每个组件。对于开发的工作量和复杂度、标准束缚的执行都会带来很多便当。并且底层组件的保护、降级甚至是迁徙，对于应用服务来说，将不再是累赘。

例如，java我的项目接入Dapr

  1. 在pom文件中引入Dapr sdk
<dependency>    <groupId>io.dapr</groupId>    <artifactId>dapr-sdk</artifactId>    <version>1.6.0</version></dependency>
  1. 公布事件记录
    try (DaprClient client = new DaprClientBuilder().build()) {      for (int i = 0; i < NUM_MESSAGES; i++) {        String message = String.format("This is message #%d", i);        client.publishEvent(            "messagebus",            "testingtopic",            message,            singletonMap(Metadata.TTL_IN_SECONDS, MESSAGE_TTL_IN_SECONDS)).block();        System.out.println("Published message: " + message);        try {          Thread.sleep((long) (1000 * Math.random()));        } catch (InterruptedException e) {          e.printStackTrace();          Thread.currentThread().interrupt();          return;        }      }
  1. 订阅事件记录
  @Topic(name = "testingtopic", pubsubName = "messagebus")  @PostMapping(path = "/testingtopic")  public Mono<Void> handleMessage(@RequestBody(required = false) CloudEvent<String> cloudEvent) {    return Mono.fromRunnable(() -> {      try {        System.out.println("Subscriber got: " + cloudEvent.getData());        System.out.println("Subscriber got: " + OBJECT_MAPPER.writeValueAsString(cloudEvent));      } catch (Exception e) {        throw new RuntimeException(e);      }    });  }

就这么简略的几行代码，就实现了一个分布式事件的生产者和消费者，至于底层反对服务能力的组件是redis、是kafka 还是本地存储，对于应用服务齐全是通明的，治理和配置的工作都交给Dapr来实现。
Dapr的configuration API和服务调用API的实现复杂度，也跟公布订阅根本相当。大家能够参研一下SDK 官网文档。

将来，Dapr还会公布工作流组件，置信会为事件驱动架构提供更多抉择。