什么是实现松耦合系统架构的神器？

什么是事件？
　　根据百科的定义，事件是比较重大、对一定的人群会产生一定影响的事情。那么对于一个软件系统来说，事件就是系统中发生的某个变化，可能是一个数据发生了变化，也可能是某个命令被触发了。
　　在软件系统架构中，对事件最常见的应用场景就是事件通知。
　　当领域内有变化发生时，发送事件消息来通知其它系统。事件通知的一个关键点是源系统并不关心外部系统的响应。通常它根本不期待任何结果，即使有也是间接的。发送事件的逻辑流与响应该事件的逻辑流之间会有显著的隔离。
　　事件通知非常有用，因为它意味着低耦合，并且结构也非常简单。但是，当逻辑处理流跨越各种事件通知时，它也可能成为问题。因为没有任何代码显式地描述这个流程，所以这个流程是不可见的。通常，唯一的办法是通过监控系统来观察它。这会导致调试和修改流程变得很困难。
　　事件不需要包含太多数据，通常只有一些ID信息和一个指向发送方、可供查询更多信息的链接。接收方知道它已发生变化，并且接收到关于变化的最少信息，随后会向发送方发出请求，以决定下一步该做什么。
　　第二种模式是携带状态转移的事件，采用此模式时，可以在不需要访问源系统的情况下，更新客户端的信息。例如客户管理系统可能在客户修改自己的详细信息（如地址）时抛出事件，事件包含了详细的修改数据。因此，接收方无需与客户管理系统通信，就可以更新自己的客户数据副本，以进行下一步的操作。
　　这种模式的优点是我们获得了更好的弹性，因为即使客户管理系统不可用时，接收方系统仍然可以正常工作。我们减少了延迟，因为访问客户信息不需要远程调用。我们也不必担心所有来自消费端的查询给客户管理系统带来的负载。
　　还有一个应用事件的模式是事件溯源，事件溯源（Event Sourcing）的核心思想是，每当系统状态发生变化时，都将状态更改记录为事件，这样我们就有信心在任何时间都能够通过重新处理事件来重建系统状态。事件库成为事实的主要来源，系统状态完全来源于它。对于程序员来说，最好的例子就是版本控制系统。所有的提交日志就是事件库，源码树的工作副本是系统状态。考虑一下版本控制系统带来的价值，就很容易明白事件源有许多有趣的收益。事件日志提供了强大的审计功能（账户交易是帐户余额的事件源）。我们可以重放事件日志到某个点来重新创建历史状态。在重放时注入假设事件可以探索不一样的历史。
　　最后一个使用事件的架构模式是CQRS，命令查询职责分离（CQRS）是指读取和写入分别拥有单独的数据结构。严格地说，CQRS跟事件没有关系，因为你完全不需要任何事件就可以使用CQRS.但通常人们会将CQRS与之前的事件驱动模式结合起来。
　　使用CQRS的理由是，在复杂领域中，使用单一模型处理读取和写入过于复杂，我们可以通过分离模型来简化。当访问模式有区别时（例如大量读取和非常少的写入），这一点尤其具有吸引力。但是，需要注意平衡CQRS的收益和分离模型所带来的额外复杂度。
　　综上所诉，应用事件的场景基本上有这四种：把事件作为消息通知、带有状态转移的事件作为业务驱动、基于事件库的事件溯源、基于事件驱动的CQRS架构。
　　那么，进入正题。业务中台的事件中心，能支持哪几个场景呢？支撑日均500万事件分发量的事件中心又是如何保证高性能？
　　首先看一下事件中心的应用架构：

　　事件中心包含两大块：事件引擎和事件管理。事件管理功能又包括事件类型、事件源注册，监听器注册，事件查询，看板，本地事件管理。事件引擎包括事件接受服务，事件消费服务，事件重试服务，以及事件库。
　　事件中心支持的特性包括：
　　·支持可靠事件发布，保证事件不丢失。
　　·支持大并发下处理效率。
　　·支持限流功能，保证订阅者服务的安全可控。
　　·支持事件库持久化，能够基于历史事件进行事件的管理和跟踪查询。
　　·支持开发配置界面进行事件类型注册和监听器注册。
　　为保证可靠事件，以及大并发场景下的高性能，事件中心的技术架构：
　　

通过本地部署EOS服务来实现本地可靠事件，保证事件不丢。
　　同时按照监听者动态分配消息队列，能支持大并发下保持较高性能。从微服务部署形态上看，事件中心拆为了事件中心管理微服务，接受事件微服务，消费事件微服务，重试微服务，以更小的粒度进行服务实例的动态扩展。
　　回到关于事件的四个场景，事件中心可以支持一、二两个场景。同时对事件做了持久化，维护事件库，那么就可以基于事件库来实现事件溯源，所以事件中心也间接的支持了第三个场景。
　　那么，有了事件中心，我们还可以做什么？
　　基于事件中心，我们还可以实现有序事件管理，比如场景要求必须事件1投递之后，事件2才可以投递，那么可以设置事件2的前置事件是事件1，通过绑定键值来找到相关的事件1和事件2，做前置控制。
　　基于事件中心，也可以实现数据最终一致性控制。可以实现中心式的Saga管理器，在事件中心定义以事件组成的业务流程，同时定义事件监听失败的补偿命令，通过Saga的算法来实现最终一致性。
　　最后说明一点，业务中台的核心思想是通过快速组装若干个标准化能力，来实现快速变化的前台场景。那么业务中台的这一特性就要求了各能力中心必须是松耦合的，可装配的，而达到这一架构要求的，也必然是基于事件中心的事件驱动架构最为合适。