8.6　业务一致性平台

在淘宝平台进入服务化时代后，偶尔还是会遇到远程服务调用失败，数据库保存失败，MQ消息发送失败这样的情况，从而导致丢失数据或者各服务中心数据不一致。在双11大促期间，这样的问题出现的次数和造成的影响更让业务人员如坐针毡。也发现过应用在运行过程中，即使服务调用都没有任何报错信息，但由于程序设计自身逻辑理解的问题，导致业务数据异常的情况。试想一下，一个用户刚刚在双十一活动中下了一个订单，在下单的过程中使用了“扣减10元”的优惠券，并完成了付款操作，但因为某一个模块的逻辑中因为没有实现对优惠券的扣减，造成实际支付宝付款时并没有扣减这优惠的10元，从而造成多扣了用户的金额。如果发生这样的情况，有可能在大量用户投诉之后，应用开发人员才从客户服务部门收到反馈，或许这已经是问题出现一个小时之后的事了。

面对这些业务与数据不一致的问题，业务稳定性保障迫在眉睫。要解决这个问题，就需要在实现业务处理的过程中，实时检测到业务不一致的问题，在消费者发现该问题之前系统就应该发出了报警，并且已转交相关技术人员处理。也许，在用户开始投诉的时候，这个问题就已经纠正过来，这样的话影响的用户范围就很小了。

在这样的背景下，实时业务审计平台（Business Check Platform，BCP）应运而生，这个平台采用规范与标准化业务规则的方式，统一解决平台服务化后越来越凸显的业务一致性问题，解放业务人员那颗悬着的心。

BCP平台并不仅限于交易类业务，也适合其他对业务稳定性要求比较高的领域。平台的目标是在每个上线的业务都能形成一对一的监控与检测，并形成一个规范的业务上线、订正流程。BCP平台实现了以下4个主要目标：

1）高实时性地发现业务脏数据或错误逻辑实现，第一时间发现并及时通知技术保障人员，而不是等客户反馈。

2）方便地接入各种业务规则，通过脚本规则编写的方式，让各应用快速接入业务审计平台。

3）整合订正工具，形成规范的赃数据订正流程。

4）业务上线的实时监控，新上线业务可以很方便地进行校验。

要实现业务的实时审计并不简单，如果是在应用层上进行业务规则的判断，一方面会对应用有非常大的代码侵入，很难灵活地进行业务规则的修改；另一方面也会对应用的性能产生影响，因为原本只是业务校验的代码执行进入到了业务处理的流程中。为了更高效率地让应用快速接入业务审计平台，同时减少对应用带来的代码侵入以及性能的影响，BCP平台通过事件模式，把业务数据变化触发的消息（如精卫、MQ等平台消息）转换为相应业务类型的事件，放入到事件执行队列进行规则检查，BCP提供了通用的事件监听框架，实现了与MQ（消息服务）对于数据库的对接，是对于数据变更的日志信息接入到了BCP平台中，如图8-13所示。

图8-13　BCP平台功能定位

类似于传统的规则引擎运行流程（如图8-14所示），当从数据源生成相关消息发送到业务规则平台所监听的消息队列后，就自动触发了规则执行流程。

通过事件的类型和状态，从规则库中获取对应的业务规则，而不是所有的事件都需要跟规则库中所有的规则进行循环比对，否则将会因为规则的逐渐增多给业务规则判断带来性能的影响，过程如图8-15所示。

图8-14　BCP平台业务处理流程示意图

图8-15　BCP平台支持不同事件采用不同规则集进行判断

进入规则执行部分，BCP平台提供了Groovy脚本的规则编写方式，方便各应用通过脚本实现快速地与BCP平台对接：

if（order.containsItemTag（"tmc_tags"）&&order.getAttribute（"promotion"）!=
"bigMarkdown"）{
return "应为大促优惠，当前promotion："+order.getAttribute（"promotion"）;
}

以上示例代码实现了如果订单对象的ItemTag包含tmc_tags标签时，而且如果promotion的属性不等于bigMarkdown（大促优惠），则认为数据为脏数据，返回错误信息，BCP会将不满足系统中业务规则的结果保存到数据库中，方便相关人员随时查看，同时系统会给相关人员发出报警通知。

使用BCP平台实现业务稳定的典型案例是双流对账方案，用于解决以下三种场景下的对账问题：

1）单一系统内的对账。

2）单链路不同系统间的对账。

3）不同业务链路间的对账。

在前面两种场景中对于对账的需求实现没有太大的问题，但对于不同业务链路场景中实现对账的时候可能会需要接收两种数据源，通过两个数据源之间的某个id进行关联后做对账，在实际的生产运行环境中，业务异步化或单元化后就可能会出现一些问题，比如A、B两个数据源，A数据源数据更新后，B数据源数据还没有得到更新，如何实现这种场景的对账就需要采取一些特殊的方式，BCP就能很好地满足这一场景的需求。

以图8-16中所示的某供应链平台的双流对账场景为例，这个场景中有两个Notify（消息服务）数据源，IPM是库存中心批次库存变更消息，PAC是菜鸟网关消息，PAC消息是先于IPM消息到达的，所以在这个方案中BCP在接收PAC的消息后并暂存入Tair（缓存服务器）中，等待IPM消息到达后根据消息中的关联ID去Tair中找PAC中对应的那条消息来做对账。从而实现在不同业务链路间的对账操作。

总结来说，对于平台或应用进行服务化后，很难保证所有的应用设计人员都能对每个服务的能力和逻辑准确认识，而且不同业务链路是由不同的人来设计实现的，业务不一致会是此类平台迟早会面临的问题。而阿里巴巴开发的实时业务审计平台BCP，使得业务异步化后在实际生产环境中出现业务不一致的情况得到了根本性的解决，既提升了用户体验，也让因为业务不一致带来的资金损失降到了最低，特别在双11这样的场景下，体现出了极大的业务价值。BCP平台让整个平台稳定性的能力从技术维度延伸到了业务维度，完善了平台稳定性的覆盖广度，是平台稳定性体系化的一个非常重要的拼图。

图8-16　双流对账场景实现业务检查的流程示意图