背景
本文主要是从全局角度来分析debezium的插件架构特性，帮助大家对debezium有一个宏观的了解。
架构
debezium的使用方式目前有3种形式：
- 部署作为一个kafka connector in Kafka Connect cluster
- 部署在Debezium Server里
- 作为一个embedded engine 在自己的应用里
本文主要讨论作为embedded engine的时候的架构。
嵌入式引擎需要实现DebeziumEngine接口，这个接口也是一个Runnable，所以它的入口方法是在run方法里。
1 | public interface DebeziumEngine<R> extends Runnable, Closeable |
EmbeddedEngine是它的实现类。我们来看看它的run方法，首先会根据 connector.class 属性创建一个SourceConnector实例（如：MySqlConnector），接着实例化offset store实现类并启动（**offset.storage**配置），接着判断是否自定义了offsetCommitPolicy提交策略，没有的化初始化一个默认的策略（PeriodicCommitOffsetPolicy），接着初始化connector，在通过connector获取ConnectorTask（如：MySqlConnectorTask），初始化并启动ConnectorTask，真正执行同步的动作都在ConnectorTask类里，里面会创建根据是否需要同步快照，先启动SnapshotReader，接着启动BinlogReader，两个reader通过一个ChainedReader来组织。reader里获取的changeEvent会放入一个BlockingQueue里，之后通过task.poll()方法获取新的事件，最后回调ChangeConsumer的handle方法交给客户处理。
至此，整个流程就走完了。
走起整个流程后，我发现整个代码里，有许多Listener，回调方法，比如：
- SourceConnector
- OffsetBackingStore
- offsetCommitPolicy
- ConnectorCallback
- ChangeConsumer
这些类要么通过配置来自定义，要么通过接口实现类传入，最后通过在事件处理流程中进行回调。其实这就是我们经常听到的微内核，插件化架构，以后别人在给你吹我们的架构是微内核架构，就不用虚了。
