解决方案:给大家分享一款销售人员做信息的利器

　　解决方案:给大家分享一款销售人员做信息的利器

　　发布信息是销售人员最基本的应用技能。拥有一款简单易用的软件，会让我们事半功倍。在这里给大家介绍一款我用了很久的信息发布软件。

　　龙兴站特发软件。这是一款用了很长时间的软件，也是领导推荐给我的软件。在这么多年的工作中，发布信息的软件数不胜数，而这款是其中最令人满意的一款。它有一个最突出的优点，它可以完全让发表的文章变成你想要的样子，这对于对文章规范有要求的人来说更加突出。

　　

" />

　　软件就是这样打开的，具体怎么用就不用跟大家过多解释了。下面主要说说它的特点。

　　1. 刚开始使用会比较费力气，尤其是想要生成非常复杂的文章的朋友。采集的数据分为固定使用和随机调用，您可以对不同的采集内容进行分类存储。

　　二是呼唤信息自治。内容排版完全自定义，每类信息都有特定的调用标签，应用标签自行组装文章。

　　3、文章内容中的图片最好先上传到网站，调用网址。这可能被视为该软件的非智能部分。我已经习惯了，但我认为没有任何问题。

　　

" />

　　四、可以定义发布多少篇文章，什么情况下停止发布等功能。软件本身有账号登录、身份验证码账号更换等多种账号使用功能，但是在目前网络发布信息的大背景下，我使用的文章很少，一般都是手动登录后自动发文章。

　　第五，相对昂贵。这是一个致命的缺点。一年要几百块钱。用了这么多年，想自己做一个类似的软件，结果只是个半成品，成了发布信息的辅助软件。

　　对于每一位需要做网络推广的朋友来说，有一款适合自己的辅助软件是非常好的。这个软件不能像网上那些可以智能伪原创的，但是可以实现自定义规则的伪原创。让你发出的每一篇文章看起来都和原来的文章一样。

　　解决方案:兴盛优选大前端是如何做监控的

　　一、产品介绍

　　Prism是体验技术部前端效率团队自主研发的前端监控系统。整个系统由效率团队自上而下自主研发，为公司提供前端产品的性能和质量评估，以及错误报警和定制嵌入式服务已接入公司100多个项目.

　　2. 背景

　　之前在网上看到两组这样有意思的数据，在国外做了一个网页延迟对收入影响的实验。

　　用户容忍度

　　诚然，任何一家开始使用甚至自研前端监控系统的互联网公司无非就是越做越大。它不能简单地用肉眼和主观判断来定位在线发生的一系列问题。相反，需要大量的数据来定位和论证错误的原因以及运营决策的考量。自从社区电商受到关注以来，大型厂商纷纷入局，我司一直保持着一往无前的势头。无论是开发、产品还是运营，对数据的需求也在与日俱增。

　　一般来说，一开始，产品的设计开发或多或少都有“个人”的主观意图，每个人的想法都不一样。但是，当公司达到一定规模后，产品的迭代和上线就不是个人的“偏见”可以做到的了。任何没有数据支持的决策都很难让人安心，因为人是有偏见的，但数据永远不会说谎。公司核心产品迭代，每一次重要决策都是基于完善的AB Testing和小流量机制。同时，对于开发者来说，前端线上的问题是在用户一系列操作之后发生的，很难定位。导致错误的原因可能是机型、网络环境、接口请求、复杂的操作行为等。

　　3.探索过程

　　3.1 困难

　　对于一个纯前端的前端监控系统的开发，对于前端工程师来说难度并不大，但是需要承担整个系统的全链路开发，包括前端SDK的数据采集，数据清洗、数据聚合计算、前端可视化等等一系列的开发环节，都不是一件简单的事情。因此，棱镜的研发过程并非一蹴而就。一开始我们遇到了很多头疼的事情，比如：

　　开发多端SDK并统一数据格式

　　跨技术领域的探索与学习

　　高并发高吞吐数据处理

　　机器和集群的稳定维护和容灾措施

　　 ……

　　或许对于很多专门从事大数据处理的大数据专家来说，我们遇到的问题可能不值一提，但是对于从未涉足大数据领域的前端工程师来说，要学习的东西就更多了。资源的协调和统筹对我们来说也是一个挑战。

　　3.2 解决方案

　　3.2.1 数据采集

　　目前我们是通过某种侵入式的方式采集数据，即前端采集SDK。采集到的数据维度也非常丰富。Web端包括停留时长、接口错误（请求体、返回体、httpCode）、页面错误等，App端包括设备信息、网络信息、版本信息、手机系统、接口错误等。 ，Wx端的数据维度更加丰富，这里就不一一展开了。

　　大前端性能团队提供四大端SDK，分别是小程序SDK、AppSDK、WebSDK、ServiceSDK，基本涵盖公司所有产品。性能团队安排不同的人不断迭代不同技术栈的前端SDK。前端接入SDK流程也比较简单，这里以WebSDK为例：

　　前端工程师与后端沟通后，可以通过接口错误上报逻辑配置的方法上报错误数据。同时性能数据无需配置，WebSDK会自动采集性能数据。当然，前两类数据只是Prism的入门级数据。开发者也可以根据自己的业务逻辑自定义埋点，Prism也会接收自定义事件的数据。

　　3.2.2 接收和存储源数据

　　前端采集的数据会按照SDK规定的数据格式统一进入我们的接收服务。接收服务是Nodejs构建的多节点服务集群。源数据会被CLB控制，进入不同的节点进行处理和脏数据过滤。然后，接收服务将处理后的源数据随机写入Kafka不同主题的不同分区中。Kafka扮演着消息队列的角色，充当数据接受的“中间人”。前段时间，在一年前一系列活动的支持下，数据量爆发式增长，但接收服务稳定经受住了考验，服务和接口都没有宕机。

　　3.2.3 数据清洗

　　

" />

　　与前两步相比，数据清洗方案一直在变化，我们也在不断探索和学习的过程中。目前我们使用的是Kafka+Flink+Clickhouse的方案，这也是目前探索以来效果最好的方案。其实一开始，前端团队并不负责数据清洗。一开始是在后端小伙伴的帮助下完成的。Spark 还用于清理源数据。后来重构了一个版本的Flink（Scala版本）清洗服务。，但由于数据量和业务需求的激增，以及部门之间的精力流失，一直收效甚微。一时间，我们也接过之前的方案，不断优化技术方案和代码。在吸取了前人的成功经验并结合当前业务场景，在不断扩充人员资源和技术拓展学习的基础上，Prism数据清洗部分，终于收到了不错的回报。以下是我们探索过的几种解决方案的一些比较。对于我们棱镜团队来说，失败对我们来说也是一次宝贵的经验。

　　ES之前一直是我们的主要技术栈。数据查询和指标数据聚合都使用了ES。它越来越大了。查询和聚合的效率直线下降。虽然之前我们也通过不同的方式探索过ES，比如通过定时脚本离线计算等等，但是都只解决了一部分问题。随着业务需求的不断变化，ES已经难以支撑当时的业务。ES确实是一个强大的搜索引擎，它在日志和数据检索方面非常强大，数据计算和聚合不是它的强项。用Clickhouse代替是Prism发展壮大的必然趋势。

　　3.2.4 后端服务&前端可视化&告*敏*感*词*务

　　“任何问题总有解决办法”。翻过前面几座大山，终于来到了我们服务团队擅长的部门。Prism 的后端服务是使用 Nodejs 开发的。目前已提供40+指标数据和20+openApis，包括应用的日活、月活、界面表现、页面表现、自定义数据、页面和界面错误（错误模型、版本错误、网络状况、httpCode... )等，同时，我们将在棱镜平台上以图表的形式直观展示数据，并不断拓展数据维度和优化交互，让用户更便捷地获取有用信息。以下是 Prism 平台上的一些图表：

　　棱镜平台-小程序健康

　　棱镜平台——优米健康优化

　　棱镜平台——青牛系统健康

　　网格站3.0模型分布

　　客户端小程序手机系统分布

　　自定义事件

　　用户行为流

　　告*敏*感*词*务依赖于企业微信的机器人，通过在Prism平台配置机器人的webhook地址和自定义告警规则（最大受影响用户数、最大错误数、最长告警时间、最短告警时间）。一旦连接到 Prism 的应用程序达到报警阈值，企业微信机器人将发送通知。同时，通过点击通知卡片，可以看到错误详情，帮助开发者快速定位线上问题。

　　机器人配置

　　企业微信群

　　Sentinel 详细信息页面

　　3.2.5 机器和集群的整体架构和维护

　　Prism平台整个开发环节比较长，衍生的服务和机器集群也很多。如何维护机器、集群和服务，如何实现服务的可靠、可维护、高可用，也是我们面临的问题。问题。我们团队参考了业界比较成熟的监控服务方案：Alertmanager+Promethues+Grafana+Nodejs+企业微信机器人。安装抓取各*敏*感*词*能数据的SDK，汇总到Promethues上。Grafana表盘上提供了官方的报告脚本，比如Kafka的top消费是否延迟，内存是否不够，CPU是否未满，我们都一目了然。同时，一旦服务宕机，Promethues会根据我们预先设置的报警阈值触发我们的报警接口，并将机器宕机发送到我们的企业微信群，然后我们的异常重启脚本就会相应的被屏蔽掉。触发重启服务。

　　目前，我们主要依托于公司内部产品——测量平台。我们在测量平台上配置机器所有的性能消耗和服务运行，定期观察机器和服务的运行情况，努力贯彻研发方针——减少这种协同效应。我们把精力放在代码的优化和数据维度的扩展上。以下是我们监控的一些截图：

　　

" />

　　测量平台

　　至此，Prism的整个开发环节就完成了。回顾整个研发过程，任何一个环节都是不可替代的。正是一个个问题的攻克，才有了现在完整的自主研发的前端监控平台。下面是棱镜的整体*敏*感*词*：

　　棱镜技术架构图

　　4. 棱镜数据能力输出

　　4.1 A/B 实验的补充（Picasso）

　　Picasso是我们大前端性能团队的另一个重要产品，就是全流程自动化A/B实验平台。其中，本平台的数据能力全部依附于Prism平台的输出。同时，Prism平台的数据维度和数据扩展能力也因为Picasso的存在而大放异彩。正如我开头所说，任务者都有自己的“偏见”和强烈的主观性，但数据是不会说谎的。公司核心产品迭代，每一个重要决策都建立在完善的AB Testing和小流量机制之上。Picasso项目成立以来，性能团队调集了集团各部门的人力资源，在几个月内，完成了数据采集端、服务器端、数据端和前端UI。目前，Picasso已针对C端用户的小程序重大营销活动进行了多次A/B实验，反响热烈。后续还计划接入App端和H5端的A/B实验。值得一提的是，在几年前C端各类营销活动的支持下，数据量呈爆炸式增长，Prism平台稳步协助Picasso支持A/B实验。以下是近期几次A/B实验的部分实验报告。后续还计划接入App端和H5端的A/B实验。值得一提的是，在几年前C端各类营销活动的支持下，数据量呈爆炸式增长，Prism平台稳步协助Picasso支持A/B实验。以下是近期几次A/B实验的部分实验报告。后续还计划接入App端和H5端的A/B实验。值得一提的是，在几年前C端各类营销活动的支持下，数据量呈爆炸式增长，Prism平台稳步协助Picasso支持A/B实验。以下是近期几次A/B实验的部分实验报告。

　　毕加索 - 实验室报告 1

　　毕加索 - 实验室报告 2

　　4.2 跨部门数据合作

　　4.2.1 仿真平台数据协同

　　Prism平台对外提供数据输出能力，通过openApi向业务方传输数据。

　　仿真平台是物流平台测试线自研的平台，用于采集、记录线上线下流量，快速生成流量回放脚本并回放（回归验证）。主要用于单界面自动化和流量播放。目前在物流平台线上推广使用。其中，部分数据是依托Prism的数据接口实现的。Prism对线上业务产品中的接口调用进行聚合、计算和分析，为测试人员提供输入参数、返回体、Header、错误响应码等接口数据维度。测试伙伴在业务中使用Prism提供的数据，推动整个业务线上产品的有效迭代和优化。

　　测量平台

　　4.2.2 自定义数据推广应用

　　现在接入自定义事件的产品有20+，其中推广力度和业务粒度最广的是悠米的运营和仓内的一些APP。比较棱镜的数据作为日常工作，数据维度需求不断更新迭代。同时，仓库的Web应用和一些分拣APP也会接入棱镜的埋点，产品会利用棱镜的数据来衡量员工实际操作的重点和后续产品迭代和优化的一些操作方法比较的基础上，下图是部分数据截图：

　　网格站点埋点数据

　　悠米电饭煲埋点数据

　　五、未来规划

　　目前，Prism前端监控平台实际上已经覆盖了推广区90%的前端项目，大家已经形成了产品接入Prism的意识。在这种情况下，对我们棱镜团队来说更是一种责任和挑战。我们目前提供了很*敏*感*词*和数据维度，但是在细节和交互上还有很多不足。这些也是我们急需解决和改进的地方。俗话说，“天下难事，必易行；天下大事，必从细”。事实上，市场上有很多成熟的监控平台，如Sensors、Bugly、友盟、Sentry等。在开发过程中，Prism一直在研究和借鉴优秀的同行产品，

　　同时，我们的效率团队一直忌讳闭门造车。Prism一直以跨部门、跨平台的合作为努力方向，我们的服务对象不局限于前端部门。同时，我们一直在尝试使用我们兄弟部门的优秀产品。例如：2021年下半年，我们将依托琉璃塔，将棱镜在线的全链路后端服务全部打包发布，简化了我们的发布流程，大大提高了我们的开发效率；所有uat服务都迁移到星斗云，降低了我们的维护成本。在未来的规划中，我们计划将Prism数据端的服务托管在公司的数仓平台上，我们将投入更多精力优化数据维度的交互和深度研发。毕竟听真话有优先，文艺有专攻，仅此而已。

　　Prism作为前端监控平台，肩负着获取产品洞察*敏*感*词*能的责任和规避风险的义务。同时，不宜一味追求数据的广度，应加强对数据的深度挖掘。应该结合公司的业务场景，从开发人员、产品、仓库员工的角度，多角度思考和衡量产品的有效迭代，提高开发人员的效率。最后，用屈原的一句名言来结束本次分享。“路漫漫其修远兮，我将上下求索。” 我会与你分享我的鼓励。