知鸦日报2024-08-30

本文详细介绍了58同城邀约业务系统的架构设计和实践经验。文章涵盖了系统的业务背景、整体架构、核心组件设计、技术实现细节等。

在面对平时的业务功需求迭代时，相信大家都会面临一个代码复杂度和后续的维护高成本的问题，下面我们主要针对营销返利活动场景，对复杂的业务场景的代码设计进行详细的讲解。

经济趋势

国家大力推动“互联网+”发展的背景下，涌现了众多的互联网企业。同时，中大型企业也纷纷尝试通过自建电子商务平台加速转型升级，以整合供应链上下游资源。互联网支付也面临着很多资金安全问题以及监管问题。

监管要求

监管部门禁止没有支付牌照和支付资格的互联网平台开展网络支付业务，禁止其以自身名义搭建具有金融属性的类电子账户，禁止私设不具有真实交易背景、不受金融机构管控的资金池。

《非金融机构支付服务管理办法》

“非金融机构提供支付服务，应当依据本办法规定取得《支付业务许可证》，成为支付机构。”

说明1-1：

二清，简单来说就是在未持有《支付业务许可证》的时候，从事资金清结算业务。举个场景的例子吧，比如一个撮合型电商平台，消费者支付了100元后，资金是进入到平台账户，待店铺提供了产品或者服务后，再将资金结算给店铺，这就是我们所谓的二清。二清的风险在于，代收消费者资金容易形成具备金融属性的“资金池”。可以想象，一个初具规模的电商平台，日交易额几百万甚至几千万。这么庞大的资金，原本大头部分是给入驻的店铺的，但滞留在平台就很能引发挪用或者卷款的风险。

推荐系统通常可以分为召回、粗排、精排、重排四个阶段，召回主要是根据不同策略或模型从海量的物品库中快速筛选出一小部分用户可能感兴趣的物品，交由排序模型来精准地完成个性化排序，本文主要阐述召回在算法侧的工作原理以及召回系统工程侧落地实践。

海拍客内部有很多后台系统，包括配置，OPS，管理，监控等等。现有的前端资源不足以覆盖完所有的需求，经常出现串行排队的现象。

哪怕人员再高效，熟练，哪怕需求再简单，哪怕页面风格高度统一，但是沟通，开发，联调，测试，发布，这一大串流程走下来，还是会有些心有余而力不足。

因此，我们迫切需要创造一个强大高效的平台，用来规模化，标准化，高效化地搞定这些事情，提高研发产能 低代码搭建平台“梵高”应运而生。

声音、文字、图片都是信息的载体，其中图片传递的信息更直观、更丰富。人们对于图片信息也更乐于接受，有研究表明人类通过视觉接收超过80%的信息。合理的利用图片，可以从中获取对我们有用的信息，以辅助我们做出决策，同时，我们也可以将这些信息再传递给他人。海拍客作为全国最大的母婴B2B2C电商平台，涉及20多万家母婴门店以及10多万商品，其中也包含了大量的图片，这些图片有各个商品的图片、门店内部陈列照片等。为了充分发挥这些图片的价值，我们对图像算法加以实践。

商详，顾名思义，就是商品详情页，商品详情是海拍客各商场业务购物主流程必不可少的一环。每次新业务搭建一个新商城，都会需要搭建一个新的商品详情页面。商品详情页作为用户了解商品（基本信息、价格、图片等）及相关信息（促销、优惠、服务、评价、店铺信息、商品推荐）的主要页面，通过这些信息来确定加购或者下单，最终引导成交。为了能够引导用户更多成交，各个业务都希望在商详添加业务价值信息在商详情露出，业务需求改动比较频繁；作为下单的核心链路，商品详情页需要保证高可用，确保不会中断用户下单。在稳定和高效的双重压力下下，急需对目前的商详的业务和技术实现进行体系化的梳理，然后做思考架构的演进方向。

是服务器选型选配没有做好导致的问题，还是系统问题，文件系统问题？

埋点作为商业智能体系中重要的一环，为公司提升产品功能、实施AB Testing、流量分析等业务决策方面提供了数据支撑。随着海拍客业务快速发展，对于精细化流量运营的需求不断提升，埋点数据质量差的问题也逐渐凸显出来，但埋点质量保障又是个老大难的问题，主要体现在以下几个方面：

1. 埋点链路涉及团队非常多，包含业务方，pd，开发（后端，前端，客户端，数据），测试，bi等多团队人员，各团队职责边界及团队协作问题，难度很大；
2. 缺少相应流程规范和系统保障，导致其中任何一个环节出错，都会影响整个埋点数据准确性，而且问题往往发现的不及时；
3. 涉及多端业务，包含ios，安卓端，web端，各c端小程序等，对不同端上的埋点数据保障和测试回归效率问题，带来了很大挑战；

因此，针对这样一个长链路 & 多端复杂数据问题，我们开启了埋点质量保障体系建设之路。

埋点是在应用中特定的流程收集一些信息，用来跟踪应用使用的情况，后续用来进一步优化产品或是提供运营的数据支撑。

一个APP及其背后的系统发展到一定程度，主要功能基本定型，想要持续保持用户关注度和使用率，再靠持续增加新功能来吸引客户留住客户就很难了。一般都是通过运营、内容、优惠活动等方式来保持用户的新鲜感和吸引眼球。通过在APP中插入埋点，来统计分析用户的使用习惯、偏好等信息，进而帮助我们通过修改页面布局、创建活动等方式来运营。

埋点重要，但埋点是否有效及正确与否，通过人工测试的方式是效率很低的，常用的方式就是人工操作APP，再通过抓包工具查看是否有埋点接口和参数上报，或者通过查询日志来查看数据是否被保存成功。如果能有一套自动化测试工具，就能极大提升效率，解放人力。

品牌和门店是海拍客平台的主体，针对门店和商品的营销生命周期的建设也是产品和业务一直在构建和优化的基础设之一；此次的“品牌门店营销生命周期”项目也是基于此背景和需要提出的具体方案，该方案的核心有两块：基于商品视角的门店生命周期画像和基于门店视角的门店偏好画像；前者在推荐系统，搜索系统等渠道中已经有了相应的落地和应用，但后者一直是我们平台的短板；尤其是门店对品牌的偏好，对购买时间的偏好，对单品的复购周期，对应季品的偏好等的挖掘。该博客正在在此业务背景中分享算法组在门店应季品，应季属性方面的挖掘实践。

正如前文介绍，门店应季属性 一直是业务和产品想挖掘的一个痛点，该属性的精准定位可以有效帮助门店及时发掘应季商品，不仅提升门店的销量同时也降低了门店的品类运营成本；但在以往的方案中，不管是通过业务规则还是在推荐系统中，对门店应季属性的发掘和认知都是后验性的，没有有效的方案可以提前准确匹配，只有等到这段时间之后才能通过统计或者经验汇总一部分应季品类，无法有效解决门店应季商品的问题；基于此业务背景，通过业务规则和统计方法构建了这一套门店应季属性的挖掘方案，以满足门店应季属性提前精准匹配的业务需求。

在业系统的迭代过程中，系统的测试用例的覆盖率依赖于测试人员对系统的熟悉程度的，即使是全部做白盒测试，也比较难保证100%的覆盖率，同时测试用例本身的正确性保证也是一个问题。基于这个前提，系统的发布就是有一定的概率会对线上用户的正常使用造成影响，引发客诉的。既然线上发布带来的问题，没办法100%避免，那缩小发布的影响范围就非常必要。

灰度发布就是一种缩小问题影响范围的常规手段。所谓灰度发布，就是使用技术手段，让线上发布的功能仅对线上部分用户可见，这样新发布仅会影响这一部分用户，不会影响其他用户。

尽量避免大对象的使用，大对象无法利用栈上分配和TLAB的JVM优化，会带来显著的性能下降，当然对GC也十分不友好。

目前APP+小程序的轻应用模式已经成为一种流行趋势，海拍客为了进驻toc市场，提升门店线上卖货的能力，推出了121小程序，目前在如火如荼的进行中。

说到小程序，一定绕不开的就是登录和授权, 好的登录授权流程和容错机制能够帮助小程序维持好的用户体系和保证功能的正常使用。

虽然看官方文档感觉就几个api很简单，但是为了保证121能够稳定的运行，避免因登录授权问题导致应用的阻塞，需要对这个流程好好打磨一下。

针对我在我的页面在静默登录、用户登录、用户信息授权相关开发流程中出现的问题和解决方法,以及一些个人思考，分享下小程序登录授权相关的内容。

在许多自然语言处理(NLP)任务中，通常会使用神经网络将单词从高维稀疏向量转变为单词嵌入(Word Embedding)，即单词的低维表示[1], 随着神经网络在各个领域应用的发展，这个概念已经扩展到NLP领域之外的其他应用。研究人员希望用Embedding的方式来更好的描述某些特征或者某些特定实体(Entity)。2013年，Bengio等[2] 扩展了这一概念，这里有一段直接引用，“...人们非常希望减少算法对特征工程的依赖,...人工智能只有学会识别和解开隐藏在低水平数据中的潜在特征，才能实现这一目标。”在这之后甚至出现了一门新的学科：表示学习(Representation Learning)。这一技术也迅速运用到推荐系统及推荐排序模型中，使用深度学习进行推荐的早期阶段的Wide&Deep[3]、YoutubeNet[4]中就出现了Embedding技术。并且由于Embedding技术能和NLP领域的其他技术很好的结合在一起，很多NLP的技术也由此迁移而来，带动了深度学习技术在搜广推领域的发展。

本文将回顾Embedding技术的由来，介绍它的算法及改进，以及它在搜广推领域的运用。

全链路压测在海拍客已经有2~3年的实践。海拍客是一家母婴互联网产业平台，致力于将海内外新的品牌、新的知识、好的消费理念通过全中国母婴店，带给三线以下城市的消费者，帮助消费者完成消费升级。

随着业务的快速发展，我们日常遇到的系统性能压力问题也逐渐出现，甚至经常会因一些突发的营销活动，导致系统性能指标突然暴涨，可能导致我们系统的瘫痪。最近几年，随着系统架构的不断升级，以及电商业务的多样化和各种促销活动，传统性能测试已不能满足现有系统架构的需要。

所以，全链路压测变得越来越基础 ，也越发重要。经历了两年多的全链路压测实践与总结沉淀，通过录制流量回放，模拟大促真实流量，串联线上全部系统，让核心系统流程成倍比的同步放大用户真实流量，海拍客压测平台和全链路压测体系已经能够承担起公司整个后台服务稳定性的重任。

本篇主要讲述下海拍客购物车中台发展及现状。

1、每次运营筹备大促活动，搭建活动页面总要花很多时间，主要时间花费在挑品上边，运营要通过人工取数挑品，这样做有以下缺点：

第一，效率较低，且这个工作量无法避免，每次都需要做；

第二，人工取数的规则无法沉淀下来；

2、不同的业务方对各种商品列表的个性化诉求越来越多，导致以下几个问题：

每次需求的定制化开发效率较低，且无法复用，代码可维护性变低；

开发资源优先，重复工作使得需求迭代慢，业务满意度降低。

为了解决以上的两个痛点，选品投放中台应运而生。

Java Agent这个技术，对于大多数读者来说都比较陌生，但是多多少少又接触过，实际上，我们平时用的很多工具，都是基于Java Agent实现的，例如常见的热部署JRebel，各种线上诊断工具（btrace, greys），还有阿里开源的arthas。另外我们大伙熟知的apm性能监控工具skywalking,pinpoint等都是agent的实际运用.那我们要怎么简单理解他呢 ,如果熟悉spring的读者应该知道动态代理技术,相对于agent技术,大家可以理解成一种jvm级别的aop技术. 有了它,可以在类加载前后增加相应代码,实现我们要的特性.

随着agent场景的普及,我们公司也在很多方面要用到agent带来的功能. 本文重点举例介绍3个agent场景,也是我们公司大量使用的地方.首先是apm调用链,大家应该对这个比较熟悉,业务迁移到微服务之后,服务之间的调用关系势必要借助apm工具来进行追踪的.其次是测试团队使用的覆盖率测试工具jacoco,另一个场景是我们在进行beta发布,全链路压测等场景需要对流量进行识别和传递,那么标签传递的过程中,会遇到大量的异步场景,调用走到线程池以后,标签会出现传递丢失,那么在这种情况下,目前比较流行的解决方案是接入阿里开源的transmittable-thread-local框架. 以上三个场景apm,jacoco,transmittable-thread-local等 ,都是基于agent(或者推荐使用agent方式)方式接入的,针对这么多agent,甚至以后会出现更多的类似场景,我们要怎么管理,引入了过多的agent以后会不会引入过多的风险?

关于营销，相信作为电商消费者，大部分人都不陌生，营销是一种运营手段，通过各种玩法刺激消费者下单，核心是让消费者认为花了更少的钱买到了商品，觉得划算！

营销总体分为：1. 传统的营销，比如最典型的优惠券；2. 互动营销，比如微积分玩法帮砍一刀；

本文内容，主要针对传统的营销玩法，阐述规则引擎再营销业务玩法中的应用。

业务系统在发展的过程中，业务的逻辑越来越复杂，简单的逻辑步骤拆分已经不能快速适应业务的变化，大部分时候都是在主流程上打补丁的方式进行业务支持。而且大量的业务逻辑被隐藏在实现细节中，无法从全局看到整体的业务流程。所以在此背景下，需要一个业务编排框架帮助我们将代码逻辑以组件化的方式组织起来，达到快速配置和快速了解业务全貌的作用。

海拍客是一家母婴行业的B2B2C平台，随着业务的发展，公司对数据化运营的需求越来越迫切。面对大量数据，数据工程师需要从多维度去分析挖掘数据价值，从而构建标签化数据体系，形成用户洞察和分析的数据服务平台，以此助力运营、采购、BI人员快速实现业务需求。

其中，DMP作为一个全面的数据收集、加工、整合平台，吸收各种数据源的数据，以门店、商家、商品为基本单位，清洗、整理形成结构化的数据表，并进行标签的计算，从而精准地描述各种目标主体。

目前海拍客采用Disconf作为配置中心用于配置相关的存储以及动态更新。其简单、实用的特点在一开始时能很好满足业务系统的需求，但是随着业务、系统的不断发展变得越来越复杂，Disconf本身只可以在配置修改时会一次性令所有依赖该配置的机器全部生效，有时候我们希望推送的配置能够只在部分机器生效，在被推送新配置的机器上观察新更新配置生效下的运行情况，再决定是否让配置在其他机器生效。这样如果修改的配置有问题时，则只会影响第一次推送的机器，也可以直接回滚配置。

在修改配置文件时，难免会产生文本编辑的错误，此时如果修改的是一些核心配置项容易引发大面积的报错从而产生大型故障！若使用灰度的方式，能先将配置在一台机器上验证，观察到错误后，及时回滚避免错误进一步扩大。

2021年的1月1号，新年伊始的2:27分，突然大数据运维同学在钉钉群中反馈，大数据的slave002节点是不是卡住了。

DBA和运维同学就着手进行排查。

DBA同学反馈，从IDC的大数据集群通过网络拉取阿里云的RDS数据库，确实耗时大幅增加，我们看下图中的Time字段，平时在分钟级别的，今天暴增到了小时级别，网络延时大幅增加。

早期，业务线同事都是使用公司内部基于 Jmeter 实现的压测系统进行压测。在使用过程中，发现压测数据准备起来很麻烦，而且自己造的数据总感觉不真实，丰富度不足。要解决这个问题，最好的办法是使用真实的线上流量进行压测。于是，一个新的需求提到了我们基础应用组 —— 提供一个平台，方便业务同学进行线上流量录制和回放。基于这个需求，我们展开了调研和选型工作，最终把目光锁定在了 GoReplay 上。

每条用例都要经历相同的初始化过程，导致整体增加了很多不必要的耗时。

在浏览器中，JavaScript是非阻塞的，事件就是一种用来通知正在发生的相关事情的机制，表示基本的用户交互以及其他浏览器内部的事情，JavaScript在接收到这个通知后才会执行相关的事件处理函数，避免阻塞主流程。不管使用什么样的前端框架来开发，与事件打交道都是不可避免的，但是前端框架可能会对浏览器原生的事件机制进行一些封装和改造，例如React就在浏览器原生事件机制的基础上，实现了一套事件机制，将浏览器原生的事件合成为React抽象的SyntheticEvent，并实现了一套模拟浏览器原生事件冒泡和事件捕获的React事件机制。

本文将分别分析原生的事件机制和React事件机制，来了解React事件机制的实现原理以及使用时的一些注意事项。

互联网电商公司每天都有各种各样的促销活动，需要大量的活动页面来承载。每个页面虽然长的不一样，但模块大同小异，无非是图片、导航、各种商品列表。如果这些页面都要开发工程师来写肯定不现实。淘宝京东这些大型电商网站都有自己的建站工具。运营模块化搭建页面，前端开发只需要维护模块就行了。

海拍客自研的建站平台叫YTMS，Y取自洋驼首字母，TMS意思为模板建站系统。从2018年上线至今，已经支持了公司的上千个促销活动和主频道活动。

在没有YTMS以前，我们只有一个模板活动工具，运营在上面新建一个活动产生一个活动id。前端通过这个活动id返回的楼层数据渲染页面。所有模块不管是否有用到，都会在用户的设备里运行。YTMS解决了这个问题，把每个页面按需打包发布到CDN，大幅提升内容的丰富程度。

本篇文章，和大家分享一下之前发生在生产环境的一次问题排查与分析过程，这个问题本身并没有特别复杂，但需要排查的同学足够的细心谨慎，能从监控及日志中提取关键信息，一步步缩小问题范围并最终定位到问题点，这个问题点一般都可以具体到一行确定的代码，即问题代码。但”问题代码“往往并不一定是”错误代码“，由于运行时因为一些其他因素，导致这行看上去完全正确的代码，运行出了不符合预期的结果，而这个结果也可能是偶发的，即它没有固定的发生条件，比如发生时间、发生节点和发生数据等等，这也是大部分疑难故障难以直接通过review代码的方式来定位的原因。

因此，我们排查问题时，切勿想当然，而是要严格基于现有的数据”大胆假设小心求证“，并适当使用排除法，真相一定只有一个。

单例有很多使用场景，比如无状态的工具类，日志工具类，全局信息类配置类等，实际应用也能有很多，比如说应用配置，一般用线程池的时候也采用单例设计，还有数据的连接池一般也是单例模式的。

1986年，机器学习界一代大神Geoffrey Hinton提出embedding的概念，倡导采用机器学习方法进行人工智能研究，进而探索通过人脑运作方式来运作机器学习系统。而受人脑原理的启发，他与同僚们提出“人工神经网络” (artificial neural network)，成为现代机器学习的基石。现在大家耳熟能详的，在工业界上大放异彩的word2vec，就是这个思想下的产物（在本文中我们也会将此方法作为基础多次提及）。而这个思想中最核心的一点就是向量化，把事物编码成向量，方便计算机进行各种运算，这也成为了目前工业界比较主流的一种解决问题的方式。

向量化也有多种方法，最简单的方法就是one-hot编码，但对于后续的运算会产生一些问题。例如要把汉字表示成向量，假设我们只编码8万个汉字，一个汉字的表示就需要一个8万维度的向量，大家凭直觉也能理解后续的存储和计算都绝非易事。究其原因，核心点在于这样的思路下，向量表示是稀疏化的且彼此之间相对独立。那么我们就需要走与之相反的一条路，让产出的向量尽可能多地保留住信息（类似压缩和编码），输出的结果通常是稠密的向量。这样的方法在业界多被称之为embedding，通常是事物在低维空间的向量化表示，也是本文所想要向大家阐述的向量化思路（通常辅以特征化的信息表示）。一个常见的embedding的例子就是颜色的RGB表示。自然界的颜色有成千上万种，但我们知道，任何一种可见光都可以由红色、绿色、蓝色这三种颜色的光混合而成，因此我们只需要一个三维的向量就可以表示所有色彩。颜色的RGB值就是这个三维向量，每一维的取值范围是0到255，分别表示三种原色光的强度。同理，对于汉字，我们也可以把它拆成指定数量的特征维度，字典中的每一个词都可以用这些维度组成的向量来表示。

实际工作中有很多需要树状结构来表示某些数据关系，比如省市区，商品的几级类目，组织架构等。

按照官方的说明java 的thread 有以下几种状态：

• NEW
• RUNNABLE
• BLOCKED
• WAITING
• TIMED_WAITING
• TERMINATED

会发现通过jstack 打印出来的线程状态不是这样的。

本文给出了一个通用Java IO API设计，并且有API的Demo代码。

更重要的是给出了这个API设计本身的步骤和过程，这让API设计有些条理。 文中示范了从 普通简单实现 整理成 正交分解、可复用、可扩展、高性能、无错误的API设计 的过程，这个过程是很值得理解和学习！

设计偏向是艺术，一个赏心悦目的设计，尤其是API设计，旁人看来多是妙手偶得的感觉，如果能有些章可循真是一件美事。

给出 减少艺术的艺术工作量 的方法的人是 大师。

奇异果TV作为在电视设备上用户活跃度最高的应用之一，为广大用户提供了丰富的内容播放服务。随着奇异果TV多年的发展，功能逐步增加，业务更加复杂，每次发版都需要经过功能测试、适配测试、线上灰度测试，但线上问题仍不能完全避免，需要及时对线上问题进行修复。

同时，由于电视端特有的商业模式和合作生态，App更新覆盖速度较慢，且更新操作较为复杂，对于以老人和儿童居多的TV用户来说，需要更快速地使用无感知的方式修复线上问题。

2023年8月中旬文档画中画特性跟随chrome116版本发布，基于该功能特性，我们于2023年10月中旬启动了B站跨页面播放队列功能的开发与功能灰度，并于2024年6月中旬完成了灰度全量。

实施走班制教学会造成教学班与行政班交错的情况, 课表的安排更加复杂, 对教学资源的需求会增加, 课表编排的约束条件也更加苛刻, 这种情况下实施走班制教学困难重重. 单纯手动排课不仅费时费力, 而且不能保证遵循所有的约束条件, 排出的课表难以满足教师和学生的需求. 课表安排是否合理, 对学校教学质量有着较大的影响, 因此需要一种高效智能的排课方法来求解走班制度下的排课问题.

近些年的解决方案有遗传算法 (Genetic Algorithm, GA)、模拟退火算法、蚁群算法、禁忌搜索算法以及混合算法等, 本文介绍一种基于遗传算法的排课实现方式.

Learn how Uber uses Apache Pinot for serving over 100 low-latency offline analytics use cases.

实时通信技术正在迅速改变我们的沟通方式，WebRTC（Web Real-Time Communications）作为这场变革的核心，为开发者和用户带来了无限可能。

本文主要介绍 接口隔离原则 在 React 开发中的应用。

文章概述了从用户输入URL到网页呈现的过程，重点讲解网页的开发、部署与发布阶段，包括前端代码编写、模块化管理、构建工具的使用、资源部署、缓存策略与动静分离，以及非覆盖式发布的资源更新方法，旨在优化网页性能和迭代效率。

软件设计模式是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。它的意义在于这些模式是众多程序员经过相当长的一段时间的试验和错误复盘所总结的宝贵经验，可以帮助我们提高代码的可重用性、可读性和可靠性。

本文讲述通过异质性分析的手段，能够帮助我们在实验中进行更精细化的分析，通过业务洞见和特征输入的方式，从而辅助实现策略的优化迭代。

列车运行图是铁路运输调度指挥的核心内容，是铁路行车组织工作的基础。而列车运行调度是指在列车运行工作中，因各种因素和突发事件的影响，使得列车运行的实际状态偏离预定值，需要不断对列车运行计划进行调整，以尽可能小的代价，尽快地恢复列车的有序运行状态。

本文以三个示例从易到难地演示一种名为JS RPC的技术。