基于中间件的数据流模型设想

Posted 2021-04-10 道爷说事儿

数据是系统的血液，任何没有数据的软件系统都毫无用处，对于业务系统更是如此，因为所有的业务操作最终都是数据操作。

数据是如此的重要，所以处理好“异构系统之间的数据同步”则是一个比较有思考意义的问题。

本人多次经历异构系统之间数据同步的需求，在实践过程中也遇到过很多问题，因此也一直在思考如何处理好这些问题。

本文针对以前遇到的问题提出了一个架构设想，欢迎拍砖~

缘起

我在多个系统上遇到需要将一个系统的数据需要同步到另一个系统的业务场景，对于一些老旧或者设计不是那么良好的系统来说这是一个小小的挑战。

起初，我采用简单粗暴的一边select一边insert的暴力模式，这样做的好处是产出很快，做完调好立马上线，前后花不了三天时间，唯一的后遗症是不好应对变化，且同步的数据两端必须是数据库。

因此我觉得这并不是什么好的方案，对于这个问题必然有更优雅的解决办法。

抽象

后来，我觉得目光不要这么局限，想想现实世界有没有类似的问题，现实中是如何处理的。一番思索后觉得自来水送水的模式跟这个数据同步有及其相似之处，它们都是将资源从一个地方传递到另一个地方。那么，我是不是也可以采取这种思路来解决这个问题呢。

架构设计

既然想到这里，不妨来尝试一下，打开Visio做一个简单的架构和流程设计。

经过一番狂想，得出如下流程（该流程大致模仿自来水送水过程）：

1. “控制中心”通过“资源抽取”来抽取“资源”（即“水厂”通过“水泵”抽水的过程）。

2. “控制中心”将取得的资源投放到“传输管道”中（即“水泵”将水抽入“水管”的过程）。

3. “传输管道”一番处理后将“资源”投放到“接收”端（即”沉淀”、“过滤”，“消毒”，“送水入户”等过程）。

4. “接收”端在接收到资源后可以选择将资源“存储”起来（即用户放水的过程）。

在流程图中，已经将各部件在自来水运输过程中所属的角色标注出来了；同时，也将这些部件在软件中应当承担什么样的角色标注了出来。

然后来升华一下基于这个流程得出的思路，再画个架构图出来，如下：

调度器（Dispatcher）
Dispatcher作为最核心的部件，担当“水厂”的角色。它负责调度Reader，并向Pipeline输入数据。

管道（Pipeline）
Pipeline是次核心的部件，它负责管理Middleware和搬运数据。

读取器（Reader）
Reader则担当“水泵”的角色，它负责从异构的系统中去读取数据，针对不同的数据资源可以实现不同的Reader。Reader唯一的作用就是获取数据，并将取得的数据交还给Dispatcher，它本身对数据不做任何加工。

中间件（Middleware）
Middleware作为数据加工的重要组件，它负责对数据进行过滤、转换等二次加工，并将加工之后的数据再次输入Pipeline使其继续流转，Middleware有优先级之分，Pipeline按照“从高到低”的优先级依次将数据输入Middleware，数据每经过一个Middleware都可能发生一些变化（即，Middleware对数据做了处理）。

存储器（Writer）
Writer担当“放水”的角色，当数据到达Writer的时候，它负责将数据写入数据库中。之后，数据从Pipeline中移除。事实上它也是一个特殊的Middleware，不过它的优先级在所有Middleware的最后。

可行性分析

经过前面的一些分析和设计：我认为这个思路是可行的。

大概分析一下这个模型的优点：

整个架构呈现出一种比较松散的体系，对数据的读取、转换、写入进行了拆分。

在这种体系之下，可以比较从容的应对数据资源格式不统一的问题，例如：有的数据来源于数据库，有的来源于文件，对于这种情况，只需要编写相应的“Reader”就可以快速的将数据纳入整个数据流转体系。

另外，对数据的二次加工变得更加容易，通过中间件，可以很方便的对管道中的数据进行各种处理，例如：序列化、反序列化、去重、筛选等等。每一个中间件可以只负责一小部分工作，将比较复杂的数据处理过程分散到多个中间件中。这样，整个数据处理的过程就比较清晰明了，开发起来也更加容易。

同时，这个模型的扩展性也是不错的，当增加异构系统时，只需要增加相应的读写组件就可以了。

总结

现实中的很多工作模式抽象到软件中也能获得不错的效果，面向对象的本质就是对现实进行抽象。