前言

在之前的文章中我们介绍了如何进行流式处理——从一般性的概念和模式说起，并列举了一些Streams的例子：

• 流式处理相关概念总结说明
• 流式处理设计模式总结说明
• Kafka Streams 架构概览

接下来的文章将介绍一些流式处理的实际应用场景以及我们该从哪些方面考虑选择哪些流式处理框架，目前比较流行的流式处理框架有很多，比如说 Flink, Spark Streaming， Kafka Streaming 等。

使用场景

客户服务

假设我们刚刚向一家大型连锁酒店预订了一个房间，并希望收到电子邮件确认和收据。但是，在预订了几分钟之后我们还没有收到确认邮件，于是打电话向客服确认。

客服的回复是：“我在我们的系统中看不到订单，将数据从预订系统加载到客服系统的批处理作业每天只运行一次，所以请明天再打电话过来。你应该可以在2~3个工作日之后收到确认邮件。”这样的服务质量有点儿糟糕，而我们已经不止一次在一家大型连锁酒店遭遇过类似的问题。

我们希望连锁酒店的每一个系统在预订之后的几秒或几分钟之内都能发出通知，包括客服中心、酒店、发送确认邮件的系统、网站等。我们还希望客服中心能够立即拉取到我们在这家连锁酒店的历史入住数据，知道我们是忠实顾客，从而为我们升级服务。

如果用流式处理应用程序来构建这些系统，它们就可以几近实时地接收和处理事件，带来更好的用户体验。有了这样的系统，顾客就可以在几分钟之内收到确认邮件，并及时从信用卡中扣除费用，然后发送票据，服务台就可以马上回答有关房间预订情况的问题了。

物联网

物联网包含了很多东西，从可调节温度和订购洗衣剂的家居设备到制药行业的实时质量监控设备。

流式处理在这方面最为常见的应用是预测何时该进行设备维护。这与应用程序监控有点儿相似，只是监控的对象是硬件，这在很多行业中很常见，包括制造业、通信（识别故障基站）、有线电视（在用户投诉之前识别出故障机顶盒）等。

每一种场景都有自己的模式，但目标是一样的，即处理大量来自设备的事件，并识别出故障设备的模式，比如交换机丢包、制造过程中需要更大的力气来拧紧螺丝，或者用户频繁重启有线电视机顶盒。

欺诈检测

欺诈检测也叫异常检测，是一个非常广泛的领域，专注于捕获系统中的“作弊者”或不良分子。

欺诈检测的应用包括信用卡欺诈检测、股票交易欺诈检测、视频游戏欺诈检测和网络安全风险。在这些欺诈行为造成大规模破坏之前，越早识别出它们越好。一个几近实时的可以快速对事件做出响应（比如停止一个还没有通过审核的交易）的系统比在3天之后才能检测出欺诈行为的批处理系统要好得多。这也是一个在大规模事件流中识别模式的问题。

在网络安全领域，有一个被称为发信标(beacon)的欺诈手法。黑客在组织内部植入恶意软件，恶意软件会时不时地连接到外部网络接收命令。由于恶意软件可以在任意时间以任意频率接收命令，因此很难被检测到。

通常，网络可以抵挡来自外部的攻击，但难以阻止从内部到外部的突围。通过处理大量的网络连接事件流，识别出不正常的通信模式（例如，检测出主机访问了平常不经常访问的某些IP地址），我们可以在蒙受更大的损失之前向安全组织发出告警。

如何选择流式处理框架

在选择流式处理框架时，需要着重考虑应用程序的类型。不同类型的应用程序需要不同的流式处理解决方案。

数据摄取

• 数据摄取的目的是将数据从一个系统移动到另一个系统，并在传输过程中对数据做一些修改，使其更适用于目标系统。

低延迟处理

• 任何要求立即得到响应的应用程序。有些欺诈检测系统就属于这一类。

异步微服务

• 这些微服务负责执行大型业务流程中的一些简单的操作，比如更新库存信息。这些应用程序需要通过维护本地状态缓存来提升性能。

几近实时的数据分析

• 这些流式应用程序通过执行复杂的聚合和连接操作来对数据进行切分，并生成有趣的业务见解。

选择什么样的流式处理系统在很大程度上取决于你要解决什么问题：

• 如果你要解决数据摄取问题，那么就要考虑是需要流式处理系统还是更简单的专注于数据摄取的系统，比如Connect。如果你确定需要流式处理系统，那么就要确保它和目标系统都有可用的连接器。
• 如果你要进行低延迟处理，那么就要考虑是否一定要使用流。一般来说，请求与响应模式更适合用来处理这种任务。如果你确定需要流式处理系统，那么就选择一种支持逐事件低延迟模型而不是微批次模型的流式处理系统。
• 如果你要构建异步微服务，那么就需要可以与消息总线（希望是Kafka）集成的流式处理系统，它应该具备变更捕获能力，可以将上游的变更更新到微服务的本地缓存里，并且支持本地存储，可以作为微服务数据的缓存和物化视图。
• 如果你要构建复杂的数据分析引擎，那么就需要支持本地存储的流式处理系统，不过这次不是为了本地缓存和物化视图，而是为了支持高级聚合、时间窗口和连接，因为如果没有本地存储，就很难实现这些特性。流式处理系统的API需要支持自定义聚合、时间窗口操作和多种连接类型。

除了具体的应用场景，还需要从全局考虑如下事项。

系统的可操作性

• 它是否容易部署？是否容易监控和调试？是否容易扩展？是否能够与已有的基础设施集成？如果出现错误需要重新处理数据该怎么办？

API的可用性和可调试性

• 用同一种框架的不同版本开发高质量的应用程序所耗费的时间可能千差万别。因为开发时间和发布时机太重要了，所以需要选择一个高效的系统。

化繁为简

• 大部分系统声称它们支持基于时间窗口的高级聚合和本地缓存，但问题是，它们够简单吗？它们是帮你处理了伸缩和故障恢复方面的问题，还是只提供了脆弱的抽象并让你自己处理剩下的脏活？系统提供的API越简洁，封装的细节越多，开发人员的效率就越高。

社区

• 大部分流式处理框架是开源的。对开源软件来说，一个充满生机的社区是不可替代的。好的社区意味着用户可以定期获得新的功能特性，而且质量相对较高（没有人会使用糟糕的软件），bug可以很快地得到修复，用户的问题可以及时得到解答。如果你遇到一个奇怪的问题并在谷歌上搜索，那么可以搜索到相关的信息，因为其他人也在使用这个系统，并遇到过同样的问题。