从上述流量监控工具中选择适合您的，安装并按提示将您 app 的流量转发到工具里

· 在工具中的过滤器中输入“up?”

· 正常使用 app，就能在工具中看到上报的埋点日志

· 点击每条记录，就能查看上报报文的内容了

// 是否需要在发送追踪信息之前请求许可

// 是否追踪初始页面

// 最终的追踪js文件名

OpenFeign为微服务架构下服务之间的调用提供了解决方案，同时它可以结合其它组件可以实现负载均衡的HTTP客户端。

不同数据源采集的用户数据的关联可采用基于ID-Mapping技术实现id的数据关联。

当下数据关联实现主要选择第三方提供的服务和自行开发两种方式：

三方服务选择上有很多，可以利用阿里、华为、神策等厂商提供的各种相关解决方案或服务，有原生开发支持，也有直接的SAAS支持方式。以阿里的ID-Mapping体系的方案OneData体系为例

1）基于ID-Mapping用户数据关联实现可总结为以下三种：

①基于账号体系企业中最常用的是基于账号体系来做ID的打通，用户注册时，给到用户一个uid，以uid来强关联所有注册用户的信息。

②基于设备：那对于未注册用户可以通过终端设备ID精准识别，包含Android/iOS两类主流终端的识别；通过SDK将各种ID采集上报，后台利用的ID关系库和校准算法，实时生成/找回终端唯一ID并下发。

③基于账号&设备：结合各种账户、各种设备型号之间的关系对，以及设备使用规律等用户数据；采用规则规律、数据挖掘算法的方法，输出关系稳定的ID关系对，并生成一个UID作为唯一识别该对象的标识码。

a.从日志数据中抽取各种标识id

b.将提取出的标识id，去redis标识id库中查询是否存在

c.如果不存在，则新建一个"统一标识"+“id set”

d.如果已存在，则使用已存在的统一标识

采用图计算手段，来找到各种id标识之间的关联关系，从而识别出哪些id标识属于同一个人；

将数据表达成“点”，点和点之间可以通过某种业务含义建立“边”；然后，可以从点、边上找出各种类型的数据关系：比如连通性、最短路径规划等；

A.将当日数据中的所有用户标识字段，及标志字段之间的关联，生成点集合 、边集合

B.将上一日的ids->guid的映射关系，也生成点集合、边集合

C.将上面两类点集合、边集合合并到一起生成一个图

D.再对上述的图执行“最大连通子图”算法，得到一个连通子图结果

E.在从结果图中取到哪些id属于同一组，并生成一个唯一标识

F.将上面步骤生成的唯一标识去比对前日的ids->guid映射表（如果一个人已经存在guid，则沿用原来的guid）

主要通过实现数据导入工具，来实现对人工处理数据的采集；比如定制好数据模板，当人工填写数据模板后，在数据工具中导入上传，再进入大数据平台的文件自动处理机制流程中。

数据导出方法包含API导出、文件导出、消费消息数据、数据库导出、工具导出集中方式。

定制开发数据输出API接口，实现对外数据查询或导出数据文件，接口做成详细参照《2.2.1.3第三方系统API对接-接口规范性设计》，输出API的调用大概分为以下几个步骤：

通过做成的对外API接口，为外部提供数据输出。

可通可视化形式，提供页面级别操作，导出所需数据文件，前提也是需要获取到相应权限。

以kafka为例，通过消费实时数据来满足更多使用场景。服务端接到一条 SDK 发来的数据后，会对数据做一些预处理并将数据写入到消息队列 Kafka 中供下游各类计算模块及对外使用。

A.启动消费的服务器需与数据服务器实行鉴权，让消费服务器与数据服务器处于同一网段或者网络互通，且可解析数据服务器的host。

B.尽量选用兼容性的kafka版本，高版本服务端兼容低版本客户端，反之则容易出现兼容性问题

消费有shell、原生API等多种方式，可以选择一种适合使用场景的方式。

下面给出两种 Shell 方式启动消费的示例，使用 Shell 方式可以通过重定向标准输出将数据写入文件后处理或直接用管道作为其他进程的输入，可以对接各种编程语言实现的处理程序。

·可以将 stdout 输出到文件或作为其他数据处理进程的输入数据。

消费的数据的格式与导入时的数据格式基本一致。

可通过自行开发导出工具或第三方导出工具为外部，可通过下载授权数据导出工具获取输出的数据。

这几年，网络直播应用异常火爆，自李克强总理2015年提出“互联网+”行动战略以来，各行各业都在向互联网靠拢。

本人作为一个在流媒体行业沉浸了十年时间的老程序猿，由于自己所发表的一些技术博客与解决方案吸引了来自全国各地的互联网创业者、投资者、传统行业领袖前来咨询，这期间大家几乎都要问的一个共同问题是：

搭建一个直播运营平台需要哪些技术？投入多少资金？

下面就根据我自己的从业经历给大家做一下解释。

由于大部分跨界人士对互联网业务平台都不甚了解，所以大部分人对目前火热的网络直播平台也是只看到表像，看不到更实质的部分。因此，很多跨界人士都会片面的认为：建设一个直播运营平台和建设一个普通的内容展示网站没有太大区别，前期几万元投入足矣，大不了做2款手机端APP再投入十来万元，整个平台做下来有20万就足够了。然后，让你按照这个思路去做的时候，往往会发现到头来20万都打了水漂，连一个可以用起来的平台的影子还没看到。

说实话，倘若我不从事这方面工作，我和这些人的认识也是一样的。为了免于今后不再重复向人解释做这种运营平台为啥前期要有几百万元的资金储备，今天抽出一些闲暇时间和各种想投身于互联网运营的跨界人士简单介绍一下。

首先，直播运营网站并不是一个简单的企业网站或者图文网站，看下图可以说明问题。

其次，直播运营平台不是一个简单的内容展示网站+两个移动平台的APP。

仔细看一下上图就可知道，网站和APP只是用户端看到的直观表像，是用户层面的东西。你还要知道，在直播网站和移动APP的背后，还有一个强大的底层运营支撑平台，这些用户看不到的部分才是整个运营平台投入资金最多的地方。就像当你使用一款银行APP的时候，其背后有一个庞大的金融业务支撑平台在为你服务一样。

再次，前期把平台功能建设好之后，后期就不需要再投入更多运营资金了，只管发展业务等着赚钱即可，这个也是严重的误区。

当你前期投入了数百万或者数千万资金将整个平台建设起来以后，你会发现这只是马拉松赛事的起跑阶段。前期做了这么多充分的准备工作只是为接下来的长跑做一个更好的铺垫，跑到最后的终点还需要你持续不断的体力与精力投入，这个投入就是平台运维、不断扩容的服务器资源和带宽资源，以及更多的内容资源，这些都是需要有源源不断的现金流来支持，如果运营得当的话，你的产出会远远大于你的投入。

下面我从具体技术实现环节来讲一下自己的经验和体会。

首先，底层运营支撑系统的技术实现

1. 流媒体直播内容发布系统

对于这部分，用行业内的术语来讲，就是直播流媒体服务器系统。这个系统主要实现直播数据流的转发功能。如下图所示：

别小看这个直播流媒体服务器，它是整个运营平台的核心零件。它的性能与稳定性好坏直接决定者核心业务平台的稳定性与运营成本。

有人说，网上有各种免费的直播流媒体服务器软件，比如Live555、Red5等，还有人说可以用破解版的FMS软件去做。没错，如果用来做实验性平台，这些免费的或者开源的系统可以用。但是在决定将其用到自己的运营平台中使用之前，应该亲自去测试一下吧，不然就是真得对自己不负责任。只要测试后你就会发现，这些基本上都是实验室级的产品，无论在稳定性还是在性能方面都远远满足不了运营级平台的要求。所以，这就很好地解释了为啥各大直播运营平台都投入巨大资金开发自己的流媒体服务器系统了。倘若这些免费或者破解版的系统可以用这些直播运营平台（映客、一直播、花椒直播、腾讯云、阿里云、乐视云、优酷、爱奇艺等）投入更大的人力物力去开发自己的流媒体直播平台就没有任何意义了。

真正运营级的流媒体服务器系统，可以达到单机支持5000并发在线用户，这种核心系统通常都是用C或者C++编程语言实现，具有极高的资源利用效率。

这种功能模块如果要采购第三方的，费用大概在5~10万元/服务器授权。

2. 流媒体内容分发系统

用行业内术语来讲，这个就是流媒体CDN系统，它能够在多个节点服务器之间将直播内容进行自动分发，从而实现一点发布，全网播放，终端用户可以自动选择离自己最近的服务器节点来接收内容，

像优酷网、爱奇艺等专业视频网站，之所以能够为全国上亿网民提供服务，就是因为它们有一个强大、高效的CDN内容分发网络系统。

这种底层CDN系统通常都是由运营方自己开发实现，如果要购买商业运营级的功能模块，授权费大概在3~6万元/节点。而且，搭建一个覆盖全国的内容分发网络平台，通常要建设数百个内容分发节点，所以投入还是非常可观的。

3. 直播录制与点播回看系统

这部分功能实现相对简单，但是要达到更高的性能指标，还是需要投入很大的精力去做深入开发。通常，做直播录制功能大家都会想到ffmpeg，做点播回看大家也会想到用Apache或者Nginx，但是对于运营级的服务平台来说，如果没有了稳定性保障、没有了性能上的保障，那么你会发现运营成本会越来越高，运营效率越来越低，最终因为用户体验差，再加上资金链告急而迫使你还需要从底层重新开发，或者购买商业版系统来实现。

这部分主要实现节目的多终端适配。当你用PC终端推送一个1080P的高清节目流到流媒体服务器后，服务器端需要将其转换成适合PC、电视机、手机三种屏幕终端播放的不同分辨率和码流的节目。在日常做节目编辑和格式转换时我们往往会发现，对一个1080P的高清节目做转码时，我们用一台搭载Intel i7处理器的主机做处理都非常消耗资源，而且转码速度极慢，对于一个有上千个用户同时做直播的运营平台来说，这个压力就更大了，因此，我们必须要找到一种更合理的解决方案，既要达到更高的转码效率，同时还要能合理地控制成本，这样才能满足平台运营的需要。

在行业内，目前最有效的解决方案不是采用大量通用服务器+转码软件来实现，而是采用GPU这种技术来加速转码，同时还需要采用多进程模式来充分利用服务器的硬件资源，达到更高的性价比。

在这方面，目前成熟的产品主要有北京顺景科技的先锋云转码服务器和美国Elemental的MediaConvert（当前已经被亚马逊以5亿美元收购）。

经过测试，在性价比方面，我发现国内的产品比国外的要高出一倍。而且国内的技术在全球已经处于领先水平。

在当前的政策环境下，每个人都需要为自己发布的内容负法律责任。所以，平台要为用户提供一个真实可靠的权限控制机制，任何人都不能越权发布违规的内容，也不能假借第三方的名义来发布违规的内容。

这部分功能通常都是平台自主开发实现的，通常开发周期在2个月左右。

6. 计费、支付与订单结算系统

直播运营中的各个环节都会和资金流交互，比如主播的在线收入、主播与平台的资金结算、用户的充值与消费记录等。

这是业务支撑系统的核心，并且要求数据必须准确，由于是和自身实际的业务系统相关，所以这个功能模块往往是需要自主开发实现的。

实现方式主要是通过网站脚本编程语言 + MySQL/Oracle数据库。

当前，国家对内容的合规性审核要求越来越严格，各大直播运营平台都建立了自己的直播业务内容审核团队，通常意义上的内容审核是在节目制作完成后，而直播运营平台的内容审核是在内容的同步生产过程中。这样，由于内容生产者众多，每时每刻都会有新的内容产生，这就对在线的内容审核提出了更高的时效性要求，而且由于审核的内容数据庞大，单独依靠人眼去做内容审核的压力可想而知，因此我们必须充分利用计算机技术帮助我们做初步的内容合法性识别，机器无法准备判断的再交给人去处理，这样可以极大地节省人力成本。

这种系统的开发需要用到图像智能识别与比对技术，比如google的Tenserflow技术。所以，这种看上去功能简单的应用，实现起来却远没有想象的那么简单。

8. 弹幕与在线互动聊天系统

对技术方面稍有一些了解的人可能会主观的认为，弹幕与在线聊天应用实现起来很简单，网上也有很多这方面的开源项目，比如Workerman这类软件，通常都是基于Websocket的长连接来实现文字聊天功能，但是你经过实际搭建测试后会发现，这种聊天服务器在windows平台下只能支持256个并发，在Linux下只能支持2000个并发，如果采用这种技术来部署聊天服务器，则需要部署超大规模的服务器集群才能满足高并发应用的需要，这种方案对于大的运营平台来说投资巨大，所以极不可取。由于WebSocket协议使用了自定义的二进制分帧格式，把每个应用消息切分成一或多个帧进行传送，所以单个消息长度通常不能超过256字节；其次基于Websocket协议实现的聊天服务器采用脚本语言来实现，这导致了其永远无法实现高性能的应用。因此，你可以在网上看到这篇文章“”，它比较详细地解释了为何要投入那么大的开发力量来亲自实现高并发的弹幕系统。

实际上，bilibili的运营平台虽然花那么大气力实现了高并发的弹幕和聊天应用，但是它的实现方式也不是最优的，它走了很多弯路，最直接、最高效的实现方式应用通过C++语言自主编程来实现，这种不依赖于其它开源产品的实现方式，最直接了当，效率最高，不需要层层调用各个开源系统然后再层层包装。目前，北京顺景科技开发的聊天服务器可以支持数十万并发连接，并且支持的聊天文字消息理论上无上限，而这仅仅是基于一台几万元的通用服务器来完成的。

其次，应用层系统的技术实现

目前，PC端直播推流工具的开发是一项很复杂的系统工程，它涉及到多方面的专业技术，包括视频编解码技术、音频编解码技术、图像处理技术、多媒体封装技术、各种音视频方面的国际标准与实现、流媒体传输协议规范与实现、操作系统原理、C/C++语言编程等。

通常，要自主开发一个完整的PC端推流系统，往往要投入3~5年的开发时间。目前，行业内产品级的PC端推流工具主要有以下几款：

根据以往的项目经验，做直播运营平台不建议从零自主开发PC端直播推流工具，耗时太长，这与运营平台需要快速崛起的运营思路不吻合，最好找一家有实力的技术开发商做OEM定制开发来实现。

目前，Android端直播推流工具已经有几个可行的实现案例，比如javavc，yasea等，可以实现软编码与硬编码的RTMP协议推流，开发者也可以根据Android SDK自主开发实现，难度不是特别大。

这方面，Apple公司提供了比较好的支持，可以使用iPhone本身集成的GPU进行H.264硬件编码，实现起来相对容易。

这方面也需要熟悉专业的视音频编解码技术和流媒体传输协议，以及ffmpeg开源软件，刚入门的开发团队也可以参考其它第三方集成好的播放器模块，比如ijkplayer或者OPlyaer。

HTML5网页版播放器，实现起来相对容易，懂HTML5技术开发就比较容易实现，在Android和iOS端通用，此外，网上也有不少HTML5播放器的开源项目可以参考，HTML5作为当前各大主流厂商鼎力支持的标准，肯定是将来的主流。

Flash播放器在最新版的浏览器中已经默认不再支持，比如Firefox和Chrome，另外Adobe官方也已经宣布到2020年停止更新Flash播放器，将来各厂商均会大力支持HTML5标准，因此Flash播放器可以不用重点开发。

当前各大直播平台主要采用在线人脸识别认证，这方面阿里的芝麻信用平台提供了免费的开放接口，可以基于它做应用层的对接开发。

PC端用户站点模板相对简单，一般2~3个月即可完成，主要是UI设计要有自己独特的地方。

主要涉及Android和iOS两个平台的APP开发，可以采用HTML5方式做UI设计开发，将推流和播放功能集成进去，然后在2个平台上做封装，预计每个平台的APP开发在20万元左右，2个APP的开发投入在40~50万元。

再次，物理层服务节点的建设

在前面两步中，把基础软件平台搭建好之后，整个平台的主要工作就完成了绝大部分，接下来就是服务节点的部署。根据我个人的经验，通常在每个节点机房部署5~10台服务器，并且在设计上考虑到后期的扩容能力。

在服务器的选型上，可以选用相同品牌的服务器，便于后期的维护。设计时一定要考虑到服务的冗余和容灾备份，这点非常关键。

通常，每台硬件服务器的费用在3万元左右，一个节点的服务器部署成本在35万元左右。

按照这种设计，每个节点可以支持2~3万个并发用户，部署3~5个类似的节点即可满足平台前期的业务需要。

平台建设周期方面，根据团队的能力不同以及采用的技术路线差异，周期在6~10个月之间。

请注意：技术选型与团队建设很重要，如果有幸找到一个经验丰富的项目主管，会为你的项目带来事半功倍的效果。

综上所述，前期平台软件系统开发建设至少需要300万元以上的资金，再加上硬件与带宽资源的采购，需要至少500万元的资金储备。

和那些动辄需要2千万投入的大的直播运营平台相比，我们采用的技术实现路线已经节省了大笔资金，省下来的资金可以投入到后期运营中去，就像前面我说过的一样，基础平台建设好之后只是马拉松的开始，但是也是产出的开始，后期投入的运营资金会为你带来源源不断的现金流，如果你运营得当的话。

看完这些，我想你对这种平台的建设应该有了一个大体的认识与了解，有不同意见或者另有高见欢迎提出建议或指正，但是请勿拍砖，谢谢！