专业名词的中文可能不准确，参考英文名词。
本篇文章主要讲述我们在微服务架构设计中常见的事件驱动，内容如下：
1.Event Stream-事件流
2.Event Sourcing-事件溯源
3.Polyglot Persistence-混合持久化
4.Command Query Responsibility Separation-命令查询分离
目前国内外互联网公司已经从单体应用(monolithic)完全转变为微服务架构(microservices)。单体架构就是把所有的功能都耦合在一个进程之中，如果要横向扩展就要把整个应用进行复制。
单体应用架构最大问题在于单一数据库。因为分布式事务以及join连接很难进行垂直或者水平扩展。当大并发访问会造成性能瓶颈。
微服务已经有很多文章谈到了，最根本的方法就是按照业务垂直进行服务拆分，每个服务都是独立的应用，分别调用独立的数据库以及独立的资源。
笔者在2014年的一个产品中进行了微服务规划及改造，具体架构如下，为了方便大家理解以服务端的视角来描述微服务架构。
每个功能都是独立的node app（可以理解为一个spring boot），每个功能都有独立的数据库（Mongodb）。每个服务都是无状态可以进行横向扩展。每个数据库都可以进行replication/sharding集群。
Event Stream
在我尝试迁移整个架构的过程中，Event Stream是我常用的方法之一。可以把一些event扔到kafka或者rabbitmq中。把一组event可以理解为topic，当然event一定要进行持久化，目前技术选择MapR stream也是不错的选择，安利一下支持kafka api。如图
要记住的是，event一定要进行状态持久化。
Event Sourcing
Event Sourcing也是架构常见的设计模式，其实就是保存了修改记录的各个状态的步骤，如图。
我们还是采用stream的方式来记录整个事件的变化，如上图所示，在stream中，可以重新创建整个账户。其实这种是很常见的模式，比如源码管理及数据库复制都是这种模式。
这种模式带来的优势很多，如跟踪整个变化过程，数据一致性。
Polyglot Persistence
混合持久化顾名思义就是根据不同的需求应用不同的数据库，
如图，根据不同的业务场景把数据的变化存储为不同的数据模型中，比如在更新一个商品的基本信息，把基本属性信息存储在关系型数据库中，把前端页面展示商品信息存储在mongodb中，为了全文搜索同步又会更新我们的Elasticsearch中，等等你能想象的业务场景。
CQRS
简而言之就是使用event sourcing把一个系统的读命令和命令请求(写请求)进行分离，我就举一个CMS的例子把，需求就是查询最新的5篇文章，传统的方式如下，
CQRS模式如下
这种架构过程就是把文章添加的event写入到了stream中，在通过consumer写入到文章展示库中，我们可以选用mongodb或者redis，都可以。CQRS本质就是把写入命令和读取通过event soucing进行分离。
总结
本篇文章主要讨论了基于event驱动的架构模式，分别讲述了Event Soucing，CQRS，Polyglot Persistence。这是微服务架构很基本的设计模式和方法，接下来也会分享更多关于微服务的文章，比如api gateway的选择等等。
