前两天讲软件体系结构风格中的事件驱动风格，偶有所得。
事件驱动风格中的组件一般包括：事件发布者，事件处理者。有些系统还有独立的事件分派模块。事件处理者一般会在事件分派模块处注册或者直接向事件发布者注册，注册后，事件发布时，事件处理者便会及时收到事件发布者所发布的事件，并作出响应和处理。
这样的体系结构风格的特点是：1）事件的发布者并不知道哪些构件会被这些事件影响，组件之间相互保持独立。2）这样不能假定构件的 处理顺序，甚至不知道哪些过程会被调用；3）各个构件之间彼此无直接的连接关系，各自独立存在，通过对事件的发布和注册实现关联。
这种体系结构风格的好处是：1）事件发布者不需要知道哪些组件会影响事件，组件之间关联较弱。一个组件出错将不会影响其他构件。2）提高软件复用能力。只要在系统事件中注册组件的过程，就可以将该组件集成到系统中。3）系统便于升级。只要组件名和事件中所注册的过程名保持不变，原有组件就可以被新组件替代。
这种体系结构风格的坏处是：1）组件放弃了对计算的控制权，完全由系统来决定。2）存在数据交换问题。3）该风格中，正确性验证成为一个问题。
事件驱动风格的典型应用之一就是像新闻推送，公众号推送等。联系到我们的生活，如果把人当做终端的一份子的话，那么我们就组成了一个巨大的事件驱动风格的系统。每天我们会收到注册的公号的推送，新闻的推送，这是发布-订阅式的结构；我们还会收到朋友的微信留言，这可以看做是点到点（基于队列）的结构。
事件驱动风格系统中的组件对计算是没有控制权的。事件发布者无法控制事件处理者的处理，何时处理，怎么处理，何时回应，是否回应，这都由事件处理者说了算，事件发布出去之后发布者就只能等待。这时想到有时联系不上某人，就在群里大喊：谁能帮我喊一下xxx，有急事找，不由莞尔。而事件的处理者只要没有宕机，遇到事件的召唤，就一定会即刻作出响应，因此我们常说现在好难专注，一边工作还得一边注意微信，一旦有消息还得及时回复。有时候上一堂课下来，微信里的红点点就排队了。这就是事件驱动风格的系统缺陷。系统缺陷就意味着只要你在这个系统中，就不可避免。所以所谓的提高专注度的若干种方法都是伪命题，在事件驱动系统中，无可避免你必须分出一个线程关注事件是否发生，一旦发生就得处理。要想改变，只有从事件驱动系统中脱离出来，但人脱离出来容易，神脱离出来不易，习惯性竖起耳朵就不在本文讨论范围内了，：P。
事件驱动风格系统中的数据传递是采用消息进行传递，尤其在具有独立调度模块的事件系统中，数据则需要经过调度模块的传递。在这些情况下，全局性能和资源管理成为了系统的瓶颈。如果联系到我们的推送系统，我们还会发现，各种事件产生的消息往往都是碎片化的，很难将一个知识体系装进一个消息里进行传递，所以想通过订阅号来系统学习也是一个伪命题。我们可以学到一个个知识点，但很难构成体系。最好的解决办法就是建立自己的知识体系，将这些碎片知识挂到自己的知识树上去。
事件驱动风格中，正确性验证成为一个问题。因为发布事件的过程的具体含义与事件激发的上下文有关。而当接收方收到消息时，往往丢失了上下文信息，无法验证消息的正确性。因此，本就不应该由消息的接收方来验证消息的正确性，而是应该由事件分发者甚至是第三方来进行消息过滤。
