纽约时报Kafka架构实战.docxVIP

纽约时报Kafka架构实战 我们即将引见的是一种基于日志的架构。Martin Kleppmann在“Turning the database inside-out with Apache Samza”中提到了这一架构方案，后来在“Designing Data-Intensive Applications”中有了更为具体的描述。“Log: What every software engineer should know about real-time datas unifying abstraction”则提到了将日志作为一种通用的数据结构的说法。对于我们来说，我们的日志就是Kafka，全部发布的内容依据时间挨次添加到Kafka主题上，其他服务通过消费日志来访问这些内容。 传统的应用使用数据库保存数据，虽然数据库也有很多优点，但从长远来看，管理数据库会成为一种负担。首先，变更数据库schema就很麻烦。添加或移除字段并不难，但这些变更需要以暂停服务为代价。我们也无法自在地更换数据库。大部分数据库不支持流式变更，虽然我们可以获得数据库快照，但这些快照很快就会过时。也就是说，我们难以创建衍生存储，比如搜索引擎使用的索引，由于索引里必需包含全部文章内容，而且一旦有新内容发布就要重建索引。虽说我们可以让客户端同时将内容发送给多个存储系统，但这样仍旧无法处理全都性问题，由于有的写入会失败。 从长远来看，数据库最终会变成一个简单的单体。 基于日志的架构可以处理这些问题。一般来说，数据库保存的是大事的结果或形态，而日志保存的是大事本身。我们可以基于日志创建任何我们想要的数据存储，这些数据存储就是日志的物化视图，它们包含的是派生的内容，而非原始内容。假如要更改数据存储的schema，只需创建一个新的数据存储，然后从头到尾再消费一遍全部的日志就可以了，然后把旧的数据存储扔掉。 一旦使用日志作为现实的来源，就没有必要再使用中心数据库了。每一个系统都可以创建属于本人的数据存储，或者说物化视图，它只包含该系统所必需的数据，而且为该系统供应了特定的格式。这就简化了数据库在架构中的角色，更贴合每一个应用的需求。 另外，基于日志的架构也简化了访问内容流的方式。对于传统的数据库来说，访问整个数据转储（比如快照）和访问“实时”数据（比如种子）是两种不一样的操作。而对于日志来说，它们并不存在差别。你可以从任意的偏移量处开头消费日志，从起始位置也好，从两头开头也好，甚至从末尾也可以。也就是说，假如你要重新创建数据存储，只需依据需要重新消费日志即可。 基于日志架构的系统在部署方面也有很多优势。在虚拟机里进行无形态服务的不变模式部署已经成为一种常见的方式。重新部署整个实例可以避开很多问题。由于有了日志，我们现在可以进行无形态系统的不变模式部署。由于我们可以从日志中重新创建数据存储，所以每次在部署变更的时候都可以获得新的数据存储。 为什么Google的PubSub或AWS SNS/SQS/Kinesis无法处理这些问题 Kafka一般有两种应用场景。 Kafka常被用作消息代理，用于数据分析和数据集成。Kafka在这方面有很多优势，不过Google PubSub、AWS SNS/SQS/Kinesis也能处理这些的问题。这些服务都支持多个消费者和多个生产者，可以跟踪消费者的消费形态，消费者在宕机的时候不会消灭数据丢失。在这些场景里，日志只是消息代理的一种具体实现而已。 但在基于日志的架构里，情况就不一样了。这个时候日志就不只是单纯的实现细节那么简约了，而是变成了核心功能。我们有以下两点需求： 我们需要通过日志永久地保留全部大事，否则就无法任凭创建我们需要的数据存储。 我们需要依据肯定挨次消费日志，由于乱序处理关联性大事会得到错误的结果。 目前也只要Kafka能够满足这两个需求。 Monolog Monolog是我们的新内容发布源，其他系统把创建的内容以追加的方式写到Monolog。创建的内容在进入Monolog前会经过一个网关，网关会检查流经的内容能否符合我们定义的schema。 Monolog里包含了自1851年以来发行的全部内容，它们依据发行时间进行排序。也就是说，消费者可以从任意时间点开头消费这些内容。假如需要消费全部的内容，就从头开头（也就是从1851年开头），或者依据需要只消费那些更新过的部分。 举个例子，我们有一个服务担任供应内容清单，比如某个作者发布过的内容、与某个科学主题相关的内容，等等。这个服务会从起始位置开头消费Monolog，然后构建内容清单。我们还有另外一个服务，它只供应最新发布的内容清单，所以它不需要永久的数据存储，它只需要过去几个小时的日志数据。它会在启动的时候消费最近几个小时的日志，并在内存里维护一个最新内容的清单。 我们依据规范化方式将内容