流水线各阶段之间的数据契约:错误为何会在接缝处止步

大多数流水线是在中间悄悄出问题的。某个阶段产出的东西略有偏差，一个字段形状不对，一个数值溢出了，一个匹配存在歧义，而下一个阶段还是会尽力用它继续处理，因为拒绝往下走感觉比带着一个猜测继续前进更糟糕。等到有什么地方看起来不对劲时，后面已经有三个阶段建立在这个坏输入之上了，没有人能说清究竟是哪里出了岔子。Rexfin 的流水线建立在一个不同的假设上:各阶段之间的每一次交接都是一份契约，接收方阶段被允许，而且被期望，拒绝任何不符合契约的东西。

数据包是一份契约，不是一种期望

数据摄取不会把它的输出当作一堆松散提取出的数字直接交给下一个阶段。它会把一份文件产出的一切，事实分类账、引用片段、规范页面、把各项数字彼此关联起来的边图、一份记录该文件提取质量评分的报告，以及一份描述包内内容的清单，统统组装成一个单一的、按内容寻址的数据包。在这个数据包被发往任何地方之前，摄取阶段会依据一份它自己并不拥有的模式对其进行校验。如果数据包不符合规范，摄取阶段会拒绝生成它。它不会悄悄改造数据以使其凑合适配，也不会传出一个“差不多够格”的数据包然后让下一阶段自己去理清楚。此时的拒绝意味着这份文件需要再看一遍，而不是三个阶段之后出现一个无法追溯来源的错误数字。

另一边也会核查

接收数据包的阶段不会仅仅因为发送方声称已经校验过，就对其一致性照单全收。在数据包中的任何内容被当作新数据处理之前，它会在边界处针对同一份契约模式独立运行自己的声明式数据质量校验。一次交接经过双方各自独立检查，而不是单方假定合规，这才是一份被强制执行的契约，而不是一份被默认成立的契约的样子。如果摄取阶段自身的校验器出现了漏洞放行了某些东西，接收方就是第二道防线，而不是一个形式流程。

跨越这道边界的一些内容会因形状问题被拒绝，比如一个本应是有限数字的字段却不是，或者一个超出任何真实文件所会报告范围的数值;还有一些内容会因歧义而被拒绝:一个可能同时指向多个数字的引用锚点会被直接拒绝，而不是靠系统挑一个来“解决歧义”再抱着希望往下走。相互引用的递归结构会被限定在一个有界深度内遍历，而不是无限跟随下去，这样一个畸形或恶意构造的结构就无法把一次校验步骤变成一次死锁。

契约不仅关乎形状

一条记录可以形式上完全合规，却依然不值得信任。在一个提取出的数字被允许成为可引用的对象之前，在任何人能够指着它说这是一个事实之前，必须有多个独立的提取后端就它的内容达成一致。单一后端的读取结果，无论看起来多干净，都不足以单独作数，跨后端的一致性是一个数字从“已提取”变为“可用”之前必须满足的契约的一部分，这也是验证机制在核实总额是否真正对平时所依据的同一标准。

同样的逻辑把暂定数字和实际数字区分开来。提交进入 Rexfin 的一份预测或计划走的是自己独立的通道，拥有自己的存储、自己的写入路径，与验证和引用所依赖的原子数据在结构上被隔离开来。这类提交中任何试图声称自己已经是实际数据、已被引用、或已经过审计的内容都会被直接拒绝，而附加在一份计划上的保证等级是由系统自身盖章认定的，而不是照单接受发送方的说法。一份预测无法仅靠自称是已归档的数字就把自己伪装成那样的数字。

为什么拒绝优于修补

一个拒绝畸形输入而不是修补它的阶段，其失败方式也是你可以恢复的，这与该平台处理可靠性与灾难恢复的思路一脉相承:准确知道哪里坏了，把它隔离开，让其余一切继续运转。阶段之间的契约让这一点在接缝这个层级就能实现，而不仅仅是在整个系统的层级。

这适合谁

任何曾经遇到下游报告出错，花了一下午时间在三个系统里追溯一个坏数字，才终于找到问题出在哪里的人。Rexfin 的流水线被设计成让一条畸形记录在它跨越的第一道边界就被拒绝，并附带一个原因，而不是悄悄传播下去，直到变成一个出现在你原本信赖的页面上的错误数字。想了解各个接缝是如何衔接在一起的，请参阅总览页面,或预约演示现场看一次契约违规被实时拦截的过程。