锦素网易考拉规则引擎平台架构设计与实践.docxVIP

网易考拉规那么引擎平台架构设计与实践 背景考拉平安部技术这块目前主要负责两块业务：一个是内审，主要是通过敏感日志管理平台 考拉所有后台系统的操作日志，数据导入到es后，结合storm进行实时计算，主要有 行为查询、数据监控、事件追溯、风险大盘等功能；一个是业务风控，主要是下单、支 付、优惠券、红包、签到等行为的风险控制，对抗的风险行为包括黄牛刷单、恶意占用库 存、机器领券、橹羊毛等。这两块业务其实有一个共通点，就是有大量需要进行规那么决策 的场景，比方内审中需要进行实时监控，当同一个人在一天时间内的导出操作超过多少次 后进行告警，当登录时不是常用地登录并且设备指纹不是该账号使用过的设备指纹时告 警。而在业务风控中需要使用到规那么决策的场景更多，由于涉及规那么的保密性，这里就不 展开了。总之，基于这个出发点，平安部决定开发出一个通用的规那么引擎平台，来满足以 上场景。 写在前面在给出整体架构前，想跟大家聊聊关于架构的一些想法。目前架构上的分层设计思想已经 深入人心，大家都知道要分成controller, server, dao等，是因为我们刚接触到编码的时 候，mvc的模型已经大行其道，早期的jsp里面包含大量业务代码逻辑的方式已经基本绝 迹。但是这并不是一种面向对象的思考方式，而往往我们是以一种面向过程的思维去编 程。举个简单例子，我们要实现一个网银账户之间转账的需求，往往会是下面这种实现方 式： .设id^一个账户交易服务接口 Accountingservice,设计一个服务方法transfer (),并提供 一个具体实现类AccountingServicelmpl,所有账户交易业务的业务逻辑都置于该服务类 中。 .提供一个Accountinfo和一个Account,前者是一个用于与展示层交换账户数据的账户数 据传输对象，后者是一个账户实体(相当于一个EntityBean),这两个对象都是普通的 JavaBean,具有相关属性和简单的get/set方法。 .然后在transfer方法中，首先获取A账户的余额，判断是否大于转账的金额，如果大于那么 扣减A账户的余额，并增加对应的金额到B账户。 这种设计在需求简单的情况下看上去没啥问题，但是当需求变得复杂后，会导致代码变得 越来越难以维护，整个架构也会变的腐烂。比方现在需要增加账户的信用等级，不同等级 的账户每笔转账的最大金额不同，那么我们就需要在service里面加上这个逻辑。后来又 需要记录转账明细，我们又需要在service里面增加相应的代码逻辑。最后service代码 会由于需求的不断变化变得越来越长，最终变成别人眼中的“祖传代码”。导致这个问题 的根源，我认为就是我们使用的是一种面向过程的编程思想。那么如何去解决这种问题 呢？主要还是思维方式上需要改变，我们需要一种真正的面向对象的思维方式。比方一个 “人”，除了有id、姓名、性别这些属性外，还应该有“走路”、“吃饭”等这些行为， 这些行为是天然属于“人”这个实体的，而我们定义的bean都是一种“失血模型”，只有 get/set等简单方法，所有的行为逻辑全部上升到了 service层，这就导致了 service层 过于臃肿，并且很难复用已有的逻辑，最后形成了各个service之间错综复杂的关联关 系，在做服务拆分的时候，很难划清业务边界，导致服务化进程陷入泥潭。 对应上面的问题，我们可以在Account这个实体中加入本应该就属于这个实体的行为，比 如借记、贷记、转账等。每一笔转账都对应着一笔交易明细，我们根据交易明细可以计算 出账户的余额，这个是一个潜在的业务规那么，这种业务规那么都需要交由实体本身来维护。 另外新增账户信用实体，提供账户单笔转账的最大金额计算逻辑。这样我们就把原本全部 在service里面的逻辑划入到不同的负责相关职责的“领域对象”当中了，service的逻 辑变得非常清楚明了，想实现A给B转账，直接获取A实体，然后调用A实体中的转账方 法即可。service将不再关注转账的细节，只负责将相关的实体组织起来，完成复杂的业 务逻辑处理。 上面的这种架构设计方式，其实就是一种典型的“领域驱动设计(DDD)”思想，在这里就不 展开说明了(主要是自己理解的还不够深入，怕误导大家了)。DDD也是目前非常热门的 一种架构设计思想了，它不能减少你的代码量，但是能使你的代码具有很高的内聚性，当 你的工程变得越来越复杂时，能保持架构的稳定而不至于过快的腐烂掉，不了解的同学可 以查看相关资料。要说明的是，没有一种架构设计是万能的、是能解决所有问题的，我们 需要做的是吸收好的架构设计思维方式，真正架构落地时还是需要根据实际情况选择合适 的架构。 整体架构设计 上面说了些架构设计方面的想法，现在我们回到规那么引擎平台本身。我们