目录
前言：
1、传统架构与流处理架构
对于后端数据而言，典型的传统架构是采用一个中心化的数据库系统，该 系统用于存储事务性数据。换句话说，数据库（SQL 或者 NoSQL）拥有 “新鲜”（或者说“准确”）的数据，这些数据反映了当前的业务状态，如系 统当前有多少已登录的用户，网站当前有多少活跃用户，以及当前每个用户的账户余额是多少。需要新鲜数据的应用程序都依靠数据库实现。分布式文件系统则用来存储不需要经常更新的数据，它们也往往是大规模批量计算所依赖的数据存储方式。
2、消息传输层和流处理层
如何有效地实现流处理架构并从 Flink 中获益呢？一个常见的做法是设置消 息传输层和流处理层
(1) 消息传输层从各种数据源（生产者）采集连续事件产生的数据，并传输 给订阅了这些数据的应用程序和服务（消费者）。
3、消息传输层的理想功能
3.1、兼具高性能和持久性
3.2、将生产者和消费者解耦
采用高效的消息传输技术，可以从多个源（生产者）收集数据，并使这些数据可供多个服务或应用程序（消费者）使用，如图下图所示。Kafka 和MapR Streams 把从生产者获得的数据分配给既定的主题。数据源将数据推送给消息队列，消费者（或消费者群组）则拉取数据。事件数据只能基于给定的偏移量从消息队列中按顺序读出。生产者并不向所有消费者自动广播。这一点听起来微不足道，但是对整个架构的工作方式有着巨大的影响。
这种传输方式——消费者订阅感兴趣的主题——意味着消息立刻到达，但并不需要被立刻处理。在消息到达时，消费者并不需要处于运行状态，而是可以根据自身的需求在任何时间使用数据。这样一来，添加新的消费者和生产者也很容易。采用解耦的消息传输系统很有意义，因为它能支持微服务，也支持将处理步骤中的实现过程隐藏起来，从而允许自由地修改实现过程。
4、支持微服务架构的流数据
微服务方法指的是将大型系统的功能分割成通常具有单一目的的简单服务， 从而使小型团队可以轻松地构建和维护这些服务。即使是超大型组织，也可以用这种设计实现敏捷。若要使整个系统正常工作，各服务之间因通信而产生的连接必须是轻量级的。
消息传输系统一方面将生产者和消费者解耦，另一方面又有足够高的吞吐量，并且能够满足像 Flink 这样的高性能流处理器。这种系统非常适合用于构建微服务。就连接微服务而言，流数据是相对较新的模式，但是它有许多好处。
4.1、数据流作为中心数据源
流处理架构的核心是使各种应用程序互连在一起的消息队列。流处理器例如Flink从消息队列中订阅数据并加以处理。处理后的数据可以流向另一个消息队列。这样一来，其他应用程序（包括其他 Flink 应用程序）都可以共享流数据。在一些情况下，处理后的数据会被存放在本地数据库中
如上图所示在流处理架构中，消息队列（图中以水平圆柱体表示）连接应用程序，并作 为新的共享数据源；它们取代了从前的大型集中式数据库。在本例中，Flink 被多个 应用程序使用。本地化的数据能够根据微服务项目的需要被存储在文件或者数据库中。 这种流处理架构的另一个好处是，流处理器（例如 Flink）还可以保障数据一致性。
流处理架构不需要集中式数据库。取而代之的是消息队列， 它作为共享数据源，服务于各种不同的消费者。
4.2、欺诈检测：流处理架构用例
基于流处理的微服务架构有着强大的灵活性，特别是当同一份数据被用于不同的场景时，其灵活性更为明显。以信用卡服务提供商的欺诈检测项目为例。项目的目标是尽可能快地识别可疑的刷卡行为，从而阻止盗刷，并将损失降到最低。例如，欺诈检测器可以将刷卡速度作为评判依据：在很短的时间内，发生在跨度很大的不同地点，这样的连续交易合理吗？事实上，真正的欺诈检测器会使用几十个（甚至几百个）特征作为评判依据，但是我们仅仅通过分析刷卡速度这一个特征就可以理解许多问题。 下图 展示了流处理架构在欺诈检测项目中的优势。在图中，许多销售终端 （POS 机 1~n）请求欺诈检测器判定是否有欺诈行为。这些来自销售终端的询问需要立即被应答，因此在销售终端与欺诈检测器之间形成了询问与应答的交互。
上图中欺诈检测可以从基于流处理的微服务架构中受益。在这种架构中，Flink 在 如下几个部分都非常有用：欺诈检测器、更新器，甚至刷卡行为分析器。值得一提的是，这种架构没有直接在本地数据库中更新刷卡行为的数据，而是将数据放在消息队列里，这些数据还可以不受干扰地被刷卡行为分析器等其他服务使用
传统的欺诈检测模型将包含每张信用卡最后一次刷卡地点的文件直接存储在数据库中。但在这样的集中式数据库设计中，其他消费者并不能轻易使用刷卡行为的数据，因为访问数据库可能会影响欺诈检测系统的正常工作；在没有经过认真仔细的审查之前，其他消费者绝不会被授权更改数据库。这将导致整个流程变慢，因为必须仔细执行各种检查，以避免核心的业务功能受到破坏或影响。
与传统方法相比，上图所示的流处理架构设计将欺诈检测器的输出发送给外部的消息队列（Kafka 或 MapR Streams），再由如 Flink 这样的流处理器更新数据库，而不是直接将输出发送给数据库。这使得刷卡行为的数据可以通过消息队列被其他服务使用，例如刷卡行为分析器。上一次刷卡行为的数据被存储在本地数据库中，不会被其他服务访问。这样的设计避免了因为增加新的服务而带来的过载风险。
4.3、给开发人员带来的灵活性
基于流处理的微服务架构也为欺诈检测系统的开发人员带来了灵活性。假设开发团队正试图改进欺诈检测模型并加以评估。刷卡行为产生的消息流可以被新模型采用，而完全不影响已有的检测器。新增加一个数据消费者的开销几乎可以忽略不计，同时只要合适，数据的历史信息可以保存成任何一种格式，并且使用任意的数据库服务。此外，如果刷卡行为队列中的消息被设计成业务级别的事件，而不是数据库表格的更新，那么消息的形式和内容都会非常稳定。若一定要更改，向前兼容可以避免更改已有的应 用程序。
信用卡欺诈检测只是流处理架构的一个用例。流处理架构通过一个合适的消息传输系统（Kafka 或 MapR Streams）和一个多用途、高性能的流处理器（Flink），能支持各种应用程序使用共享数据源，即消息流。
5、不限于实时应用程序
虽然低延迟性很重要，但是实时应用程序只是众多流数据消费者中的一种。流数据的应用很广泛，比如，流处理应用程序可以通过订阅消息队列中的流数据来实时更新仪表盘（如下图中的 A 组消费者）。
持久化的消息可以被重播，这一特性使许多用户获益（如下图中的 C 组消费者）。在本例中，消息流成为了可审计的日志，或者长期的事件历史。能够重现的历史非常有用，比如可以在工业安全分析中作为预知维护模型的一部分输入，也可以在医学或环境科学领域用于回顾性研究。
流数据消费者并不仅限于实时应用程序，尽管它们是很重要的一种。本图展示了从流处理架构中获益的几类消费者。A 组消费者可能做各种实时分析，包括实时更新仪表盘。B 组消费者记录数据的当前状态，这些数据可能同时也被存储在数据库或搜索文件中在其他一些用例中，应用程序使用消息队列中的数据更新本地数据库或者搜索文件（如图上图中的 B 组消费者）。消息队列中的数据往往必须被流处理器聚合或者分析并转换之后，才会输出到数据库中。这是 Flink 擅长的另一个场景。
6、流的跨地域复制
流处理架构并不是玩具：它被用于具有重要使命的系统，这些系统要求流处理层和消息传输层具备一些特性。许多关键的业务系统依靠跨数据中心的一致性，它们不仅需要高效的流处理层，更需要消息传输层拥有可靠的跨地域复制能力。例如，电信公司需要在移动通信基站、用户和处理中心之间共享数据；金融机构需要快速、准确地在相隔很远的办公室之间复制数据，同时控制成本。类似的例子还有很多。具体来说，数据中心之间的数据复制需要保存消息偏移量，这一点最有用，因为它使得任何数据中心的更新都可以被传播到其他数据中心，且允许双向和循环的数据复制。如果消息偏移量没有被保存，那么另一个数据中心就无法可靠地重启程序。如果不允许其他数据中心更新数据，那么就必须设计可靠的主节点。循环复制则可以避免复制过程出现单点故障。
