业务流程设计之-断点触发，职能定责

1.前言

想想自己代码里面有没有让人眼前一亮的东西，想想还是有的，印象比较深的还真有那么几个，自己写出来归纳整理一下，做个备份，也让自己的脑袋运转一下，最近脑袋越转越慢了，感觉药不能停啊！博客真的要坚持写。

2.业务场景

自己有个功能模块是这样的，开通一个服务，我这里就指定为T服务（Telematics Service）而我们这个服务的开通要调用好几个模块的服务，例如：A/B/C/D/E/F…服务等等。
因为调用链很长，我们要考虑，服务之间互通性的问题，不可能你一执行你的代码逻辑能保证所有的服务ABCDEF…都能执行成功，有可能就断在D这个服务这里。这时通常的做法是直接抛个异常啥的，或者返回D服务操作失败信息。但是真实的业务场景是这个T服务开通成功必须保证调用链里面的所有服务都执行成功，而不是在某个节点执行失败。
也有同学可能觉得这样没有问题，在执行一次不就行了，那么我举个例子大家看看是不是并不是你想象的那样返回就行。

1. A服务说你调用人家一次了，人家已经有了一个宝宝，国家没有二胎政策，再生是违法的。开个玩笑，你数据再别人那边已经存在了，你再次调用别人那边数据已经存在通常的设计就是告诉你数据已经存在不允许重复插入。
2. A服务操作正常，B服务如果是流程，你应经开通流量了，别人不会再给你开一次，会告诉你操作不合法，或者能再次调用别人接口，别人又给你加了流量，那不是白白送流量给别人，要是出现这种情况，公司岂不是要亏大发了。
3. AB服务操作正常，C服务说我心情不好，我情绪不稳定，不想理你，各种超时网络不稳定，导致C服务调用失败。
4. 再从设计的角度来看，你这边很长的调用链，如果从头开始，不止可能出现脏数据也很浪费时间，为啥不能就从上一次断开的位置运行勒既高效又有针对性。

3.设计思路

我们考虑ABCDEF。。。服务都有成功失败两个状态，例如：
A（成功，失败）
B（成功，失败）
C（成功，失败）
D（成功，失败）
E（成功，失败）
F（成功，失败）
。。。

我们把这些状态存在数据库，那么我们从数据库拿到那个状态就能很清楚的知道他在哪个环节出了问题，最开始我想到的是用字符串代替这个状态，可以用英文单词记录，这样我们可以很清楚的知道到底错在哪个节点，但是一想我要怎么在每个接口判断一下，到底该怎么知道我这个节点已经运行过，不用再运行，D节点失败状态A节点判断我已经执行过了，想了想妈的英文单词真麻烦啊该怎么比啊！大于等于，这个设计真恶心，后面直接改为数字了，123456789是真香，A=1 B=3 C=5 D=7 E=9是成功状态，A=2 B=4 C=6 D=8 E=10是失败状态，这会D失败我给serviceStatus=8，执行成功是9 那么ABC只要符合下面几个条件就不用执行了。

1. 不为空
2. A节点等于1时，B节点等于3时。。。
3. 8 > 2/4/6（2/4/6节点直接return true不用执行）
4. 不为9（9已经执行成功）

因为 8 不大于 8所以我们流程不会停，不会return 所以我们执行到D，会再次执行，直到D 状态为9。这样我们就做到了断点触发，职能定责。

4.补偿策略

针对上面失败的问题，我们还要有一套补偿机制，让那些失败的T服务能正常开通，建议从两个方面入手：

1. 单独设置一个接口来调用。
2. 启用定时任务，隔几分钟查询一次那些开通失败的，然后运行开通流程开通T服务。

这样我们可以避免卡在这一环节，忘记了还有定时任务来处理，当然我没有举例portal页面，portal页面也能很清楚的看到哪些T服务开通成功，哪些开通失败，失败了具体失败在哪个环节，失败的环节可以单独设置T服务开通按钮，开通完毕以后可以隐藏按钮。

记录一下！！！