如何从零构建直播系统（后端篇）
本文来自作者 陈丽能@龙珠技术 在 GitChat 上分享 「如何从零构建直播系统（后端篇）」，「阅读原文」查看交流实录。
「文末高能」
编辑 | 哈比
起源
现在直播互动已经成为大家比较熟知的交流方式，我们可以通过直播沟通、学习、宣传、商业等，粉丝经济也是很多人加入主播的一个重要原因，人人成为主播，展示自己的魅力，技能，知识，让更多的人了解自己，有的主播也成为了一个圈子内的明星。
我作为一名技术人员，更关注的是如何搭建一套比较完整的直播体系，其中涉及到多少技术点、工具、第三方的资源等。
本文给那些愿意了解直播的技术人才和感兴趣的人士一点分享，希望大家可以有所收获，那我们开始了！
选择合适的直播流供应商
我们在多年的使用过程中，对接过很多直播供应商，比如网宿，腾讯云，七牛，金山云，阿里云等，各家其实都是有优势的。
目前我们使用的是网宿，腾讯云，七牛 , 金山云。我们目前的业务有直播，点播，直播转点播，点播转直播，回放，短视频等。
为了主播直播稳定，我们有的时候会提供多条直播线路，尽最大可能保证开播质量。对接的过程基本大同小异，而且供应商一般都有 demo 示例。
自建机房还是使用云
这个问题还是根据各个公司的发展需要来决定。龙珠其实一开始就走了自建机房的道路。我们目前有多个机房，分布在杭州广州，同一地区还有互备，杭州广州通过光缆打通。
我们选择自建确实遇到了非常多的问题，有网络硬件，供应机房问题等，但好处是锻炼了运维和开发团队，扩容和架构也比较灵活。
自建可以根据实际业务做更灵活的设计。使用云确实可以减少很多运维成本和很多坑，如果是刚起步的公司，可以先考虑云来快速搭建系统。
开播流程
直播互动功能
弹幕
直播里面最基础的功能，可以带动房间的活跃，有的大主播的房间更是可以看到满屏的弹幕，非常震撼。
我们的弹幕是采用 go 写的，可以支持非常高的并发和请求下发，采用 websocket 下发消息，写消息是写到 kafka 集群中，下发消息可以根据不同房间和全局下发。
支持灵活的限流配置和活动玩法，对于弹幕消息也会进行一定的过滤策略，净化平台的语言风气。
送礼
直播里面主要的收入来源。我们的送礼在后台有比较丰富的配置，可以支持单房间，多游戏，全房间，分品类等下发礼物配置，对礼物配置也做了非常多的改进，支持 pc、App、h5 的道具播放效果，上传更多的道具素材。
道具素材是我们的设计部非常用心制作的动态动画帧。送礼接口采用的是事件链的设计模式，支持更多的运营玩法，送礼逻辑我们采用同步和异步消费分开的方式，提高接口的响应。
对于一些异常送礼数据，我们也开发了对应的补单程序，在网络硬件和其他不可知的原因下，会自动补单，保证用户不受损失。补单程序的前提是我们要记录完整的事件过程数据，这也是一个比较复杂的设计模块。
活动
各种节假日，我们都会有很多活动，有送礼产生排行榜，产生宝箱，大转盘等。
这里我想说下，我们做了很多活动，所以我们已经抽象了一套活动系统出来，任何一个培训过的运营都可以比较方便的配置出一个通用活动出来，这里的通用活动主要是送道具产生排行榜。
在其他特殊活动中，我们也抽象出更多的活动模块，加快开发的质量和效率。
任务
我们的任务也是经历了几次改版，现在的任务可以支持更加灵活的玩法，最近我们上线了任务通关 100 关，效果还是非常好的。
在实现上，我们对任务系统做了大量的抽象，任务有单阶段任务和进阶任务，有新手任务和每日任务。
任务完成需要的条件也是不相同的，完成任务领取的奖励也可能是多个类型的。需要设计一个任务基类，增加进度，完成领取奖励的重载方法，还需要一定的扩展性。
座驾
需要支付龙币获取一定时间的座驾，进入房间会有比较炫的动画，这里涉及到扣费以后，给用户绑定一个有效期的座驾数据，进入房间检测用户是否有未过期座驾信息，前端做对应的动画展示。
靓号
根据用户喜欢个性有意义的号码的需求，我们设计了这个玩法。靓号的难点在于需要在平台各个露出房间号的地方支持靓号的露出和进入靓号房间功能。
vip 会员
需要支持一定有效期和进阶 vip 会员优先级的判断。vip 会员会有过期，需要处理如何过期，我们是判断 vip 的有效期已经过期，我们就主动更新状态。
进阶 vip 的功能范围会包含低阶 vip，需要在展示的地方优先展示高阶 vip。龙珠目前还有黄钻 VIP，紫钻 VIP，体育 vip，多个 vip 之间还需要很好的处理，要支持以后的扩展场景。
小游戏
我们平台目前也有不少小游戏，针对小游戏对接，我们有一套标准的对接方案，对接方根据方案可以快速实现对接，可以实现扣币，返币，查询订单接口，发送龙珠系统消息，对账系统等。
守护
也是有效时间的玩法，需要在入场和发言对守护用户做特殊处理，前端展示酷炫效果。
后台管理能力
实时结算系统设计
主播公会结算逻辑
每月 1 号根据之前每日消费数据，每日直播数据，主播公会基本数据，计算出底薪、奖金、分成、公会总表还有根据上个月各个活动计算出补贴费用。
每月 1-2 号为提现日，3 号会把提现的收入导入到结算表中，结算表按照月来存放数据。
后面几日会经过财务审核，把需要调整的主播数据确认调整后放到结算数据中，最后出确认报表，给主播和机构打钱。
多年踩坑经验
弹幕从原来的轮询调整为 websocket 下发消息
龙珠原来采用的拉取消息的模式是轮询方式，一般 3 秒一次轮询，房间消息会有一定的延时。
最近 2 年我们已经采用了 websocket 连接来下发房间消息，实时性更强。
实时排行榜
我们在做一些活动的时候会使用到排行榜，而产品的要求是要更实时，有些活动的计算逻辑还是有些复杂的。
我们一般是采用异步消费数据 (redis,kafka) 的方式去计算排行榜，然后通过页面轮询或者建立 websocket 更实时的下发数据，这样的活动需要考虑产生的数据频率和下发数据的客户端数。
多端异构，.net,php,go, 微服务的发展
因为历史的原因，我们后端采用 Asp.net,php,go 三个语言来架构系统，分工不同。.net 主要做主要业务逻辑，php 主要做网站前台和大量后台工作，go 主要做基础服务。
随着业务的发展，我们发现有些业务是多端重复开发，造成一定的资源浪费和维护成本。所以我们最近 1 年在做微服务的发展，已经迁移了部分业务到微服务。
微服务的特点就是可以拆分的粒度比较小，可以给多端同时调用，上层和微服务关联比较少。在以前我们改了底层的 vip 业务，就需要全站发布，影响面太多，而现在我们只需要更新 vip 这个微服务即可。
被恶意攻击，催生出强大的监控体系
grafana 监控主机和业务数据，我们可以很方便的查到哪些有压力的 redis 和 mysql，如果超过了预设的阈值，会有微信短信报警，帮助我们快速定位和解决问题。
对外对接产生的不靠谱，催生出方便的补单和回滚系统
我们会和很多第三方合作，这里会涉及到接口超时不可用，造成了异常订单处理的问题。我们在合作的过程中，不断完善我们的对外合作的框架，记录详细的行为日志，方便的补单和回滚系统。
App 版本出现异常，服务端紧急修复，版本审核比较慢等
我们的 App 版本发布都是非常重要的，因为 App 的特殊性，它不能像 pc 那样如果有 bug 更新下就可以，所以我们在和 App 对接过程中就要考虑到更多的异常场景。
比如会频繁更新的页面，是不是考虑用 h5 实现。比如接口规范，我们会在统一的 rap 中书写规范的接口契约，而且明确契约的责任是后端部门的。
比如多个 App 版本，同一个接口需要有不同的展示效果，那就需要考虑分版本的接口返回。我们 App 调用每个接口都会传 device,packageId,version。
自助式发布站点和服务
早期我们发布代码比较传统，通过 ftp，或者一台机器更新，同步到其他机器。
现在我们已经实现代码通过版本号或者分支一点发布，服务包括分布式服务都可以通过 jenkins 方便的发布，真的节约了很多精力。而且最近我们在做并行式发布，节约发布的周期。
中心的分工
目前中心分研发，app, 前端，测试，运维，设计，大数据，音视频，产品，项管，技术客服等，技术部磨合了 4 年，有很多经验的沉淀和积累。
我们也一直在推进一些基础体验的工作，比如视频流快速切换 cdn，h5 播放器，视频流防黑屏等。
总结
以上是我的一些从业的一点经验和总结，其实有很多系统可以再讲讲，比如送礼系统、结算系统、微服务化等，但我觉得我还需要更多的思考和实践，给大家多点实际的帮助。
希望大家可以和我多交流，我知道的我也会尽力解答，不懂的我也可以找人来解答，再次谢谢大家的时间。
顺便打个广告，团队招人，运维、开发 (.Net,Go,Php)、大数据、App、测试、前端、设计可以发简历到 [email protected]。
最后推荐一些学习资源地址：
https://www.zhihu.com/question/42162310?sort=created如何搭建一个完整的视频直播系统？
https://www.w3cschool.cn/webpo/webpo-cdnintro.html国内 CDN 产品价格和性能对比和介绍：励志成为较全的直播技术导航 AnyRTC
https://github.com/DyncLang/DevLiveBook
近期热文
《如何用 TensorFlow 让一切看起来更美？》
《Web 安全：前端攻击 XSS 深入解析》
《300万粉丝，全国最大的线上抽奖平台，深度解析》
《高可用、高性能？ 接口设计的 16 个原则》
《【钓鱼】与【反钓鱼】的技术剖析》
「阅读原文」看交流实录，你想知道的都在这里