HomeAway 用事件溯源解决大数据迁移

HomeAway数据架构师 Adam Haines 最近在Data Architecture Summit 2018大会上介绍了他的团队如何使用事件溯源云设计模式来加速其组织中的大数据项目。

像类似事件溯源的数据架构模式可以帮助解决迁移到云环境后团队面临的新挑战。这些挑战包括最终一致性、遗留服务依赖、弹性扩展以及不可靠的网络。事件溯源通过将数据存储为一系列领域状态变更，来改变数据存储的范式。数据就像服务可以使用的日志一样存储。

他们云迁移的主要目标是最小化云平台的技术负债。他们面临着数据架构方面的挑战，比如有限的事件回放、可审核性较小、到处都有的数据拷贝、有限的可发现性和沿袭性、数据飘移以及一些弹性挑战。

事件溯源是基于不可变的日志变更，并提供最大程度的可审核性。它会带来最终一致性、事件迭代和数据增长这样的挑战。

他还提到其他与事件溯源紧密相关的设计模式，命令查询职责分离（CQRS）分离了读和写的关注点，保证应用程序和服务能独立扩展。

在 HomeAway，事件溯源解决方案包括实践规范化、捕捉 delta 变更（改变数据捕捉）、每条消息“仅有一个”语义，保证排序和分块服务。

他们还使用Strangler模式成功地实现了向云的增量迁移、资产捕捉、事件重定向以及路由请求。

InfoQ 采访了 Adam Haines，向他了解了有关事件溯源模式、在组织中使用它获得的教训以及他推荐的实践。

InfoQ：你可以介绍一下为什么事件架构在事件溯源解决方案中如此重要吗？

Adam Haines：事件架构很重要，因为这是以数据为中心或以应用程序为中心的基础。只要数据是由编写它的服务所决定的，我们在数据民主化的道路上就更进了一步。每个事件都应该非常细粒度，绑定到现实世界的事物。比如说，预约并不是件实物，而由一系列大家皆知的特征/属性组成，我们为了方便给它下了这个简单的定义。预约包括人、入住日期、离店日期、所有权、价格等等。如果我们的工作做得不错，那么编写事件的服务/平台/功能就无关紧要了，因为预订域已经可以与所有其他平台和服务互操作。这就是以数据为中心的体系结构的本质。

InfoQ：事件溯源有什么好处和挑战？

Haines：

好处：事件源允许服务分离它们的读写关注点，并真正允许服务封装数据。具有完整的封装不仅可以防止死星架构，还可以降低每个微服务的集成成本。事件源架构的最大优势之一是数据民主化。在体系结构的中心拥有数据可以让服务很容易地发现和订阅，这对于开发人员开发速度和实现接近实时的体验至关重要。事件源也为基于模式的编程打开了大门。如果已经设置好了模式和库，那么目标应该是让一个入门级的工程师执行开发生命周期，而不需要太多的提升或培训的时间。事件源提供了一个很好的审计跟踪，因为整个历史是持久的，这使得审计和可视化发生的事情非常容易。我认为这是一个非常关键的方面，因为服务变得更加异步，客户需要实时更新或反馈他们的事务状态。

挑战：由于本质上过去十年我们一直在编程，所以一直期望读自己写的东西。尽管我们认为读写分离是有益的，但同时它也存在着问题。有了事件溯源模型，软件工程师现在需要考虑幂等运算，以及如何处理不一致的结果。另外一个挑战是数据增长。事件溯源启动很快，也很容易，这是因为数据很少，所以速度会很快。很明显，随着数据的增长，存储空间以及返回当前状态需要的时间也会增长。我认为重要的是要有一个策略(恢复和/或快照)来最小化回放的成本和影响。

InfoQ：你可以介绍一下 HomeAway 的事件溯源架构吗？

Haines：HomeAway 转换到事件溯源的架构之后确实提升了架构的灵活性和弹性。从消息架构开始还有很长的路要走（我们还在努力），然而我们发现数据需要成为我们工作的中心。我们编程的方式需要更灵活、更适应。第一步是让数据的消费和生产变得简单。我们的目标是将事件放在业务的核心。事件和事件溯源给我们提供了更强大的洞察力、更多的灵活度以及更好地使用云的能力，同时帮我们降低了遗留数据中心服务的危害。

InfoQ：你们的解决方案中使用了什么技术？

Haines：HomeAway 的事件溯源主要使用了两种技术：Kafka 和 Photon。Photon 是高度分布式写优化事件溯源平台，在内部创建来解决事件溯源的挑战。

我想要重点声明的一点，技术选择的优劣其实是未知的，然而，这不是说没有权衡。我的目标是制定事件溯源模式的根本，这决定了技术选择的利弊。这表示，在决定选择什么技术来支持事件溯源的时候需要慎重考虑。不是所有的持久性都是一样的，也不是所有的平台都像数据库一样能提供相同的属性或保障。

InfoQ：你在演说中提到了 Strangler 模式。你可以介绍一下你的团队在开发事件溯源架构的时候是怎么使用这个模式的吗？

Haines：在我们迁移云计算之旅中，数据工程团队在很早阶段就意识到服务和数据库集成得如此紧密，几乎不可能分开。

我们需要解决的问题是如何迁移。我们需要找到一个方法，从遗留平台中得到突变事件，并把它们放到云上。

最简单的方法是使用变化数据捕获（CDC）流。CDC 流可以让我们的服务订阅遗留系统的突变事件，并放到目的地。

由于存储内容和存储方式的性质，决定了唯一的选择就是事件溯源。事件溯源允许我们以数据为中心来看待世界。在其中云服务或变化数据捕获是否写了事件并不重要，因为每个服务都在写相同的内容。

在研究了 Strangler 模式之后，我们意识到了事件的价值和力量。这时我们真正开始推行了事件溯源，让公司变得更加以数据为中心。

他还谈到了 CQRS 和事件溯源模式协同工作，以使系统变得更加有弹性。

命令查询职责分离（CQRS）是事件溯源交付价值和实现云规模的重要环节。CQRS 实际上是关于读写服务的分离。通过解耦这些服务，帮助我们独立地扩展读和写，并增加了弹性层。在传统的微服务世界中，服务可能委托给其他的微服务，然而，这是以集成成本为代价的，并对弹性造成负面影响。HomeAway 使用 CQRS 来真正提供和封装数据，因此服务丢失的影响会很小。在大多数情况下，最糟糕的情况是潜在的数据，这会让服务比停机状态更糟糕。在云中，人们预期看到的就是服务和资源增增减减、起伏不定。云并不像数据中心这么稳定，事件溯源+CQRS 可以帮助我们最小化这种风险。

查询层（CQRS 中的 Q），我们发现最好用图来表述，因为这样可以更好地探索跨领域的数据，这通常是封装微服务和业务对象的需求。

查看英文原文：Event Sourcing to the Cloud at HomeAway