标签：
- Kafka，Event Sourcing
目标受众：
- 目标受众：系统架构师
关注问题：
- 在以微服务架构为代表，分布式系统架构越来越成为主流的当下，如何保证不同限界上下文中数据的一致性一直是系统架构设计上的一个主要挑战。尤其是在只留存数据最终镜像（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一样简单。
Blip来源：
::Techniques (ASSESS[ 2017.11 | 2018.05 ])::
Event streaming as the source of truth | Technology Radar | ThoughtWorks
相关Blip
- EventStore | Technology Radar | ThoughtWorks
- Event Sourcing | Technology Radar | ThoughtWorks
- Domain-scoped events | Technology Radar | ThoughtWorks
- Capture domain events explicitly | Technology Radar | ThoughtWorks
- Apache Kafka | Technology Radar | ThoughtWorks
