大数据与 AI 时代不仅给人们带来了生活上的便利，也给软件工程师、系统架构师、数据分析师带来了技术上的挑战。那么，如何在面临海量数据的情况下构 建一个健壮、可扩展、响应迅速的数据类应用，并且兼顾系统模型的灵活性？如果你也是一名被这些问题困扰的开发者，我想《事件流实战》会给你一些启示。
“事件”对于开发者而言是个熟悉的词，各种开发框架、编程语言中都或多或少有“事件”的概念，但很少有书籍谈及如何运用事件对系统建模。“流”的概念 亦是如此，计算机世界中充斥着各种流：输入输出流、网络流，还有最近几年出 现的流计算。而本书把事件与流的概念结合在一起，展示了一种崭新的架构；通 过流这种数据架构在系统之间传递事件，不仅解除了系统间的耦合，也为系统带 来了更好的扩展性，同时数据分析师可以自由地开展各种分析。
系统架构上不存在银弹，但基于事件流的架构设计让我们多了一种选择，它带来的特性与优势是之前传统架构所没有的。而使用事件流实现 Event Sourcing 这样的模式就非常简单且自然，能解决以往架构方案很难处理的问题。本书延续 了“实战”系列书籍的一贯风格，强调实战性，大部分示例来源于我们日常开发 中耳熟能详的场景。无论你是一位经验丰富的架构师，还是一个初出茅庐的开发 者，一定能从书中获得自己想要的答案。
《事件流实战》是一本全程关注事件的书籍，主要讨论如何定义事件，如何向 Apache Kafka、Amazon Kinesis 这类统一日志系统发送事件，以及如何编写一个处理流数据的应用程序。
《事件流实战》涵盖了以下技术的基础知识：Kafka、Kinesis、Samza 和 Spark Streaming 等流式处理框架，以及与事件处理契合的数据库(如 Redshift)。
节选自《事件流实战》一书
-----------------------------------------------图书基本信息------------------------------------------------------
书名： 《事件流实战》
ISBN:9787302559412
定价：98元
出版时间：2020年9月
京东链接：https://item.jd.com/12965562.html
内容简介：
Linkedln、Netflix等知名应用都通过实时响应用户和系统事件，来提高灵活度和响应速度。在大规模系统中，需要能高效地监控、管理和处理大量的事件流。
Kafka工具以及诸如统一日志处理的创新模式可帮助我们为基于事件的系统创建连贯的数据处理架构。
《事件流实战》讲解如何使用统一日志模式，来聚合、存储和处理事件流。在这本实用指南中，你将看到Lambda架构、流聚合和事件重放处理等重要的系统设计，还将看到扩展、弹性和高级流模式!读完本书，你将能设计出易于构建、部署和维护的由数据驱动的大型应用。
主要内容
校验与监控事件流
事件分析
事件建模
Apache Kafka与Amazon Kinesis的使用示例
------------------------------------------------------试读样章--------------------------------------------------------
第 1 章 事 件 流
无论你相信与否，真实世界中不间断的“流”与数字化事件已经对你所在的 公司产生了深远影响，只不过并不是像你同事设想的那样。相反，他们觉得自己 的工作是按照以下方式进行的：
每天和他人或其他事物(例如客户、市场团队)进行互动，提交代码或发布 一款新产品。
使用软件与硬件完成日常工作。
完成工作列表中的待办任务。
人类会按照上面的方式思考与工作，这与计算机是不同的。因为要在午餐时 间向老板提交报告，所以 QA 部门的 Sue 需要早起并工作。如果换一种思考方式， 假定我们的工作方式变为创建和响应一系列持续的、由事件组成的“流”，这对于 我们来说或许难以接受，因为很可能你会在休假期间被叫回办公室。
计算机对此却不会有任何问题，它们对以下业务定义会非常满意：
公司是一个能够产生和响应持续事件流的组织。 这样的定义并不是想从经济学家那里“要掌声”，但是作为本书的作者，我们 相信从持续事件流的角度来重塑你的业务模型会带来巨大收益。事件流会带来以 下这些特别的好处。
更加及时的洞察力——持续事件流犹如公司业务的“脉搏”，相比而言， 基于传统批处理的数据仓库就显得有些延滞。
观察事实的单一视角——对于你和你的同事们，相同的问题可能会具有不 同的答案。因为他们工作在数据的不同“点”上。一个建模良好的持续事 件流对于事实将提供单一视角，以此来消除歧义。
更快的反应——自动化、近实时的持续事件流处理流程使业务能在几分钟 (甚至几秒钟)内对事件作出响应。
更简洁的架构——大部分业务都建立在由杂乱的点对点连接的事务性系 统之上。而事件流可以帮助我们解开这些系统之间杂乱的耦合关系。
本章将首先探讨“究竟什么是事件”，将介绍一些事件的简单例子，也将解释 什么是持续事件流。这对于你来说是个很好的机会去发现这样一个事实：事件流 已经是你工作的一部分——只不过不是以你预想的那种方式存在。
在展示了一些耳熟能详的事件流后，将重点介绍在过去 20 年中企业是如何处 理事件的。你将看到，持续的技术演进是如何将一件简单的事情变得过于复杂， 而一种被称为统一日志的新架构模式，又是如何把事情化繁为简的。
新技术必须能解决那些棘手的用户问题，才能被主流所接受。因此我们将通 过各种行业的实际示例，让持续事件流和统一日志的优势显得更为真实。
1.1 术语定义
如果你在一个现代化的企业工作，那么很可能已经和各种形式的事件流打过 交道，只是从未意识到而已。接下来将展示事件的定义，以及事件是如何组成一 个持续事件流的。
1.1.1 事件
在我们定义什么是持续事件流之前，先明确单一事件的定义。幸运的是，这个 定义非常简单：事件是在某个具体时间观察到的发生的任何事物。如图 1.1 所示， 我们举了 4 个不同行业的“事件”示例。
由于事件的定义如此简单，很多时候可能会引起歧义。因此在进一步讨论之 前，我们先明确什么不是事件。下面并不是一份详尽的列表，但列出了应当避免 的最常见错误，一个事件绝不是以下列出的任何一项：
对某样东西持续状态的描述。如天气很温暖、这辆车是黑色的、客户端 API 崩溃了。但“客户端 API 在周二下午崩溃了”是一个事件。
经常发生的事。如纳斯达克(NASDAQ)每天上午 9:30 开盘。但是“2018 年某一天的纳斯达克开盘”是一个事件。 一系列单独事件的集合。如普法战争由施皮谢亨战役、麦茨攻城战以及色当战役组成。但是“法国与普鲁士于 1870 年 7 月 19 日爆发战争”是一个事件。
一个具体时间范围内发生的事情。如 2018 年的黑色星期五促销开始于 0 点，结束于晚上 11 点 59 分 59 秒。但是一个营销活动的开始是一个事件， 营销活动的结束同样是一个事件。
图 1.1 虽然在时间精度上并不完全相同，但可看到四个事件都是具体、可记录的， 发生于现实世界与数字世界(或两者兼而有之)
这里有个经验性的判断法则：如果在描述某样事物时，可将它和一个具体时 间点联系起来，就可以尝试用事件的形式描述它。有时可能需要组织一下语言， 让描述更通顺。
1.1.2 持续事件流
我们已经明确了事件的定义，那究竟什么才是持续事件流呢？简而言之，一 个持续事件流就是一连串不会终止、连续的单独事件，它们按照发生的时间先后 排序。图 1.2 从抽象的角度描绘了一个持续事件流的样子：可以看到一连串的单 独事件按时间顺序依次排列。
图 1.2 持续事件流的详细结构：时间与事件都是按自左向右的方向递进。事件流是 没有终止的，它的起始方向和终止方向都可能超出我们能够处理的范围
基于以下原因，我们称这一系列事件是不会终止的：
流开始的时间可能早于我们开始观察的时间。
流可能在未来某个不确定的时间终止。
为说明这一点，我们以客人入住日本 Hoshi Ryokan 旅馆的场景为列。Hoshi Ryokan 旅馆创建于公元 718 年，被认为是世界上最古老的旅馆之一。当在分析客 人入住的事件流时，你会发现最早的那些客人入住事件已经随着时间的流逝，不得而知。未来客人入住的事件会一直持续发生，直到我们退休都不会终结。
1.2 探寻我们熟悉的事件流
如果阅读了上一节，你觉得事件和持续事件流的概念似曾相识，那你很有可 能已经使用了事件流的相关技术，只是未将它们辨识出来。大量的软件系统受到 持续事件流的影响，包括：
交易系统——大部分这类系统需要响应外部事件，例如客户下单或供应商 交付货品。
数据仓库——从其他系统中收集事件的历史信息，并稍后在因子表中对它 们进行分析和排序。 系统监控——从软件或硬件设备持续地检查系统级别和应用级别的事件， 以此监测异常。
站点分析——通过分析网站访问者的行为事件流，分析师可形成相关的 观点。
本节将介绍三个最常见且最接近事件流概念的编程领域。希望这能让你更多 地从事件的角度来思考现有的编程工具。但如果这些例子对你而言有些陌生，也 不必担心，之后你将有大量机会从无到有地掌握事件流。
1.2.1 应用级日志
让我们首先讨论大部分后端开发者和前端开发者都熟悉的“应用级日志”。如 果你曾用过 Java，那么很可能也用过 Apache Log4j；如果没有，也不必担心，它 与其他日志工具非常类似。假设 Log4j.properties 文件配置完成，而一个静态的日志记录器也已被成功初始化，那么使用 Log4j 相当容易。代码清单 1.1 展示了一 个 Java 开发者如何使用它在应用中记录日志。
代码清单 1.1 使用了 Log4j 的应用日志
doSomethingInteresting(); log.info("Did something interesting"); doSomethingLessInteresting(); log.debug("Did something less interesting");
// Log output: // INFO 2018-10-15 10:50:14,125 [Log4jExample_main] "org.alexanderdean.Log4jExample": Did something interesting // INFO 2018-10-15 10:55:34,345 [Log4jExample_main] "org.alexanderdean.Log4jExample": Did something less interesting Listing
1.1 Application logging with Log
可以看到应用级日志常用来在某个时间点记录特定事件。记录日志事件的代 码非常基础，仅记录了事件的重要等级，以及用来描述事件的消息字符串。但是 Log4j 也额外添加了一些元数据，包括事件发生的时间、记录该事件的线程以及 对应的 Java 类。
当你的应用产生日志事件后，应该做什么呢？最佳实践告诉我们，应该将日 志事件写入磁盘上的一个日志文件。然后使用日志收集技术(如 Flume、Flunted、 Logstash 或 Filebeat)将这些日志文件从不同服务器上收集过来，并进行汇总，用 于后续的系统监控和日志分析。图 1.3 说明了这种类型的事件流。
图 1.3 一个运行在两台服务器上的应用，每个应用实例都会生成日志信息。日志信息 在被循环写入本地磁盘后，由日志收集器转发给系统监控或日志分析工具
很明显，应用级别的日志是一个持续事件流，只是它很大程度上依赖于无模 式的消息结构(而这种通常是人类可阅读的)。就像 Log4j 示例中所展示的，应用级 日志是高度可配置的，并没有跨语言和框架的标准配置。在一个多编程语言的项 目中，通用日志的标准化是一项令人痛苦的工作。
1.2.2 站点分析
让我们来看下一个例子。如果你是一个前端 Web 开发者，那么在网站或网站 应用中嵌入 JavaScript 来进行一些 Web 或事件分析是自然而然的事。在这类软件 中，最受欢迎的是一款由 Google 提供的“软件即服务”(SaaS，Software-as-a-Service) 软件，Google Analytics。2012 年，Google 发布了新一代的分析软件，即 Universal Analytics。
代码清单 1.2 展示了通过 JavaScript 调用 Universal Analytics 的示例。这部分代 码可以直接嵌入站点的源码中，或通过一个 JavaScript 标签管理器来调用。无论哪 种方式，当任何一个网站访问者访问站点时，这段代码都会被执行，用来产生一个 持续的事件流，代表访问者与站点的交互行为。这些事件最终会流向 Google，然后 被存储、处理并展示在不同的报表上。图 1.4 展示了整个事件流程。
代码清单 1.2 通过 Universal Analytics 服务进行网站追踪
通过这样部署 Google Analytics，业务分析师可以登录到 Google Analytics，通 过站点提供的界面入口，了解所有网站访问者的事件流。图 1.5 是 Universal Analytics 实时数据仪表盘的截图，它展示了过去 30 分钟 Snowplow Analytics 网站 所发生的事件。
1.2.3 发布/订阅消息 让我们看一个更底层的例子，也许仍是很多读者所熟悉的内容：应用程序消 息，特别是发布/订阅模式的消息。发布/订阅有时简称为 pub/sub，是一种简单的消息通信方式。
消息的发送者(sender)可以发布(publish)消息，消息可能属于一个或多个主 题(topic)。
消息的接收者(receiver)可以订阅(subscribe)特定的主题(topic)，之后便可收 到所有订阅主题的消息。
如果曾经使用过 pub/sub 发送消息，那很有可能发送的就是某种形式的事件。
让我们动手尝试一下 NSQ。NSQ 是一个颇受欢迎的分布式 pub/sub 消息中间 件，最初由 Bitly 创建。如图 1.6 所示，NSQ 在一个消息发布应用和两个消息订阅 应用之间进行事件代理。
使用 NSQ 进行演示的优点在于，它易于安装和使用。在 macOS 中，我们只需要 打开一个终端窗口，使用 Homebrew 进行安装，然后启动 nsqlookupd 守护进程即可：
$ brew install nsq
...
$ nsqlookupd
...
然后在另一个终端窗口中，我们启动 NSQ 的主进程 nsqd：
$ nsqd --lookupd-tcp-address=127.0.0.1:4160
...
我们让之前的两个守护进程保持运行，并打开第三个终端窗口。我们使用 nsqd 提供的 HTTP API 创建一个新的主题：
$ curl -X POST http://127.0.0.1:4151/topic/create\?topic\=Topic1
接着开始创建两个新的订阅者，应用 2 和应用 3。再打开两个新的终端窗口， 运行 nswq_tail 来模拟应用 2 和应用 3 订阅 Topic1：
$ nsq_tail --lookupd-http-address=127.0.0.1:4161 \
--topic=Topic1 --channel=App2
2018/10/15 20:53:10 INF 1 [Topic1/App2]
querying nsqlookupd http://127.0.0.1:4161/lookup?topic=Topic1
2018/10/15 20:53:10 INF 1 [Topic1/App2]
(Alexanders-MacBook-Pro.local:4150) connecting to nsqd
然后打开第五个，也是最后一个终端窗口：
$ nsq_tail --lookupd-http-address=127.0.0.1:4161 \
--topic=Topic1 --channel=App3
2018/10/15 20:57:55 INF 1 [Topic1/App3]
querying nsqlookupd http://127.0.0.1:4161/lookup?topic=Topic1
2018/10/15 20:57:55 INF 1 [Topic1/App3]
(Alexanders-MacBook-Pro.local:4150) connecting to nsqd
回到第三个终端窗口(唯一没有运行守护进程的窗口)，我们通过HTTP API 发 送一些事件：
$ curl -d 'checkout' 'http://127.0.0.1:4151/pub?topic=Topic1'
OK%
$ curl -d 'ad_click' 'http://127.0.0.1:4151/pub?topic=Topic1'
OK%
$ curl -d 'save_game' 'http://127.0.0.1:4151/pub?topic=Topic1'
OK%
在运行应用 2 的窗口中可以看到事件到达的信息：
2018/10/15 20:59:06 INF 1 [Topic1/App2] querying nsqlookupd
http://127.0.0.1:4161/lookup?topic=Topic1
checkout
ad_click
save_game
在应用 3 的窗口中，也会看到相同的信息：
2018/10/15 20:59:08 INF 1 [Topic1/App3] querying nsqlookupd
http://127.0.0.1:4161/lookup?topic=Topic1
checkout
ad_click
save_game
在 pub/sub 架构中，我们的事件由一个应用发布，并被其他两个应用所订阅。 只要添加更多事件，就会获得一个被不断处理的持续事件流。
希望本节的例子可以让你意识到事件流是一个熟悉的概念，支持不同的系统 和解决方案，包括应用级日志、站点分析和发布/订阅消息。所采用的技术也许不 同，但从上述三例中可以看到相同的部分：事件的模式或结构(即使很少)、事件 的生成方式、事件的收集以及后续处理。
1.3 统一持续事件流
到目前为止，本章介绍了事件流的概念，定义了所使用的术语，并突出了我 们所熟悉的某种技术中是如何使用事件流的。这是一个良好开端，但你也应该看 到，这些技术的应用是碎片化的：它们的事件特性并不容易理解，它们的事件模 式并不是标准化的，而且它们的应用场景散落在各处。本节将介绍在业务中使用 持续事件流的更为先进和强大的方式。
简而言之，本书的观点是任何数字化业务都应该按照以下流程重新组织。
从各个不同的源系统收集各种事件。
将事件存储在一个统一日志中。
让数据处理应用可以在这些事件流上运行。
这是个大胆的主意，而且听起来有一大堆工作要做。那有什么证据表明这是 一个对企业实用而有效的解决方案？
本节描述了业务数据处理的历史和发展历程，并把话题扩展到事件流和统一 日志。我们将演变过程分为两个截然不同的时代，我们有第一手的经验，同时也 将迎来第三个崭新的时代。
古典时代——“大数据、SaaS 时代”之前的业务系统和基于批处理作业的数据 仓库。
混合时代——现如今的由不同系统和不同解决方案组成的“大杂烩”。
统一时代——新兴的架构，通过在统一日志中处理持续事件流。
1.3.1 古典时代
在古典时代，企业需要运维一整套本地部署的不同交易系统，并将数据灌入 数据仓库。图 1.7 展示了这种架构。每个交易系统都具有如下特点：
一个用来执行准实时数据处理的内部回路。
具有自己的数据筒仓。
在需要时，和对等系统进行点对点连接(通过 API 或 Feed 导入/导出)。
数据仓库通常在夜间通过一系列的抽取、转换和加载(ETL)，从各个交易系统 获取数据。因此数据仓库为企业提供了对于真实状况的单一视角，不仅具有完整 的数据历史，还具有广泛的覆盖范围。在内部，数据仓库通常采用由 Ralph Kimball 推广的、基于因子表和维度表的星型模型。
虽然我们称之为古典时代，而且有越来越多的 SaaS 被引入，但实际上现今仍 有大量企业采用这种架构或由其衍生的架构。这是一个久经考验的架构，但它仍 具有以下缺陷：
滞后的报表——事件发生到出现在报表中的事件跨度以小时计(甚至以天 计)，而不是以秒计。
点对点的“意大利面条”结构——新增的交易系统会带来更多点对点连接， 如图 1.8 所示，这种点对点的“意大利面条”结构带来了昂贵的构建和维 护成本，同时增加了系统整体的脆弱性。
模型困境——传统的数据仓库假设每个企业都可从业务系统中挖掘出一个稳 定的数据模型，但正如我们将在第 5 章中所看到的，这是一个有缺陷的假设。
在面对这些问题时，有些企业完成了到新模式的飞跃，特别是零售、技术和 媒体这些飞速发展领域的企业。我们把这个新模式称为混合时代。
1.3.2 混合时代
混合时代的一大特点是企业维护着一堆由交易系统和分析系统组成的大杂 烩。它们有的来自私有部署的商业软件，有的来自某个 SaaS 供应商，而有的是自 己研发的软件系统。图 1.9 展示了一个混合时代架构的示例。
很难用寥寥数语概括混合时代的架构。同样，混合时代的架构存在很严重的 “本地循环”和“数据孤岛”的问题，但仍有一些试图使用 Hadoop 或系统监控技 术“记录所有事情”的尝试。对于狭义的分析场景，例如产品推荐，往往倾向于 混合使用准实时处理技术，此外将数据批处理的工作从数据仓库剥离，转而由 Hadoop 处理。混合架构还会从 SaaS 系统中批量导出数据并放入数据仓库，同时 通过这些 SaaS 系统自有的 API，提供它们所需的专有数据。
尽管这种混合的解决方案弥补了经典解决方案中的一些不足，但也带来了自 己特有的问题。
缺乏对真实状况的单一视角——基于数据量的大小和分析时效性的要求，数 据被仓储在多个不同的系统。因此没有哪个系统的数据是 100%完整可见的。
决策变得支离破碎——系统本地处理与数据孤岛的数量较古典时代有增 无减。这让基于数据的准实时决策变得脆弱。
点对点交互数量激增——随着系统数量的增加，系统间点对点交互的数量 呈爆炸性增长。其中的许多交互是脆弱或不完整的，从外部的 SaaS 系统 中获取精确及时的数据变得极具挑战。
分析的实时性与数据覆盖性不能兼得——当以低延迟执行流处理时，实际 上就变为一个本地处理程序。数据仓库的目的在于更广泛的数据覆盖范 围，但带来的代价就是数据的冗余和高延迟。
1.3.3 统一时代
这两个时代把我们带到了今时今日，也带来了新兴的数据处理的统一时代。 关键的创新就是将统一日志作为我们所有数据收集与处理的核心。统一日志 (unified log)是一个只可追加的日志，系统中产生的所有事件都会写入其中。此外， 统一日志还具有如下特性：
支持各种低延迟的读取要求。
支持多个不同系统同时读取，不同的系统可以按照自己的速率读取日志。
仅保留一个“时间窗口”内的事件——可以是一周也可以是一个月。但可以将 历史数据归档在 Hadoop 分布式文件系统(Hadoop Distributed File System， HDFS)或 Amazon S3(Simple Storage Service，简单存储服务)中。
现在，先不要担心统一日志的实现机制，第 2 章会深入介绍这方面的细节。 目前，最重要的是要理解统一日志在企业中是如何重塑数据处理流程的。图 1.10 将零售商的系统架构更新至统一时代，新架构遵循以下两个简单规则：
所有软件系统都可以且应该将它们各自的持续事件流写入统一日志。即使是 第三方的 SaaS 供应商也可通过 webhook 和流 API 发布事件。
除非有低延迟或事务保证的要求，否则各个系统只能通过统一日志以松耦 合的方式进行交互，绝不能通过点对点的方式。
与之前的两种架构相比，统一日志具有如下优势：
对真实状况的单一视角。统一日志加上 Hadoop 的归档数据代表了对于真 实状况的单一视角。它们包含了相同的数据(事件流)，但处于不同的“时 间窗口”中。
对真实状况的单一视角处于数据仓库的上游。在古典时代，数据仓库提供 了对真实状况的单一视角，使得基于它产生的所有报表均保持一致。在统 一时代，统一日志提供了类似的单一视角。因此，业务系统(例如推荐系 统、广告目标定位系统)和分析师制作管理报表都是基于相同的数据。
点对点的交互数量大大减少。取而代之的是系统可对统一日志进行追加操 作，而其他系统则可读取追加的日志数据，如图 1.11 所示。
本地循环可以打破“数据孤岛”的限制。系统可以通过统一日志进行准实 时的协作，并做出决策。
1.4 统一日志的应用场景
阅读前几节后，你可能会认为“持续事件流与统一日志看上去的确很不错， 但它似乎是一种架构上的优化，而非用于实现一个全新系统”。事实上，它不仅是 针对之前解决方案在架构上的巨大进步，还推动了全新应用场景的出现。本节将 展示三个能引起你兴趣的应用场景。
1.4.1 用户反馈环路
持续数据处理最令人激动的应用场景之一就是当每个不同的客户在使用服务 时，能对他们的行为做出不同响应。针对你所从事的不同行业，这种实时反馈回 路的表现可能有所不同。下面是一些具体例子：
零售业——无论何时，当消费者准备弃置购物车时，浏览器会弹出带有优 惠券信息的窗口，以吸引他们付款。图 1.12 展示了这样一个例子。
电视业——基于用户当前的行为和历史观看记录，实时调整在线节目的收 视指南，以使客户的观看时间最大化。
汽车业——检测到异于平时的驾驶行为时，通知车主汽车是否被盗。
游戏业——如果玩家发现四人合作游戏太具挑战性，调整难度级别以防止 他们退出从而破坏其他玩家的游戏体验。
用户反馈回路并不是新鲜事物。即使是在古典时代，你同样可以通过获取用 户的行为数据来发送线下邮件或电子邮件进行市场营销。时至今日，一些创业公 司会在你浏览的网站上放置 JavaScript 代码，实时跟踪用户的行为，并通过页面 横幅、Flash 消息和弹出窗口来影响用户的行为。但是统一日志的使用让反馈回路 的功能更为强大：
它们完全处于服务供应商(而非第三方供应商，例如一个基于 SaaS 分析的供 应商)的控制之下，这意味着可以尝试各种能提升业务的算法。
驱动反馈的模型是基于完全相同的事件流完整归档数据测试的。
用户对于反馈回路的反应同样可以被添加到事件流中，以便后续能够进行 机器学习。
1.4.2 整体系统监控
对软件和服务的可用性监控是一项棘手的工作，因为用于检测和预防的指标 分散在各处：
系统的监控数据会放入第三方服务，或企业自己部署的时间序列数据 库中。出于网络传输与存储的考量，需要在存储前对数据预先进行聚 合和采样。
应用日志消息在服务器关闭或宕机之前，应同日志文件一样被写入应用服 务器并完成收集。
客户事件被发送至第三方服务，因此无法对这部分客户数据进行细粒度和 实例级的分析。 有了统一日志后，所有系统问题都可以通过检查存放在统一日志中的事件流 数据来解决。并不需要专门为了系统监控将所有数据存放在统一日志中。系统管 理员可浏览任何数据，从而识别问题之间的相关性，并以此查找问题的根本原因。
图 1.13 展示了一个移动应用的整体监控示例。
1.4.3 应用系统版本在线升级
我们之前曾提及，统一日志可同时被多个不同的应用系统读取，而且不同的 应用系统可按自己的速率读取统一日志。每个使用统一日志的应用系统可以独立 地跟踪已经处理了哪些事件，并决定之后处理的事件。
假定我们有多个相同的应用系统从统一日志读取事件，那么紧接着的问题是 也会有同一应用的不同版本从统一日志处理事件。这非常有用，因为它允许我们 对数据处理系统进行热替换(hot swap)——在线升级应用系统而不需要脱机。在当 前版本的应用系统仍在运行时，可执行以下步骤：
启动新版本的应用系统，从头开始处理统一日志。
让新版本的应用系统跟踪旧版本系统处理日志的位置。
将用户接入新版本的应用系统。 关闭旧版本应用系统。
图 1.14 展示了如何将旧版本的应用系统在线升级为新版本。
每个应用系统(或不同版本的应用系统)可维护各自游标位置，这种能力非常有用。除了可在不停机的状态下对应用系统升级之外，还能利用这种能力做如下事情：
在实时事件流上测试应用系统的新版本。
将不同算法的结果在同一事件流上相互比较。
让不同用户使用不同版本的应用。
1.5 本章小结
事件是可以在特定时间点观察到的任何事物。
连续事件流是一系列不会终止的个体事件，这些事件按照发生时间进 行排序。
事件流的概念对大量软件系统产生了深远影响，包括应用级日志、站点分 析和发布/订阅消息。
古典时代的数据处理方案中，业务操作散布在各个私有部署的系统中，并 将数据写入数据仓库中。这些系统存在的问题是：高数据延迟，严重的数 据孤岛，大量的系统间点对点交互。
在混合时代的数据处理解决方案中，业务操作发生在一个混合了交易与分 析系统的大杂烩架构中。虽然仍存在数据孤岛的问题，但尝试通过 Hadoop 和系统监控的方式来“记录所有日志”。
在统一日志时代，建议企业围绕一个只可追加的日志重新构建应用，而这 些应用负责向日志写入产生的事件。
统一日志架构的应用场景包括用户反馈回路、整体系统监控和应用系统版 本热替换。
想了解更多关于《事件流实战》内容，请点击：