Event streaming as the source of truth——历史永铭记、时间任穿梭 | 雷达哔哔哔

写在前面

ThoughtWorks每年都会出品两期技术雷达，这是一份关于科技行业的技术趋势报告，在四个象限：技术、平台、 工具 以及语言和框架对每一个条目（Blip）做采用、试验、评估、暂缓的建议。（第十九期雷达已发布， 可至官网下载 ）

一直以来，我们都未对每一个Blip做进一步的解读，而这次决定尝试一个新的专栏——《雷达哔哔哔》，由作者根据自己实践与理解，对雷达中部分条目作出解析，致力于用一篇篇短小精悍的文字，帮助读者加深对雷达的理解。

今天是《雷达哔哔哔》的第六篇，依然关注架构，Blip是 Event streaming as the source of truth 。

位置

2018年5月第18期技术雷达， 技术 象限，建议 评估

标签

Kafka，Event Sourcing，ETL，Integration

目标受众

系统架构师

关注问题

在以微服务架构为代表、分布式系统架构越来越成为主流的当下，“如何保证不同限界上下文中数据的一致性”一直是系统架构设计上的一个主要挑战。尤其是在只留存数据最终镜像（Snapshot）的数据持久化方案下。有没有一种方案可以让数据同步变得简单、可靠且可溯源可重建？这一直是系统架构师在思考和追寻的。

解决方案

将事件（Event）作为主数据源（Single source of truth），在上下文内则可以直接使用事件溯源（Event Sourcing）获取领域对象的最新数据快照，对外则可以直接使用类似于Kafka的工具通过事件的传递和广播进行不同上下文间的同样基于事件溯源（Event Sourcing）的数据同步和转换（ETL）。

解读

可能很多同学看到上述的问题描述和解决方案后，还没看到这就儿就已经走了……

这其实也可以理解，太多术语让人不知所云。什么Event、Sourcing、Source of Truth、Snapshot，感觉这些词就是为了架构师彰显身份创造的……

其实吧，很简单，我们做个比喻大家就都清楚了。就拿大家熟悉的Git举例子，Git就是一个就是基于事件（Commit）和事件溯源（Commit Chain）的好例子：

假设你有一份你的代码（数据），我有一份我的代码（数据），两份代码处理不同的事情。突然有一天我发现你的代码（数据）其中有一块我也能用，在通过一通“亲切友好”的沟(暴)通(揍)后，我把你的最新代码直接拷贝过来，放到了我的代码库里，并定时拷贝这块最新的代码过来，这就叫做同步（Synchronizing）。

后来我发现你的代码和我的代码还有一些不匹配，很多逻辑我并不用，只需要很少一部分，而且还得修改一下才能与我的代码对接，这就叫做ETL(Extract-Transform-Load)。

作为一个有追求的程序员，我为这个拷贝转换的过程（ETL）写了个程序，每天早上7点工作前自动完成。但是这就引入了一个新的问题，这个程序经常出问题（不要问我为什么……），导致我的代码（数据）和你的最新代码（数据）不一致，我需要知道我最新的代码是哪一次同步的、是否完整，以及如何重新同步代码到最新，这个过程就叫溯源（Sourcing）和重建（Rebuild）。

随着我同步的代码（数据）越来越多，如何保证这些来自不同源的代码（数据）始终保持时间一致性，可溯源，可重建就慢慢成为一件比较难的事情，也就是我上面提到的这个Blip关注的问题。

在代码拷贝这个场景里，Git给我们提供了另一种解决问题的思路。即我们不再保存我们的代码在某一个时间点的完整代码即代码镜像（Snapshot），而只是保存Commit信息，而一个Commit可以理解成就是一个事件（Event）。当我们需要最新代码的时候，不是从代码库里直接复制出最新的完整的代码版本，而是通过Commit链，从头开始将一个一个Commmit Apply到一起，最终形成了代码最新的样子，这个过程就叫做事件溯源（Event Souring），这样我们不仅记录了某个时刻的数据，而且记录了整个历史！

Event streaming as the source of truth，所描述的就是将这种基于Event存储方案应用于我们的系统数据管理，即用存储Event来代替存储数据现状快照，这样我们就可以基于Event和Event Souring处理数据的同时，大大简化和增强不同上下文数据同步的能力。

也就具备了Git般的威力，可以在数据的历史中穿梭，可以基于某个时间点做不同数据源的一致性同步，可以溯源，可以回滚，可以重建。而数据同步也会像Fork，Fetch，Merge一样简单。