PartI： 1024
今天是1024，一个特别的数字，比如某网站内容的解压密码通常都是1024，想求一个种子留言也是1024。1024是属于广大程序猿（又称码农）的节日，在这样一个节日里，各种“黑”程序猿的新老段子将纷纷出现在各大媒体网站。为什么程序猿属于经常被黑的一个群体？凌乱的发型、黑框眼镜、双肩包、格子衫、牛仔裤、运动鞋、钱多话少是很多人眼中的程序猿形象。
程序猿经常被黑的原因，还因为他们喜欢自黑（对比下另一个工种，千万不能当着XXX们的面，叫他们美工，一定要叫设计师），但程序猿真的是描述中的那样吗
除了钱多话少是对的，其他都不完全对，比如说我，穿的是一身国际名牌'优衣库'，喝酒烫头不抽烟，但我只是个二流的程序猿，在闲鱼里，顶级的程序猿是这个样子的。
程序猿接的最多的需求：这是老板的需求。程序猿代码上线的时间：明天上线。程序猿写过的bug：怎么会有bug。1024祝广大程序猿节日快日，继续加班写bug！！！
Part II 这是一篇技术文章
闲鱼作为一款闲置物品交易平台，让用户的闲置物品再次得到价值流通，普惠每一位用户。先看下面几个业务场景：
场景1：在闲鱼的一次活动中，用户进入活动会场后，浏览了几个不同的宝贝，就会奖励一个包邮券。
场景2：用户关注的用户宝贝降价了，实时告知用户该降价信息。
场景3：在用户搜索租房后，并浏览N个租房信息，则为其推送一套合适的房源。
场景4：双十一会场活动，用户进入会场，点击商品详情，对其发送优惠。类似这样的业务还有很多，如果每次都是case by case的去解决，不仅重复性建设，还非常的浪费人力。程序猿最大的优点就是懒，喜欢将看似不同的事务进行抽象，找出其共性，进行归纳和演绎，并通过设计一种架构，去解决该类似场景下的诸多业务，以减少重复性的劳作。
而架构的设计是有套路可以遵循的，然并卵，虽然了解了很多的架构原理、设计理念，但往往实际的操作过程中，很容易空对空，这里给出一种设计架构的套路步骤：系统解决的问题定义->系统设计的目标->核心设计->各子系统模块的详细设计。
系统解决的问题定义
问题的定义是从解决的业务场景出发的，也是最难的一步，如果问题定义的不明白，后面的系统设计很容易出现偏差，甚至各方理解不一，无法落地。上面的这些业务场景有哪些共性呢，用一句话可以描述为：“用户的一系列操作，满足一定的复杂规则条件后，对其实时的触达相应的权益”。这里有一个要求，需要“实时”，能够秒级的触达用户。 因此系统解决的问题可以定义为：能够处理复杂规则事件的实时触达系统。
系统设计目标
有了对业务场景的问题定义，如何设计一个架构，去解决这个问题，在设计之初，老板给了一些目标要求：
1. 技术与业务分离，构建技术组件和能力，组合后实现业务需求；
2. 事件的数据格式需要结构化和标准化，支持扩展；
3. 规则的表达定义类似SQL的申明式DSL，贴合业务领域；
4. 客户端和服务端有各⾃的行动触发能力，⽀持扩展开发；客户端支持服务端驱动；
5. 触发和计算分离，计算模式插件化；系统设计的目标是为了保证最终的实现和最初的想法不要出现太大的偏差，有一个衡量标准在，一是让项目内的成员依据此目标进行设计，避免出现公说公有理、婆说婆有理的情况；二是项目的验收可以依据这个目标去评判，有理可依。
核心内容设计
核心设计这一步很考验基本功和技术视野的，需要综合判断、权衡取舍，依据设计目标选出一个当前的最优解。在系统的设计目标中，其中一条，就是要标准化，标准化最大的好处是可以统一不变的接入。互联网是个发展只有不到30年的行业，但工业已经发展了几百年，很多互联网行业里的问题，在工业里已经有了标准化的定义。在搜集技术方案资料中，对RFID（射频识别）进行复杂事件的流处理的方案进入我们视野[参考1]。
RFID系统信息体系结构
而这个工业场景下的问题定义，具有标准化和通用性，其核心内容包含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的目的和目标。
- 简化该业务领域下的写法。
- 云/端表达的统一。
- 该写法要作为blink的一层通用抽象表达。
- 该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
原文链接
本文为云栖社区原创内容，未经允许不得转载。
