EventStore

前言 2020 年微众银行在 GitHub 上正式开源了 EventMesh。 EventMesh 和 DeFiBus一起作为微众银行已经开源的项目，目前支撑了微众银行每天亿级的金融交易。 作为一个动态插件式云原生基础服务，EventMesh 提供了灵活，可靠和快速的事件分发与处理，并且可进行管理。本篇文章将围绕 EventMesh 起源及原理等方面进行介绍，并结合微众银行的实践经验带领大家一起探索事件驱动架构。 01 什么是事件驱动架构 近年来，随着微服务、云原生和 Serverless 概念的普及以及容器化技术的发展，事件驱动也再次成为热点，引起IT界广泛的关注。事件驱动架构是一种用于设计应用的软件架构和模型。对于事件驱动系统而言，事件的捕获、通信、处理和持久保留是解决方案的核心结构。事件驱动架构可以最大程度减少耦合度，很好地扩展与适配不同类型的服务组件，因此是现代化分布式应用架构的理想之选。 解耦 基于这种松耦合，微服务可以用不同的语言实现。解耦后的微服务能够轻松地在网络上相互独立地扩展，通过动态添加或删除事件生产者和消费者来修改他们的系统，而不需要更改任何微服务中的任何逻辑。 基于推送通知的消息传输机制 事件驱动的体系结构中，客户端无需轮询就可以接收更新，事件在到达事件存储后就会通知给客户端，客户端可以随时接收更新，这对于动态数据转换、分析和数据科学处理非常有用。

背景 不知道是否你还在为下面的问题而困扰： 当你使用了redis或者其他中间件做缓存的时候，经常发现缓存和数据库的数据不一致，只能通过定时任务或者缓存过期的方式去做一些限制。 当你使用了ES做搜索工具，使用双写的那一套方法，还在为ES和数据库不是一个事务而担忧。 当你需要迁移数据的时候，也还在使用双写的方法，如果是同一个数据库的还好，如果是不同数据库就不能保证事务，那么数据一致性也是个问题，就会写很多的修复Job和检查Job。 这些问题相信在很多同学的业务当中应该都遇到过，也可能因为这些问题常常增加了很多的工作量或者导致一些数据不一致的故障。那么我们怎么才能比较简单的解决这些问题呢？ 我们想一想这个问题的本质是什么呢？就是需要保证我们的数据不论在redis还是在es都要和我们的mysql一致，本质上是数据的复制。一想到数据的复制，熟悉Mysql的朋友就会说到：Mysql的主备不也是数据复制吗？如果我们模仿Mysql的主备复制，那我们数据同步那么就会很容易了。 Mysql主从 既然我们可以模仿Mysql的主从复制来完成我们的需求，那么我们需要先了解一下mysql主从的原理，如下图所示： Stpe 1: 作为master的mysql需要在每个事务更新数据完成之前，将该操作记录串行地写入到binlog文件中，存储在本地磁盘中。 Step 2: 在我们的salve服务器中开启一个I/O

基于1.1.5-alpha版本，具体源码笔记可以参考我的github：https://github.com/saigu/JavaKnowledgeGraph/tree/master/code_reading/canal 关于instance的定义，可以参考前面的几篇源码解析，介绍的非常清楚。 instance模块比较简单，我们重点了解以下几个问题 instance配置模式有哪几种，如何根据配置创建instance？ 远端配置如何覆盖本地配置的？ instance实例内部有哪些组件？ 1.基本结构 instance模块下面也分为三个子模块，core、manager、spring。 其中，core是instance的核心逻辑 。 而manager和spring只是两种不同的instance配置读取方式，manager通过http请求读取admin的配置，spring通过配置文件的方式读取。 主要控制逻辑我们在deployer模块源码分析中提到过，就是在CanalController类 的instanceGenerator，配置参数是canal.instance.global.mode 根据destination创建config 如果canal.instance.global.mode = manager，就使用PlainCanalInstanceGenerator 如果canal

1.简介 canal [kə'næl]，译意为水道/管道/沟渠，主要用途是基于 MySQL 数据库增量日志解析，提供增量数据 订阅 和 消费。应该是阿里云DTS（Data Transfer Service）的开源版本。 2.提供的能力 Canal与DTS提供的功能基本相似： 1）基于Mysql的Slave协议实时dump binlog流，解析为事件发送给订阅方。 2）单Canal instance，单DTS数据订阅通道均只支持订阅一个RDS，提供给一个消费者。 3）可以使用canal-client客户端进行消息消费。 4）也可以通过简单配置，也可以不需要自行使用canal-client消费，可以选择直接投递到kafka或者RocketMQ集群，用户只需要使用消息队列的consumer消费即可。 5）成功消费消息后需要进行Ack，以确保一致性，服务端则会维护客户端目前的消费位点。 3.工作原理 MySQL的主从复制分成三步： master将改变记录到二进制日志(binary log)中（这些记录叫做二进制日志事件，binary log events，可以通过show binlog events进行查看）； slave将master的binary log events拷贝到它的中继日志(relay log)； slave重做中继日志中的事件，将改变反映它自己的数据。 canal

Command and Query Responsibility Segregation (CQRS) pattern The Command and Query Responsibility Segregation (CQRS) pattern separates read and update operations for a data store. Implementing CQRS in your application can maximize its performance, scalability, and security. The flexibility created by migrating to CQRS allows a system to better evolve over time and prevents update commands from causing merge conflicts at the domain level. The problem In traditional architectures, the same data model is used to query and update a database. That's simple and works well for basic CRUD operations.

EventBus/EventQueue 再思考 Intro 之前写过两篇文章，造轮子系列的 EventBus / EventQueue ，回想起来觉得当前的想法有点问题，当时对 EvenStore 可能有点误解，有兴趣可以参考 https://www.cnblogs.com/weihanli/p/implement-a-simple-event-bus.html / https://www.cnblogs.com/weihanli/p/implement-event-queue.html ， 最近把 Event 相关的逻辑做了一个重构，修改 EventStore ，引入了 IEventHandlerFactory ，重新设计了 Event 相关的组件 重构后的 Event Event: 事件的抽象定义 EventHandler：事件处理器抽象定义 EventHandlerFactory：事件处理器工厂，用来根据事件类型获取事件处理器（新增） EventPublisher：事件发布器，用于事件发布 EventSubscriber：事件订阅器，用于管理事件的订阅 EventSubscriptionManager：事件订阅管理器，在 EventSubscriber 的基础上增加了一个根据事件类型获取事件订阅器类型的方法 EventBus：事件总线，由 EventPubliser 和

最近把 Event 相关的逻辑做了一个重构，修正 EventStore，引入了 IEventHandlerFactory，重新设计了 Event 相关的组件 重构后的 Event Event: 事情的笼统定义 EventHandler：事情处置器笼统定义 EventHandlerFactory：事情处置器工厂，用来依据事情类型获取事情处置器（新增） EventPublisher：事情发布器，用于事情发布 EventSubscriber：事情订阅器，用于管理事情的订阅 EventSubscriptionManager：事情订阅管理器，在 EventSubscriber 的根底上增加了一个依据事情类型获取事情订阅器类型的办法 EventBus：事情总线，由 EventPubliser 和 EventSubscriber 组合而成，用来比拟便当的做事情发布和订阅 EventQueue：事情队列，希望某些音讯次第处置的时分能够思索用 EventQueue 的形式 EventStore：事情存储，事情的耐久化存储（在之前的版本里，EventStore 实践作用是一个 EventSubscriptionManager，在最近的版本更新中已修正) 以上 EventSubscriber 和 EventSubscriptionManager 普通不直接用，普通用 EventBus 来处置即可

基于1.1.5-alpha版本，具体源码笔记可以参考我的github： https://github.com/saigu/JavaKnowledgeGraph/tree/master/code_reading/canal 本文将对canal的server模块进行分析，跟之前一样，我们带着几个问题来看源码： CanalServer有几种使用方式？ 控制台Admin、客户端client是如何与CanalServer交互的？ CanalServerWithNetty和CanalServerWithEmbedded究竟有什么关系？ Canal事件消费的特色协议，异步流式api（get/ack/rollback协议）的设计是如何实现的？ server模块内的结构如下： 主要分为了三个包： admin包： 这个包的CanalAdmin接口定义了canalServer上暴露给canal-admin控制台使用的一些服务接口。 上一篇deployer模块解析中提到的CanalAdminController就是实现了CanalAdmin接口（把这个接口的实现放在deployer模块是挺奇怪的）。Admin包中使用了netty作为服务端（CanalAdminWithNetty类中实现），接受控制台Admin的请求，返回当前canalServer的一些运行状态。 server包： server模块的核心包

EventBus/EventQueue 再思考 Intro 之前写过两篇文章，造轮子系列的 EventBus / EventQueue ，回想起来觉得当前的想法有点问题，当时对 EvenStore 可能有点误解，有兴趣可以参考 https://www.cnblogs.com/weihanli/p/implement-a-simple-event-bus.html / https://www.cnblogs.com/weihanli/p/implement-event-queue.html ， 最近把 Event 相关的逻辑做了一个重构，修改 EventStore ，引入了 IEventHandlerFactory ，重新设计了 Event 相关的组件 重构后的 Event Event: 事件的抽象定义 EventHandler：事件处理器抽象定义 EventHandlerFactory：事件处理器工厂，用来根据事件类型获取事件处理器（新增） EventPublisher：事件发布器，用于事件发布 EventSubscriber：事件订阅器，用于管理事件的订阅 EventSubscriptionManager：事件订阅管理器，在 EventSubscriber 的基础上增加了一个根据事件类型获取事件订阅器类型的方法 EventBus：事件总线，由 EventPubliser 和

旅程5：准备发布V1版本 添加功能和重构，为V1版本发布做准备。 “大多数人在完成一件事之后，就像留声机的唱片一样，一遍又一遍地使用它，直到它破碎，忘记了过去是用来创造更多未来的东西。” -- 弗雷娅.斯塔克 发布Contoso会议管理系统V1版本： 本章描述了团队为准备Contoso会议管理系统的第一个产品版本所做的更改。这项工作包括对前两章介绍的订单(Order)和注册(Registrations)限界上下文的一些重构和功能添加，以及一个新的会议管理(Conference Management)限界上下文和一个新的支付(Payment)限界上下文。 团队在此过程中进行的一个关键重构是将事件源(ES)引入订单(Order)和注册(Registrations)限界上下文中。 实现CQRS模式的一个预期好处是，它将帮助我们在复杂系统中管理变化。在CQRS旅程中发布一个V1版本将帮助团队评估当我们从V1版本迁移到系统的下一个产品版本时使用CQRS和ES的好处。剩下的章节将描述V1版本发布后的情况。 本章描述了团队在此阶段添加到公共网站的用户界面(UI)，并包括了对基于任务的UI的讨论。 本章的工作术语定义： 本章使用了一些术语，我们将在下面进行描述。有关更多细节和可能的替代定义，请参阅参考指南中的“ 深入CQRS和ES ”。 访问代码(Access code)