随着计算机技术的发展，传统的命令式编程方式在解决某问题上变得捉襟见肘，流式编程有着天然的异步属性，适合用在做IO等高高吞吐量的场景下，本文我来简单分析下两种编程模型的区别。
一、数据驱动方式不同
命令式编程是业务代码驱动数据的方式，即数据的流动是我们的业务代码主动驱动的。一旦没有业务代码驱动，数据是不会流动起来的。我们也可以理解为数据"拉"模型,我们的业务要主动的取数据来完成业务计算和数据加工！
流式编程的数据是数据本身驱动的，我们可以想象一根水管中流动的水，我们接上水龙头，打开开关，水就在管道中流动起来了，把水比喻成我们的数据，我们可以发现，流式编程中的数据是"推"模型，这种情况下，我们的业务处理就不用关注数据的拉取了，我们的业务只要关注如何处理和加工，被动的等待被调用就可以了！
通过上面的两种数据驱动方式的分析，我们可以得出下面的推论：
1 流式编程由于不用在业务中处理数据的获取，只负责数据的处理，应该能大大精简业务处理代码。
2 我们可以给命令式编程封装一个数据驱动层框架，这个框架负责对命令式编程中要处理的数据“推”给业务处理链进行处理，这样我们就可以实现像IO处理一样的"伪流式"(相比于纯流式，数据还是整体，不是总长度和到达时间未知的)编程了。
二、数据处理方式不同
数据处理方式的不同本质上是由于流式编程中的数据流通常是不可以预期流总长度和到达时间的，而命令式编程中处理的数据通常都是固定大小的，而且不用考虑到达时间，我们处理数据的时候数据就在那里了！
由于数据的特性不同导致了两种编程模型对数据处理的方式不同，下面说说流式编程对数据处理的方式：
1 必须要有流拆分和合并（流编解码）
我们的业务代码，虽然是说是对流进行处理，但是本质上是还是和命令式编程中一样，是以一个完整的业务消息数据作为处理对象的，所以我们的业务代码中，要有流过滤器，负责对流数据拆分和合并成业务消息的能力，这个过滤器通常作为数据驱动层实现的一部分，后端的业务处理链直接处理解码后的消息。
2 我们的业务处理代码要以“消息驱动或者事件驱动”的形式编写，这是由于流数据的到达时间不定的特点导致的，我们的业务代码要注册为某些消息数据的处理器，等待着消息到来后被调用！
(完)
