技术项目和业务产品一样，如果一开始就设计得完美无暇，那实现起来也是艰难无比。倒不如先实现 MVP (Minimum Viable Product) 版本 ，再初步迭代完成升华。
下面就说说我在设计 Datamid 实时数据源接入的思考过程。
背景
Datamaid 是一个数据管理平台（忙忙碌碌做了好久，发现都没有写博客记录，有空还是要写一写，年纪大了脑子已经记不得踩过的坑）。在此之前，我们已经非常成熟地实现了离线数据的接入。通过配置 afs 地址和相关信息，我们会有物理机定期去拉取离线文件，再通过实体配置查询出实体的哪个字段使用了该 afs 文件的数据，通过灌数脚本完成数据的 T+ N(N为数据时效) 更新。
但是，实体身上并不只有离线字段。业务上很多字段都更倾向于使用实时数据。
那么在没开发实时数据管理之前，实体上的这些字段都是通过开发来完成。一般流程大概是：
- 上游数据源：提供消息队列的数据格式
- 下游研发人员：订阅消息，解析消息，更新数据
理想中的设计
通过上面的介绍，如果我们想接入实时数据源。最理想的情况莫过于如此：
- 上游数据源：提供消息队列的数据格式
我们设计一套数据解析系统，通过设计的 schema 描述格式，实现一个消息结构的分解。
用户在平台上填写格式配置，把数据接回。
这时候我们等于把 A 格式转变成了系统认识的统一 B 格式。
- 下游数据灌入：
组合上游数据，写入双索引（关于双索引，可以查看这篇：Datamaid 的双ES索引设计）
实际的实现
如果按照理想中的设计，可能做半个月也难以实现理想。
但通过”砍需求”，我们同样可以做出丐版的实时数据源接入！
技术项目就是好，咱自己就是产品经理，这个功能不好做，砍！
根据经验，我把实时数据源数据入库划分为了以下三步：
数据源数据解析，拿到你想要的数据
反查对方服务，获得最新数据（可省略，后面讨论）
拼装数据入库
那么我们的丐版方案，就是每次接入实时数据源。都写代码实现这三个步骤，就可以接入到 Datamaid 了。
要不要反查上游呢？
至于第二步，可以省略，采用第一步从消息里获得的数据作为入库数据。
但是我的建议还是去反查。只从消息里获得变更实体的 ID。
因为如果上游消息无法保证有序，或者是消息积压导致了延迟下发，直接入库可能会导致脏数据进入。而反查的思想就是，把消息仅仅当成一个“变更信号”，而不是当成“变更结果”。
通过变更信号我们知道 98号技师
请假了，则打电话问下茶楼是否还在？打电话获得的信息永远是最新最准确的，这时候我们入库更新的 98 号数据自然也不会造成不可预测的影响。
Adopting CC BY-NC-SA 4.0 License Agreement
