闲鱼

简介： 读懂你的心作者：闲鱼技术——有攸 一、背景卡耐基在《兽性的弱点》一书中说：“世界上惟一能影响别人的办法，就是议论他所要的，而且还要通知他，如何能力失去他所要的”。由此可见，良好的沟通交流能够很大水平上拉近单方的关系，进而影响对方。闲鱼音讯是买家理解二手物品信息不可或缺的一环，咱们有理由推断良好的聊天可能对成交产生正向影响。推断须要数据来佐证，通过对以往聊天成交数据的关联剖析，咱们失去了如下论断： 卖家比买家聊的越多，成交概率越大相比经营者，集体卖家互动转化率偏低咱们揣测集体卖家转化率偏低的一个起因是不会好好聊天，通过抽样case发现局部卖家回复内容高冷、僵硬、情绪化，进而导致单方难堪，聊天戛然而止。所以咱们摸索的方向就是如何疏导卖家与买家好好聊天，通过算法用意辨认，以聊天小助手的模式给卖家提供敌对的建议性话术，让沟通交流不再生硬。 二、从议价开始1.为什么是议价交易聊天次要对话场景有收场问询、价格问题、邮费问题、商品信息等，其中会话中聊到价格的占比30%～40%，而且会话中谈及价格时，往往也是交易较后的阶段，如果买卖双方在价格问题上沟通顺利，预计能够无效促成交易。所以咱们思考先从议价场景切入，最小闭环上线，察看数据佐证猜测后，再逐渐上线其余对话场景策略。 2.方案设计 为了不影响音讯主链路，辨认流程必须走异步mq生产流程，同时为了缩小算法辨认的压力，对音讯进行了音讯类型、发送者、关键字过滤、会话疲劳度管制等规定的初筛。此外，咱们还联动了商品的价格力数据，价格力数据能够提供商品的同类同款卖出价以及举荐价，通过算法综合择优，能够给出商品建议价，再依据买家出价状况，走不同的产品逻辑组合成不同场景下的批准/回绝文案选项。这样无论买家出价是否正当，卖家是否承受，给卖家提供友善的议价话术抉择，让买卖双方还有持续聊上来的机会，就还有成交的心愿。如果买家出价不合理，也会给买家下发议价不合理的卡片，给出同类商品的参考价，拉平买家的价格预期。 3.产品成果卖家侧： 买家侧： 三、持续摸索1.宝贝还在吗？置信这简直是每个闲鱼卖家都司空见惯的聊天开场白，但很多卖家见多了反而不违心回复这类没有养分的问题，心田os："不在还挂着干啥？？？"。咱们本着让买卖双方的聊天有一个欢快的开始的目标，思考从2个方面优化这个场景的问题： 为买家提供更多样更有价值的开场白问题为卖家提供打招呼音讯的快捷回复2.基于类目标加权随机开场白 不同类目标商品聊天中买家关注的问题点不同，咱们基于离线数据分析，回捞了一批不同类目买家最关怀的问题列表，把这些问题首先按类目分类，其次按关注点(二手属性)分类，再加上触发规定条件、权重分，造成一套开场白问题库，可由产品经营自助增加批改。 流程图： 如上图所示，当会话创立时，先依据类目读取问题库失去对应的问题列表，再依据这个商品自身的一些属性标，如是否包邮，是否全新，按规定筛选出符合条件的问题列表，再依据权重分对满足条件的问题进行加权随机，最终失去某个二手属性的问题项。为了保障问题内容的多样性，每个二手属性的问题项也会有不同文案但雷同语义的表白，最初再次随机一个具体问题表白，即可下发倡议卡片。 3.用意辨认流程框架后面曾经实现了议价用意的算法辨认，这次又要新增一种打招呼的辨认，是否要从新开发整个流程呢？显然不须要，后期议价为了疾速迭代上线看成果，没有形象设计成一种通用的用意辨认流程，这次新增第二种用意辨认，有必要还债从新设计了，任何优良零碎的设计都是一直迭代重构产生，绝不会是欲速不达的，我的项目初期在需要不明确的状况下如果思考的过多，往往会导致适度设计，前面如果需要变动，又要返工。故从新形象设计一套通用的用意辨认流程框架。 流程设计： 类图： 如上图所示，每种用意须要实现IntentProcessor接口，实现本人的过滤和解决逻辑，不同用意有不同的初筛逻辑和扩大参数，filterAndCompleteContext这个办法是用来过滤和补充用意辨认扩大参数到流程上下文中的，如果满足初筛条件，就增加该用意类型到可能的用意列表中，由算法辨认最终后果，如果一条音讯存在多种用意，由算法依据优先级规定选出最相干的用意。失去用意辨认后果后，调用对应的IntentProcessor的process办法，实现具体的业务逻辑解决，如在议价场景是依据价格规定，组装不同文案下发倡议卡片。 4.产品成果开场白： 打招呼： 四、从问答中取栗1.为什么总是问我同一个问题？咱们察看数据发现，聊天中商品问询场景覆盖率35%～40%，因为闲鱼商品交易独特的二手属性，卖家可能会面临同一个商品同一个问题会被多个买家屡次问到，从而反复答复的状况，卖家有苦说不出，只能心田os"为什么总是问我同一个问题？"。为了优化卖家体验，进步卖家回复效率，咱们决定辨认聊天中的问答对，而后在问答对音讯前面插入疏导tip，卖家侧能够抉择将问答对补充到商品详情中，如果问答对中含有商品结构化二手属性信息(比方成色、有无拆修、品牌等)，也会辨认并疏导卖家补充商品的结构化属性。 2.通用音讯扩大属性变更咱们下面说的用意辨认流程框架马上就用了起来，这时候只须要新增一种用意辨认处理器(IntentProcessor),实现该场景的过滤和解决逻辑，就能够轻松实现整个性能。但新的问题来了，下面的议价、打招呼场景中咱们给卖家侧的疏导都是一种倡议类卡片，这种卡片是一条新音讯，与其余的音讯一起混排，而且与触发源音讯关联性不强，即便有提早导致卡片插入到偏后的地位，影响也不是很大。然而问答这种场景，下发的是一条疏导tip，这个tip是与答案所属的音讯强关联的，疏导tip必须紧跟答案音讯前面，如果对不上，就会十分影响体验。 闲鱼的音讯列表是依照发送工夫排序的，如果按以往新音讯的模式插入，无奈严格保障下发机会紧跟在某条音讯前面，如果人为的批改音讯的发送工夫，会毁坏音讯发送工夫这个字段的语义。咱们从另一个角度思考，这条tip肯定是紧跟在某条音讯前面，如影随形，不离不弃，那么为什么不合二为一呢？把这条tip看成是这条音讯的一个扩大属性，所以咱们决定引入一种通用变更音讯扩大属性的能力，通过事件下发给客户端，再由客户端依据约定的协定解析并展现，如下图所示 由业务发动对某条音讯的扩大属性变更，可选设置存储服务端音讯库，更新会话视图，比方问答场景的tip，是有时效性的，只须要透传给客户端，服务端齐全不须要存储。该计划也为当前音讯的个性化变更及展现提供了可能。 3.产品成果 五、总结与瞻望至此，咱们的聊天小助手积淀出了一套通用的用意辨认流程框架，实现了议价、打招呼、问答三种用意辨认，疏导宽广集体卖家跟买家好好聊天，帮忙卖家快捷补充更具体的商品信息。聊天小助手上线后，性能使用率较高，试验桶相比对照桶，回复率绝对晋升4%，在议价场景中，下发卡片的试验桶相比对照桶成交转化率绝对晋升4%，从数据来看，的确也证实了咱们之前的推断，疏导交易聊天，对促成交易有正向作用，为接下来该项目标持续演进提供了可能。 我置信敌对亲切的沟通交流能够和煦人心，拉近关系，事实世界是如此，通过网络沟通也同样是如此。将来咱们会继续迭代优化聊天小助手，横向开掘更多的用意辨认场景，比方包邮、发货地等，同时在聊天中波及最多的商品信息辨认场景深耕，帮忙卖家更好的欠缺补充商品信息。总之，将来聊天小助手会有更丰盛实用的技能树，让她更聪慧，更懂你。 原文链接本文为阿里云原创内容，未经容许不得转载。

简介： 闲鱼交易品质自动化 背景闲鱼作为一款垂直交易社区APP，领有简单多样的业务场景：波及c2c、回收寄卖、租房租赁、见面交易、验货担保等，复杂多变的交易模式。比方验货流程： 波及39个状态机节点横跨10+利用零碎波及6个业务部门的单干波及接口几十个须要保障每个接口、每个场景切实可行，略微有一点点问题，就会波及到人民币的滋味，理论工作中，咱们遇到各种各样的问题，比拟辣手的问题如下： 问题业务先赢的疾速迭代模式下，全靠人工主力进行测试验证，测完新性能，还得回归老性能，一个小需要也须要好几个人日，版本PTM也要回归好几遍，ROI并不乐观，以下2个问题比较突出： 交易业务强依赖中台，沟通老本高，跨团队合作难，迭代效率低，测试环境下如何自洽？简单多样交易模式下，如何撑持需要稳步迭代上线以及日常回归验证？测试策略-自动化闲鱼品质基建正在快马加鞭进行中，针对闲鱼多样的交易模式，全靠人力是不可行的，累不说，改变、危险漏评估也时有发生。对此，咱们依据接口->链路的策略，摸索比照了几个不同的计划，在保障每个接口OK的根底上，保障全链路。 接口层对于每一个大型应用程序来说，接口数量会一直减少，代码变更频率越来越大、零碎不定期重构，这个接口的品质怎么来保障？传统编写脚本来进行的形式，投入的人力、工夫老本过大，在理论的测试过程中咱们摸索了一些接口测试的新想法。目前业界公认的无效形式是基于引流回放的自动化测试，实现计划业内七嘴八舌各有其词，但万变不离其中，援用上面这段总结，简单明了 一种是黑盒测试思路，它在线上接口申请时采集线上流量（次要是申请参数和后果），而后应用和线上环境雷同的环境（数据库共用等）下用采集到的流量从新触发申请，而后断言被申请的返回值是不是和录制时的统一。这种办法比拟适宜对Get类型的接口进行测试，而对于写操作的申请容易造成数据净化，再加上所采集流量的数据状态（数据时效性）、环境依赖性（各种中间件、接口外部申请的RPC调用）等因素，所以这种测试形式具备一些局限性，不能满足理论测试场景中简单的需要。 另一种思路绝对白盒，次要是通过智能化的Mock伎俩，流量采集时采集代码运行过程中所依赖的内部中间件或者RPC调用的返回后果，当流量回放时，可能Mock本机程序对外的依赖中有可能产生变动的内容，使测试更关注本地接口的代码逻辑。 阿里团体外部，基于流量回放的思维，次要实现了2种不同的流量录制回放计划，一种是基于doom的天启/暴雪，一种是基于JVM-Sandbox的凤凰，两种实现都借力于JVM AOP。 天启/暴雪天启/暴雪，其底层采纳的是doom进行流量录制，其原理如下doom原理图 次要流程是： 通过Java agent挂在JVM中的client以ASM的AOP形式采集主调用（采集或回放时的入口办法）的入参、返回值、子调用（利用执行过程中的一次办法调用，采集机器会采集该办法的入参和返回值用于回放时执行到该办法进行mock）的入参和返回值，而后将采集到的数据上传至server （离线模式）；回放时，client收到接口回放申请后，会执行该接口的本地逻辑，对于子调用则用采集的入参和后果进行mock；将采集的流量和回放的后果数据进行比照。doom形式，业务利用零碎须要引入Jar包，批改启动类，批改JVM挂载agent，有局部的业务侵入性。 - 凤凰 凤凰，也是采纳JVM AOP实现的流量录制计划，理念和doom差不多，凤凰整体架构底层基于JVM-Sandbox（阿里开源的一款 JVM 平台非侵入式运行期 AOP 解决方案，通过字节码加强实现办法级别的AOP性能）输出模块原子能力。录制时，记录了产生调用的办法，入参、返回值和调用产生的程序，以链式数据结构存储，回放时进行接口逻辑执行和子调用mock。<br /><br />凤凰录制回放<br />凤凰无需代码侵入批改，不须要批改利用启动参数，相对来说，对业务代码影响小，然而有利用构造要求。思考老本和危险，以及咱们的利用构造，闲鱼采纳基于Sandbox的凤凰流量录制回放进行保障，变更上线流程卡点。<br />研发过程中，也会遇到各种各样的流量回放问题，比方用例过期，须要人工分明从新录制。咱们当初是采纳定时工作主动革除从新录制的形式解决。<br />上面是咱们的一个场景例子：<br /><br /><br />链路层在基于流量录制、回放比对的接口测试过程中，咱们发现这种机制对于单利用的品质保障比拟实用，然而对于跨利用的链路验证、外围写操作、外调用，以及零碎重构类、计划革新等大需要就有些有余，链路级的解决解决方案接踵而至。 Thub + 微服务测试环境下，对于全链路上下游的强依赖，措施之一是开发测试服务化能力，建设自洽能力，测试环境下解藕对于外界诸如交易中台、菜鸟裹裹的依赖，测试环境能进行全链路闭环。 落地首要任务是梳理业务全链路节点： 骨干链路上的每一个MTOP接口，以及接口的上下游依赖外部利用、中台利用、内部商家的依赖数据流以及TDDL梳理业务梳理残缺，进行测试服务化接口开发。上面是咱们截取的一部分链路case：同时，诸如测试环境因为依赖方测试环境不稳固block测试的状况，咱们提供测试服务化接口进行封装，裸露成下单、验货等服务化能力内置于闲鱼品质平台，用于开发、测试在研发过程中应用。 天算平台天算平台，利用影子库，全链路压测的模式，线上业务数据和测试数据隔离，测试库copy线上库一部分数据。次要实现的形式是将线上的场景进行固化仿真，全链路执行，并且在执行的过程中进行所有数据变更的比对，用户能够抉择任何代码版本的基线和变更版本进行比照。 大抵流程 天算能力根本能满足闲鱼的交易链路，闲鱼建设了主链路相干影子库，影子链路正在调试中，用于交易服务端的全链路巡检。 同时，影子链路有诸如业务变更导致影子数据过期的问题，这个计划则次要是用于业务比较稳定的业务，新业务或者一直迭代更新的业务并未all in这个计划。 总结综上，目前闲鱼交易，接口层用基于jvm-sandbox的流量录制计划, 日常巡检利用影子链路，研发过程自测、链路自动化用业务编排服务化能力。 瞻望在基建欠缺的根底上，咱们将持续摸索flutter以及服务端的全端智能化方向的测试解决方案，心愿让更多技术小二从重复劳动中释放出来，从治、防、控，三层品质网，保障闲鱼交易，让用户在闲鱼释怀的卖卖卖、买买买。期待和大家一起交换业内的不同测试计划！同时感激doom、sandbox、凤凰、天启、暴雪、全链路压测、Thub等团队提供的能力反对！ 原文链接本文为阿里云原创内容，未经容许不得转载。

简介： 千门万户闲鱼日，总把新桃换旧符 作者：闲鱼技术-兰林 背景在互联网行业，线上服务的降级更新堪称粗茶淡饭。据统计，在过来的一个季度中闲鱼工程师们执行了千余次公布，总计更新的代码数量超过百万行。 这些公布中，有一些可能只更新了几行代码，而有一些可能执行了整个集群的迁徙降级。而无论这些变更的影响面有多大，咱们都必须保障线上服务的可用性，用户无感知。本文将以闲鱼搜寻服务的迁徙降级为例，向大家介绍其背地的技术计划。 闲鱼搜寻服务根本架构闲鱼的底层搜寻服务由查问布局服务 Search Planner、查问了解服务 Query Planner、打分排序服务 Rank Service 以及搜索引擎 Heaven Ask 3 所组成。它们之间的互相调用关系如下图所示： 能够看到，整个搜寻服务是由多个互相独立的微服务所形成的。不同的微服务之间互相隔离，通过事后向外裸露的接口提供服务。所有的微服务最终通过 Search Planner 收口，对外提供对立、残缺的搜寻能力。 在底层搜寻服务之上，还有业务逻辑层和接入网关层，具体架构在此不再赘述。用户的搜寻申请先通过网关层转发给逻辑层解决，再向底层搜寻服务发动搜寻申请。这条申请链上蕴含数十个集群，调用深度达到两位数，整个过程中提供服务的服务器数量可能有成千盈百。 对于这样一个简单的零碎，降级过程显然无奈欲速不达。好消息是各个微服务之间正当的解耦合给降级工作带来了很大的便当，无效防止牵一动员全身而导致无从下手，使咱们能够分门别类地解决降级问题。 注1：Search Planner 是一个基于函数式、服务化、可视化、并行化开发框架所构建的搜寻服务网关层。注2：Query Planner 的次要作用是了解用户输出，而后对搜索词进行算法优化。最终取得更好的搜寻召回后果。注3：Rank Service 是实时打分排序服务，它的作用是依据多维度的特色对搜素引擎召回的海选后果进行算法打分。分数越高的商品就越有机会呈现在搜寻后果的前列。注4：Heaven Ask 3 （问天3）是阿里巴巴研发的一款稳固高效、功能强大的搜索引擎。为阿里团体包含淘宝、天猫在内的外围业务提供搜寻服务反对。放弃兼容开始降级之前，咱们首先须要确认被降级的服务是否放弃了向前与向后兼容性。放弃兼容不仅缩小了工作量，也缩小了降级所导致的故障危险。 为了尽量避免降级导致的不兼容，咱们能够总结一些开发准则： 近程过程调用（RPC）须要可能疏忽未知参数，并且容许缺失参数。如果须要删除已有参数，须要与所有依赖方确认。能够先将参数标记为 Deprecated 而不是间接移除。应用参数时，辨别缺省值和缺失值。如果接口无奈放弃兼容，则创立新接口代替旧接口。不要毁坏旧接口的兼容性。在降级时，先降级那些没有内部依赖的服务。等到被依赖方降级结束之后，再去降级依赖方。确定了每一个服务的降级程序之后，咱们再依据服务的理论状况确定降级计划。 无状态服务降级正式进入降级流程，咱们首先关注搜寻链路中的被设计成无状态服务的局部，例如用于解决业务逻辑的 Java 微服务、用于解决查问逻辑的 Search Planner 等。它们的独特特点是，每个申请处理完毕之后，对于该次申请的资源即被开释。不同的申请之间没有相互依赖和时序要求。同一个无状态服务内不同的机器节点是齐全等价的。 无状态服务的特点使得它们很容易通过程度扩大来动静扩缩容。因而在保障兼容的前提下，它们的降级流程绝对通用并且简略： 依据服务最小可用度决定分批数。选取一批待更新的容器，进行服务。批量降级容器、更新镜像。期待这一批容器全副复原服务后，持续更新下一批容器。 一般来说咱们能够通过把状态存储在音讯队列、缓存、数据库或者其它内部中间件中来达成服务的无状态。把服务设计成无状态的益处不言而喻：降级时不须要调配额定的机器资源，降级速度快，变更代价小，因此能够反对频繁的迭代更新。然而，这种设计也给状态拜访和更新带来了额定的开销，在某些性能敏感的场合可能是不实用的。 有状态服务降级咱们持续关注有状态的局部。有状态服务降级的麻烦之处在于，状态的存储、复原、转移往往由服务依据理论状况独自设计（或者基本没有设计），因此降级较为艰难。咱们能够简略列举一些绝对通用的有状态服务降级可选计划。 接入层网关提供热更新的能力（例如 Nginx），把状态的放弃隔离在接入层外部。适宜须要长时间放弃状态的场景。渐进更新，新申请逐渐切换到新服务上解决，旧服务解决完存量申请后销毁。适宜短时间放弃状态的场景（例如游戏服务、实时音视频通信服务）。创立全新的服务正本，通过数据双写放弃新旧服务状态统一，逐渐用新服务取代旧服务。在闲鱼搜寻的架构中，搜索引擎自身提供的尽管是无状态服务，然而引擎外部保留了用于解决索引分区，增量进度的各种状态。最终应用的降级计划如下： 应用新版本镜像创立一个齐全独立的新引擎。新旧引擎全量数据同步。增量数据同时向新旧引擎发送。新引擎上线，逐渐扩充承接流量的比例。旧引擎不再承接流量后下线。 和无状态服务的降级相比，这种形式不仅额定应用了一倍的机器资源，而且每次降级都须要做一次简单而繁琐的服务配置。如果服务自身不是无状态的，还须要自行编码实现切流逻辑，保障同一个用户的申请可能落到同一个集群上。整体降级老本较为低廉，只适宜更新频率非常低的服务。如果服务的更新频率较高，则应该依据服务的理论状况设计实现降级老本更低的计划。 服务发现在降级过程中，服务发现机制承当着重要作用。它为咱们提供了以下性能： 保障分布式一致性服务优雅高低线负载平衡流量调控与申请降级同机房优先调度跨机房容灾调度 服务发现是流量调控的总阀门。一个成熟稳固的服务发现机制不仅能够无效防止公布导致的申请成功率抖动，也为产生异样时疾速回滚止血提供了保障。 危险防控对搜寻链路的每一个集群依照依赖程序进行服务降级、挂载、切流无疑是高危操作，稍有不慎就可能引起线上故障。因而，咱们依照阿里巴巴平安生产三板斧准则对降级流程进行了梳理： 可监控重要链路的重要指标均提前保障监控笼罩。例如申请总量，申请成功率，申请响应时长等等。确保重大问题能够通过监控指标及时发现。可灰度任何变更都不容许未经灰度间接全量公布到线上。对于无状态服务，咱们个别通过调整服务发现中的权重或者调整机器比例来实现灰度放量。对于局部不能随机灰度的情景，咱们设计了按用户分批放量的机制。可回滚变更零碎提供了通用的一键回滚能力，但并非是最快的形式。在很多状况下，咱们在执行变更前就做好了把待更新的机器或集群在服务发现上从新挂载或移除的筹备，从问题发现到复原的工夫根本是秒级的。总结综上所述，简单零碎不停机降级的准则和流程能够概括如下： 服务间解耦与隔离，确保单次降级的范畴和影响可控。依据兼容性和依赖关系决定服务的降级程序。依据服务是否无状态决定降级形式。提前准备好监控和回滚计划，灰度降级。闲鱼搜寻服务降级的整个执行过程经验了两个月的工夫。这其中咱们既保证了用户无感知，线上服务稳固运行，也保障了与咱们合作开发的算法团队以及其余工程团队的失常开发不受影响。 在理论执行的过程中，咱们还遇到了很多细节上的问题。例如创立新服务时未能提前正当预估估算需要，导致降级过程中一直挪借估算，拆东墙补西墙。又比方异地多活部署带来的提早问题迫使服务放弃单元化，给降级过程中的流量调控工作带来了很多挑战。这些裸露的问题也为咱们持续欠缺架构和计划提供了指引。 心愿本次的分享可能给大家带来一些帮忙和启发。

简介： 简单事件采集+工作零碎+实时触达 作者：闲鱼技术-占先 一、业务背景闲鱼作为一款C2X的app，与淘宝、天猫等B2C的业务模式存在人造不同。集体卖家也是一般的消费者，很多集体卖家相比业余卖家，并不分明如何卖出本人的商品，问题次要体现在以下两个方面： 1、商品信息有余。闲鱼采纳轻公布模式，用户只须要上传几张照片，简略形容一下商品信息，即可在一分钟之内实现公布流程。轻公布模式投合了用户疾速公布的体验，但也导致了商品信息有余的问题。 2、商品定价不合理。有些卖家用户误判了本人商品的市场行情，导致定价和买家预期存在偏差，升高了买家的购买志愿。 所以问题来了，如何在既保证轻公布的同时，晋升商品的无效信息量，减少商品宝贝的吸引力，促成成交呢？ 二、解决思路在上述问题背景下，咱们想到了做工作的形式疏导用户。具体做法是：在轻公布的前提下，通过做工作的形式疏导卖家补全商品信息或疏导商品提价，从而促成成交。 一方面，商品要害属性的信息补全了，价格变得正当了，就有更多的买家违心浏览商品并成交。 另一方面，也帮忙咱们技术小二更好的了解商品的特色，从而更精准地举荐给须要的买家。 三、技术实现与零碎积淀在这个解决思路下，咱们发明了Tellus-基于用户&商品的工作零碎。 有些同学可能问了：“公司外部难道没有相似的零碎吗？工作零碎应该比拟常见吧？”通过调研，发现已有的外部零碎大部分是基于用户的工作零碎，而闲鱼的工作零碎是基于用户&商品维度的，这样的特点导致咱们无奈复用现有的工作零碎，只能通过自研。   整体零碎结构图   工作的生命周期分为创立工作、展现工作和实现工作。   工作创立模块： 创立工作的难点在于之前提到的数据起源简单的问题，因为工作创立的起源较多，为了升高接入老本，Tellus的工作创立模块应用音讯队列来做事件解耦。Tellus应用MetaQ作为音讯队列。MetaQ是一款阿里自研分布式、队列模型的消息中间件（RocketMQ）。基于公布订阅模式，有Push和Pull两种生产形式，反对严格的音讯程序，亿级别的沉积能力，反对音讯回溯和多个维度的音讯查问。通过音讯定制，所有的数据源对立发送创立工作的音讯，Tellus零碎监听此类音讯并且依据业务逻辑创立对应的工作，很好地解决了简单音讯源的问题。   工作展现模块: 当工作创立后，如何展现工作呢？展现流程如下：     咱们通过AB试验进行了全方位的摸索，Tellus零碎反对了丰盛的工作类型， 咱们尝试了单个工作和组合工作：   单个工作展现   组合工作展现 还反对基于用户维度(例如间断擦亮工作)的和基于商品维度(例如选商品成色)的工作。Tellus零碎同时也实现了工作频次的定制，工作能够一次性实现，也能够反复做，能够依照特定程序实现组合工作，也能够乱序实现，给业务提供了灵便的可配置型。     工作实现模块     工作的实现模块分为被动实现逻辑和被动实现逻辑，被动实现可分为工作胜利和工作失败，被动实现属于用户的某些app行为触发了实现工作的逻辑，从而在不知情的状况下实现了工作，比方在从新编辑商品的时候增加了商品成色，那么增加成色的工作就主动实现了。不同工作还能够实现个性化的激励步骤，Tellus通过策略模式的设计，将接口凋谢给业务方开发，每个工作的实现，用户都能够获取到肯定的激励，这些激励依据业务的不同而不同，通过接口凋谢，业务方开发只须要恪守接口的协定，便能够实现定制化开发，实现不同的工作激励机制。   在整个工作的生命周期过程中，还有一个始终都绕不开的难题，就是数据该如何存储，工作数据次要分为两类：一类为工作的具体数据；另一类为工作的元数据。        针对工作的具体数据，首先要思考的是关系型数据库还是非关系型数据库，关系型数据库反对事务，能够进行简单的联表查问，这些对于工作零碎并非必须和必要的，工作系统对数据的关联性要求不高（工作数据之间简直是互相独立的），然而对于数据的存储量级要求较高（百亿级别）。反对海量数据存储的Table store进入了咱们的视线。 表格存储（Table Store）是阿里云自研的NoSQL多模型数据库，提供海量结构化数据存储以及疾速的查问和剖析服务。表格存储的分布式存储和弱小的索引引擎可能反对PB级存储、千万TPS以及毫秒级提早的服务能力。除此之外，Table Store还兼具以下长处： 1、Table Store还是一种全托管的数据库。应用表格存储只需专一于业务研发，无需放心软硬件预置、配置、故障、集群扩大、平安等问题，在保障高服务可用性的同时，极大地缩小了治理及运维老本，这样能够使咱们把精力全副放在业务的开发上。 2、查问能力强。除了反对主键查问，表格存储还反对多元索引、全局二级索引。 3、高可用。表格存储将数据的多个备份存储在不同机架的不同机器上，并会在备份生效时进行疾速复原，提供99.99999999%（10个9）的可靠性。 4、数据强统一。表格存储保证数据写入强统一，并保证数据 3 正本均写入磁盘，且所有数据保持一致。写操作一旦返回胜利，应用程序就能立刻读到最新的数据。 基于上述长处，Table Store比拟好的满足了咱们数据存储的需要。 针对工作的元数据，思考到应用频率，咱们也创立了缓存进行读写，对于工作零碎的元数据，咱们选取了guava cache作为缓存。起因是guava cache申请疾速且简略易用。工作元数据数据量较小，即便每个节点都存储一份缓存，开销也不大，这种情景应用分布式缓存比拟重，意义不大。   四、业务成果Tellus因为其性能反对的多样性，可拓展性，以及可配置性的多种特点，在短时间内能够反对大量不同业务场景的上线，这里咱们以超级曝光和存量诊断也为为例，具体阐明一下。 超级曝光针对新发商品在商品公布时弹出一个弹窗，疏导用户进入组合工作页面实现工作，实现后用户可取得超级曝光特权。存量诊断针对存量商品，在宝贝下方透出第一个工作信息，疏导用户进入组合工作页面，实现组合工作。上线后，组合工作大幅提高了工作完成率。 五、开发效率晋升对于Tellus来说，比拟大的一个挑战是新增工作数量较多，较短时间内须要反对数百个工作，这简直是不可实现的工作。为了反对业务的疾速试错，并且升高开发成本，Tellus次要做了两个方面的优化，一个是工作模版化，另一个是反对工作的可配置化。 先说说工作的模版化：咱们发现工作从表现形式上能够形象为单选类、多选类、确认类、跳转类等等。将每类工作定制为一个模版，视觉同学针对模板进行视觉形象，固定展现款式，服务端依据展现款式形象模板类型，前端齐全基于服务端数据驱动，前后端的协定格局举例如下： 新增工作时，只须要套模版即可，缩小了很多反复开发的工作量。 再说下工作的可配置化：在工作模版化的根底上，咱们发现对于某些工作，工作的逻辑基本一致，只是对应的工作文案不同。Tellus针对这些简略工作，反对了工作可配置化的开发，目前1.0曾经开发实现，本来须要改代码才能够新增一个工作，现在只须要改配置文案即可。后续2.0版本将做经营页面的开发，经营同学只须要在页面上配置即可，不再须要开发人员染指，从而大幅提高开发经营效率。 ...