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，分别表示三种原色光的强度。同理，对于汉字，我们也可以把它拆成指定数量的特征维度，字典中的每一个词都可以用这些维度组成的向量来表示。

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