前面我们介绍了发布订阅的架构设计方式，本文在此基础上，继续讨论关于事件驱动系统的相关内容。
概念介绍
事件驱动系统，本质上就是在微服务架构的基础上，依托于消息队列，通过发布和订阅的方式组织的系统。消息在这里称为事件（event），发布者称为生产者（publisher），订阅者称为消费者（consumer）。最常见的事件驱动系统是git，通过例如commit的事件驱动所有的服务。下图是一个事件驱动系统的架构图。
应用场景
为什么要设计事件驱动系统呢？我们举一个例子，假如有一款射击游戏，有两个玩家，在某一时刻，玩家A向玩家B所在的位置射击，比如位置9，此时玩家B正好在位置9，应该是可以击中的。如果系统是采用请求响应的方式设计的，玩家A向服务器发送一个请求，服务器在接收到这个请求时，玩家B已经移动到了位置10，因此服务器判断玩家A未击中玩家B，结果是错误的。
如果用事件驱动的方式设计，将所有的设计和移动都作为事件发送给服务器，并记录事件发生的时间点。那在玩家A向服务器发送射击事件时，服务器会回溯到玩家A发送请求的时间点，获取当时玩家B的位置，并判断射击是否命中，这样结果就是准确的了。
事件保存
在事件驱动系统中，最好在每个服务自身的数据库中记录所有的事件。这并不是一个必须的做法，但如果这样做的话，会使得每个服务对于事件的持久化要求，可以不依赖Event Bus。每个服务记录的事件，可以结合服务的实际情况添加或者减少一些字段。我们介绍一下这种实现的优缺点。
-
优点：
- 提高可用性：服务本身记录了事件，可以载不依赖其他服务的情况下处理这些事件。
- 易回滚：当服务出错修改后，可以从服务记录的事件中的任何一个重新处理这些事件。
- 方便服务替换：如果用另一个服务替换已有的服务，可以在新服务上重新处理本地保存的所有事件，然后再从Event Bus接收新的事件，就完成了新服务的上线。
- 事务性：发送到Event Bus的消息可以提供两种语义保证，At-least-once和At-most-once。
- 记录意图：可以记录每个事件在服务中的变化，在开发新服务时，可以据此实现与之前不同的功能。
-
缺点：
- 数据一致性：将事件记录在本地的问题就是数据可能出现不一致的状态。
- 网关服务不能替换：网关上的服务会处理和外界的请求和响应，这可能是和当时请求的时间点有关的，因此不能像之前介绍的替换服务那样，替换网关的服务。
- 可控性差：由于每个服务处理自己的事件，难以跟踪一次请求的全部执行过程。
- 处理过程不透明：每个服务之间没有直接的联系，将不容易理解一个请求的整体处理过程。
- 权限控制：使用Event Bus的话，无法控制有哪些服务会使用这些事件；或者如果服务只允许获取部分事件，也是需要进行额外控制的。
- 不好移植：如果想把事件驱动系统，移植到请求响应的系统中是很复杂的。
再提一下服务如何回到过去某个事件时的状态，可以采用的方法有：
- 回到开始事件并依此处理直到该事件。如果事件的数量特别多，这个方法是不太现实的。
- 记录开始事件，以及后续事件的变化。可以减少事件的存储量。执行方式和上面的方法相同。
- 记录每个事件撤回到前一个时间的撤销操作，对于一些计算事件是可行的，但比如发邮件这种事件是无法撤回的。
一种解决方案是周期性的将事件进行压缩，比如每天或者每两天，然后记录当时处理完成的状态。这样在想回到某个事件的状态时，就可以查找最近的压缩过的状态，然后再使用前两种方法。
小结
事件驱动系统可以理解为是发布订阅模式的应用，通过在每个服务内部记录事件日志的方式，解决了服务难以回溯历史事件的问题。事件驱动系统的优点和缺点都比较突出，可以按实际需求选择是否应用。
欢迎大家订阅专题，其中包含了系统设计基础系列的全部文章：System Design
