@xuemingdeng
2017-03-08T10:02:19.000000Z
字数 1903
阅读 472
去年年底，ThoughtWorks内部开展了一个研讨会，讨论“事件驱动”应用程序的性质。在过去的几年里，他们建立了许多基于事件的系统，有被称赞，也有被吐槽。ThoughtWorks的北美办公室组织了一次峰会，来自世界各地的ThoughtWorks高级开发人员在会上分享了他们的想法。 峰会的最大结果是得出这样的一个结论：当人们谈论“事件”时，他们实际上意味着一些完全不同的事情。 所以Martin Fowler花了很多时间试图从中挑出一些有用的模式， 本文就是对这些内容的简要总结。
事件通知（Event Notification）
事件通知是最基本也是最简单的模型。当一个系统发生了变更，它会通过发送事件消息的形式通知其他系统。发送消息的系统不要求接收消息的系统返回任何响应，即使有响应返回，它也不对其进行任何处理。这也就是所谓的“fire and forget”模式。
事件通知的好处在于它的简单性，并且有助于降低系统间的耦合性。不过，如果在一个复杂的生态系统里使用了太多的事件通知，可能会带来一些问题。太多的事件难以跟踪，发生问题难以调试，除非借助完善的实时监控系统。消息流错综复杂，当其规模开始膨胀开来，就会造成隐患。
通知事件不会包含太多的数据，一般只包含了一些ID或者链接之类的信息。对于接收消息的系统来说，如果它们想得到进一步的信息，或者要基于当前事件做出一些变更，那么它们就需要向源系统发起请求，以便获取更多的数据。那么问题来了，额外的请求不仅会造成延迟，而且一旦源系统宕机，后续的流程就无法继续进行。
事件传递状态转移（Event-Carried State Transfer）
事件传递状态转移模型比事件通知更进一步，可以看作是对事件通知的改进。这个模型最大的特点是，事件里包含了发生变更的数据。对于接收事件的系统来说，如果想要采取进一步措施，可以直接使用事件里的数据，而无需再次向源系统发起请求，从而降低了延迟。而且就算源系统宕机，也不会影响到后续的流程。
不过，既然把变更数据放在事件里进行传输，那么占用更多的带宽是不可避免的了。而且，如果有多个系统接收事件，那么这些数据就会有多个拷贝。
除此之外，接收事件的系统需要维护事件的状态，从而将原本存在于源系统的复杂性转移到了接收事件的系统上。
事件溯源（Event-Sourcing）
事件溯源的核心理念是说，在对系统的状态做出变更时，把每次变更记录为一个事件，在未来的任何时刻，都可以通过重新处理这些事件来重建系统的状态。事件存储是主要的事件来源，可以从事件存储中重建系统的状态。对于程序员来说，版本控制系统是一个最好的例子。提交日志就是事件存储，而代码工作副本就是系统状态。在某个指定的工作副本上重播提交日志就可以创建另一个工作副本，也就是重建了某个时刻的系统状态。
使用事件溯源的系统有哪些好处？首先，事件存储结构简单，易于存储，它们可以被存储在数据库里、文件系统或者其他任意的存储引擎里。因为记录事件是插入操作，没有修改也没有删除，就不需要用到事务控制，这也意味着可以避免使用锁。所以，使用事件溯源可以提升系统的性能。其次，事件本身可以充当审计日志的作用。如果不使用事件溯源，那么就需要为系统维护单独的审计日志。使用单独的审计日志就意味着有存在两个“真相源”，如果审计日志发生丢失，那么通过审计日志重建的状态与真实的系统状态会不一致。
不过，事件溯源也存在一些不足。如果事件很多，重放事件是一个耗时的过程，而且在重放过程中可能会涉及与第三方外部系统发生交互，所以需要做一些额外的操作。查询某个时刻的状态会变得很麻烦，因为需要通过重播事件来重建当时的状态。解决办法是使用快照。不过，系统没有必要为每次变更都创建快照，而是阶段性地创建快照。在查询状态时，通过在临近的快照上重放少量的事件就可以获得想要查询的状态。
CQRS
CQRS是Command Query Resposibility Segregation（命令查询职责分离）的缩写，它将读操作（查询）和写操作（增、删、改命令）进行分离，不仅让逻辑更清晰，而且可以各自进行优化。对于读多写少的系统来说，就特别适合使用CQRS，因为可以针对读性能和写性能进行优化，而且可以进行横向扩展。
不过CQRS的概念虽然简单，但是实现起来相对复杂，而且涉及到很多领域驱动设计的（DDD）概念，最好结合事件溯源一起使用。
更多资料