场景
业务风控，主要是下单、支付、优惠券、红包、签到等行为的风险控制，对抗的风险行为包括黄牛刷单、恶意占用库存、机器领券、撸羊毛等。
转账例子
- 账户的信用等级，不同等级的账户每笔转账的最大金额不同
- 记录转账明细
比如一个“人”，除了有id、姓名、性别这些属性外，还应该有“走路”、“吃饭”等这些行为，这些行为是天然属于“人”这个实体的，而我们定义的bean都是一种“失血模型”，只有get/set等简单方法，所有的行为逻辑全部上升到了service层，这就导致了service层过于臃肿，并且很难复用已有的逻辑，最后形成了各个service之间错综复杂的关联关系，在做服务拆分的时候，很难划清业务边界，导致服务化进程陷入泥潭。
对应上面的问题，我们可以在Account这个实体中加入本应该就属于这个实体的行为，比如借记、贷记、转账等。每一笔转账都对应着一笔交易明细，我们根据交易明细可以计算出账户的余额，这个是一个潜在的业务规则，这种业务规则都需要交由实体本身来维护。
另外新增账户信用实体，提供账户单笔转账的最大金额计算逻辑。这样我们就把原本全部在service里面的逻辑划入到不同的负责相关职责的“领域对象”当中了，service的逻辑变得非常清楚明了，想实现A给B转账，直接获取A实体，然后调用A实体中的转账方法即可。service将不再关注转账的细节，只负责将相关的实体组织起来，完成复杂的业务逻辑处理。
规则引擎
groovy脚本
使用插件的方式加载各种组件到上下文中，极大的方便了功能开发的灵活性。
使用预加载的方式加载已有的规则，并将加载后的对象缓存起来，每次规则变更时重新load整条规则，极大的提升了引擎的执行效率
计数器引入AtomicLongFieldUpdater工具类，来减少计数器的内存消耗
灵活的上下文使用方式，方便定制规则执行的流程（规则执行顺序、同步异步执行、跳过某些规则、规则集短路等），灵活定义返回结果（可以返回整个上下文，可以返回每条规则的结果，也可以返回最后一条规则的结果），这些都可以通过设置上下文来实现。
指标存储：redis/hbase
使用hbase的列族来实现滑动窗口的计算。
dubbo这块可以采用泛化调用
网友评论