事件驱动架构（W5 总结)

什么是时间驱动架构

一般的分布式系统中，系统模块之间，子系统直接，跨系统直接的集成通讯方式以RPC方式来实现的，通常的RPC接口实现技术包括：

1. HTTP/restful

2. TCP/dubbo

3. http2/gRPC



RPC的集成方式特点：

1. 通常是C/S模式，调查者明确了解被调用者，它们通过协商好一致的接口来调用过程。

2. 大部分是request/response的模式，也有部分是一个request 多个response的模式。

3. Server（被调用者）要先于调用者启动。

4. 调用者与被调用者一般是同步模型。



RPC方式的不足：

1. 设计过程是先设计Server端，在设计Client端；两端耦合性强。

2. 运行过程client端强依赖于Server端，Server端停机或者未启动，Client不能运行。

3. Client的压力直接作用与Server端。

4. 难以实现一个Client与多个Server端的模型。



事件驱动架构的引入，弥补了RPC架构的不足。事件驱动模型

1. 在Client与Server之间引入了一个消息中间件，client与server的集成分成了两段过程, 即client -- message middleware 与 middleware -- Server;

2. Client与Server之间通讯不再关注方法(Function)，转而设计消息。

3. 设计重点转变为设计Client与Server的消息格式和消息路由，Client与Server都是对于消息的处理过程。

4. Client端与Server端的压力不直接传递，消息中间件负担Client的压力。由于消息中间的功能单一，可以实现很高的压力负载。

5. Server对Client不可见，只要消息中间件启动，Client 与Server可以分别启动、运行。

6. 一个消息可以有多个Server来处理。



由于事件驱动架构与RPC架构的差异，在事件驱动架构中，将消息生产者称作Provider, 消息消费者叫做Consumer. 常见的消息中间件包括：

RabbitMQ： erlang实现，支持AMPQ协议。

ActiveMQ：java实现的，支持AUTO，OpenWire，AMQP，Stomp，MQTT等多种协议。

RocketMQ: 私有协议

Kafka: scala实现私有协议

Redis: redis pub/sub协议



大规模应用主要关注RocketMQ与Kafka。



引入事件驱动架构通常用来解决一些问题：

1. 系统间解耦

2. 用户访问流量的削峰填谷。

3. 一对多的系统通讯过程。

4. 大量数据实时在系统间传递。



事件驱动架构要关注的技术要点：

1. 消息中间件的吞吐率、消息延迟，消息缓存时间，消息可靠性。

2. 消息传输与处理保障的三种模式：exactly once / at least once / at most once. 通常关注at least once 与 exactly once.

3. 双向通讯的过程比RPC复杂很多。

4. 事件驱动架构尽量避免分布式事务，以提高系统处理能力。



总结:

事件驱动架构不是万能的，根据场景选择；

事件驱动架构不一定能提高系统的吞吐率，反而带来系统复杂度提高；