支持微服务架构的流数据处理

微服务是指将大型系统的功能分割成通常具有单一目的的简单服务，从而使小型团队可以轻松地构建和维护这些服务。即使是超大型组织，也可以用这种设计实现敏捷。若要使整个系统正常工作，各服务之间因通信而产生的链接必须是轻量级的。微服务的目标是给予每个团队一项工作，并授以完成工作的方法，然后就放手。

之前说过消息传输系统一方面将生产者和消费者解耦，另一方面又有足够高的吞吐量，并且能够满足像Flink这样的高性能流处理器。这种系统非常适合用于构建微服务。就链接微服务而言，流数据是相对较新的模式，但是新的模式下也有很多好处：

使用数据流作为中心数据源：流处理架构的核心是使各种应用程序互连在一起的消息队列。FLink从消息队列中订阅数据并加以处理。处理后的数据可以流向另一个消息队列。这样一来，其他应用程序都可以共享流数据。另外在一些情况下，处理后的数据也会被存放在本地数据库。

使用流处理架构来做欺诈检测：基于流处理的微服务架构有着强大的灵活性，特别是当同一份数据被用于不同的场景时，其灵活性更为明显。以信用卡服务提供商的欺诈检测项目为例。项目的目标是尽可能快地识别可疑的刷卡行为，从而阻止盗刷，并将损失降到最低。例如，欺诈检测器可以将刷卡速度作为评判依据：在很短时间内，发生在跨度很大的不同地点，这样的连续交易合理吗？事实上，真正的欺诈检测会使用几十个（甚至几百个）特征作为评判，但是我们仅仅通过分析刷卡速度这一个特征就可以理解许多问题。

传统的欺诈检测模型将包含每张信用卡最后一次刷卡地点的文件直接存储在数据库中。但在这样的集中式数据库设计中，其他消费者并不能轻易使用刷卡行为的数据。因为访问数据库可能会影响欺诈检测系统的正常工作；在没有经过认真仔细审查之前，其他消费者绝不会被授权更改数据库。这将导致整个流程变慢，因为必须仔细地执行各种检查，以避免核心的业务功能收到破坏和影响。与传统相比，流处理架构下将欺诈检测器的输出发送给外部的消息队列，再由Flink更新数据库，而不是直接将输出发送给数据库，这使得刷卡行为的数据可以通过消息队列被其他服务使用，例如刷卡行为分析器。上一次刷卡行为的数据被存储在本地数据库中，不会被其他服务访问。这样的设计避免了因为增加新的服务而带来的过载风险。

基于流处理的微服务架构也带来了灵活性。假设开发团队正试图改进欺诈检测模型并加以评估。刷卡行为产生的消息流可以被新模型采用，而完全不影响已有的检测器。新增加一个数据消费者的开销几乎可以忽略不计，同时只要合适，数据的历史信息可以保存成任何一种格式，并且使用任意的数据库服务。此外，如果刷卡行为队列中的消息被设计成业务级别的时间，而不是数据库表格的更新，那么消息的形式和内容都会非常稳定。若一定要改，向前兼容可以避免更改已有的应用程序。

流处理架构通过一个合适的消息传输系统和一个多用途、高性能的流处理器，能支持各种应用程序使用共享数据源，即消息流。