昨天是1024,一个特别的数字,好比某网站内容的解压密码一般都是1024,想求一个种子留言也是1024。1024是属于广大程序猿(又称码农)的节日,在这样一个节日里,各类“黑”程序猿的新老段子将纷纷出如今各大媒体网站。为何程序猿属于常常被黑的一个群体?凌乱的发型、黑框眼镜、双肩包、格子衫、牛仔裤、运动鞋、钱多话少是不少人眼中的程序猿形象。java
程序猿常常被黑的缘由,还由于他们喜欢自黑(对比下另外一个工种,千万不能当着XXX们的面,叫他们美工,必定要叫设计师),但程序猿真的是描述中的那样吗算法
除了钱多话少是对的,其余都不彻底对,好比说我,穿的是一身国际名牌'优衣库',喝酒烫头不抽烟,但我只是个二流的程序猿,在闲鱼里,顶级的程序猿是这个样子的。编程
程序猿接的最多的需求:这是老板的需求。程序猿代码上线的时间:明天上线。程序猿写过的bug:怎么会有bug。1024祝广大程序猿节日快日,继续加班写bug!!!架构
闲鱼做为一款闲置物品交易平台,让用户的闲置物品再次获得价值流通,普惠每一位用户。先看下面几个业务场景:并发
场景1:在闲鱼的一次活动中,用户进入活动会场后,浏览了几个不一样的宝贝,就会奖励一个包邮券。 场景2:用户关注的用户宝贝降价了,实时告知用户该降价信息。 场景3:在用户搜索租房后,并浏览N个租房信息,则为其推送一套合适的房源。 场景4:双十一会场活动,用户进入会场,点击商品详情,对其发送优惠。
相似这样的业务还有不少,若是每次都是case by case的去解决,不只重复性建设,还很是的浪费人力。程序猿最大的优势就是懒,喜欢将看似不一样的事务进行抽象,找出其共性,进行概括和演绎,并经过设计一种架构,去解决该相似场景下的诸多业务,以减小重复性的劳做。
而架构的设计是有套路能够遵循的,然并卵,虽然了解了不少的架构原理、设计理念,但每每实际的操做过程当中,很容易空对空,这里给出一种设计架构的套路步骤:系统解决的问题定义->系统设计的目标->核心设计->各子系统模块的详细设计。异步
问题的定义是从解决的业务场景出发的,也是最难的一步,若是问题定义的不明白,后面的系统设计很容易出现误差,甚至各方理解不一,没法落地。上面的这些业务场景有哪些共性呢,用一句话能够描述为:“用户的一系列操做,知足必定的复杂规则条件后,对其实时的触达相应的权益”。这里有一个要求,须要“实时”,可以秒级的触达用户。 所以系统解决的问题能够定义为:可以处理复杂规则事件的实时触达系统。编程语言
有了对业务场景的问题定义,如何设计一个架构,去解决这个问题,在设计之初,老板给了一些目标要求:网站
1\. 技术与业务分离,构建技术组件和能力,组合后实现业务需求; 2\. 事件的数据格式须要结构化和标准化,支持扩展; 3\. 规则的表达定义相似SQL的申明式DSL,贴合业务领域; 4\. 客户端和服务端有各⾃的行动触发能力,⽀持扩展开发;客户端支持服务端驱动; 5\. 触发和计算分离,计算模式插件化;
系统设计的目标是为了保证最终的实现和最初的想法不要出现太大的误差,有一个衡量标准在,一是让项目内的成员依据此目标进行设计,避免出现公说公有理、婆说婆有理的状况;二是项目的验收能够依据这个目标去评判,有理可依。阿里云
核心设计这一步很考验基本功和技术视野的,须要综合判断、权衡取舍,依据设计目标选出一个当前的最优解。在系统的设计目标中,其中一条,就是要标准化,标准化最大的好处是能够统一不变的接入。互联网是个发展只有不到30年的行业,但工业已经发展了几百年,不少互联网行业里的问题,在工业里已经有了标准化的定义。在搜集技术方案资料中,对RFID(射频识别)进行复琐事件的流处理的方案进入咱们视野[参考1]。url
而这个工业场景下的问题定义,具备标准化和通用性,其核心内容包含3个模块:数据采集模块、复琐事件处理模块、结果触发相应的时间模块。
这个设计正好符合咱们的业务场景所须要解决的问题。结合咱们本身的业务,咱们将其定义为“日志采集模块、复琐事件的实时处理(EPL)模块、结果触达模块”,其核心的架构图设计以下:
这3大核心模块,都是经过异步消息进行通讯,目的是每一个模块能够解耦,便可以进行独立使用,又能够做为总体的能力提供。
经过日志采集模块,进行日志的采集和归一,获得输入的数据;然后进入EPL模块,进行规则定义和计算;最终的结果进入触达模块,进行用户的结果触达。下面分别介绍这3个模块的详细设计。
1:日志采集模块
闲鱼的系统架构,入口应用多,并且还有是异构的(有java应用,dart应用,Fass应用)。咱们作了一个拦截器,屏蔽这些应用的细节,做统一的拦截处理。 通过统一请求拦截层,将全部的请求日志写入到SLS中。如图
但这些日志的格式变幻无穷,对下游的业务处理很是的不便,所以须要对原始的日志数据进行清洗,清洗为统一的格式,同时这个清洗任务随着原始数据的多变,须要支持可配置化。
咱们使用blink实时的对原始数据进行清洗,同时在blink任务里,嵌入一个UDTF,这个UDTF接入动态化配置平台,支持对清洗任务的可配置化。通过blink清洗后的数据,格式归一化为:
归一化格式后的数据,经过rocketMQ和SLS往下游输出。这里提一下为什么要经过两种数据通道输出:rocketMQ对于在线业务的接入很是方便; SLS对下游接blink任务实时计算并发度要快。
2:EPL引擎模块
EPL模块,在以前的这篇 《闲鱼如何打造高效CEP系统及DSL编程语言》 已经对这个模块进行了详细的讲解(请戳 https://mp.weixin.qq.com/s/is1IlJdCyr-vup78rIoUIw),这里再也不赘述。
这里提一下咱们设计此DSL的目的和目标。
最终的DSL实现方案,一个任务的编写大约只须要5行,而若是使用blink代码实现,至少上百行。咱们跟blink合做,推进该DSL做为blink一种上层业务的抽象表达,能够扩展blink的使用。同时DSL的设计并非天马行空的想出来的,而是根据1这两篇论文进行的设计,尽可能去符合业界的规范。
同时这里的EPL引擎模板,除了云端的计算,还包含了端测计算能力,后面会有针对这一块内容的文章,敬请期待
3:结果触达模块
结果触达模块包含了对EPL计算结果的处理,支持可配置化,支持自定义,并提供了诸如“push、poplayer、openPage”等基础触达能力。后面会有一篇详细的文章进行介绍,敬请期待。
业务方接入,只须要3个步骤:1.配置须要获取的日志数据,2,使用DSL编写任务规则。3.配置一条触达能力。不须要一行代码的开发,只经过配置半天内就能够上线一个业务。
同时,从上游的数据采集->计算->结果触达,整个链路的耗时只须要10s就能够完成。
咱们用一个拦截器,解决诸多异构应用的日志采集问题,而后使用可配置化的blink任务,对原始的日志数据进行清洗,输出标准化的格式数据。接着根据行业的规范,设计出自定义的DSL,以方便复杂规则任务的编写,并和blink合做,无缝的接入blink实时计算平台,进行任务的计算。计算出的结果,只需进行配置,就能够进行到端的push/poplayer/openPage触达。
目前咱们的这款技术产品,已经接入了十多个业务,线上运行稳定,接入的效率获得极大提高。
将来咱们将进一步对DSL的表达能力进行增强,同时将接入端计算能力,使得一些符合端测直接计算的业务场景,实时性获得更高的提高。同时将结合算法能力,去挖掘潜在的业务价值。
参考资料:
阿里云双11亿元补贴提早领,进入抽取iPhone 11 Pro:https://www.aliyun.com/1111/2019/home?utm_content=g_1000083110
本文做者:闲鱼技术-绛曲
本文为云栖社区原创内容,未经容许不得转载。