视频直播早期创业团队的技术架构与选型
声明：本文来自「七牛云主办的架构师实践日」的演讲内容整理。PPT、速记和现场演讲视频等参见“七牛架构师实践日”官网。
嘉宾：赵琨，18 年的互联网老兵，屡败屡战的连续创业者，实用派技术的实践者，曾任 IT168 CTO，menllo 联合创始人，车易拍新产品业务线总经理，现任酷熊直播 CTO，主要负责酷熊的产品、技术与线上运营工作。
责编：钱曙光，关注架构和算法领域，寻求报道或者投稿请发邮件[email protected]，另有「CSDN 高级架构师群」，内有诸多知名互联网公司的大牛架构师，欢迎架构师加微信qianshuguangarch申请入群，备注姓名+公司+职位。
酷熊早期团队走过的弯路
早期团队的技术架构选型通常会走很多弯路，酷熊也是如此。其他创业平台在早期获取用户的成本非常高，与之不同的是，酷熊有一个近两千万级别的大 IP ，所以从架构之初，就要考虑到未来将面临的大流量冲击，因此对于架构设计比较重视。在赵琨加入之前，酷熊最早找了一个外包团队。因为当时酷熊做技术的人，不懂得架构怎么做。外包团队做了很长时间，产品却仍然无法上线，根本跑不起来。后来公司招了几个比较年轻的程序员，基本有一个小的团队在自己开发，把外包的产品给废掉了，这样又做了一段时间，结果发现还是做不出来。后面在酷熊 CEO 的邀请下，带着上一次创业失败的经历，赵琨加入了酷熊。赵琨加入酷熊后认为，只需对酷熊的前端产品调整一下就可以了，不需要做其他的事情，因为服务端大不了架构做的不好，把架构梳理一下，代码不会有太大的问题。但是事实证明他错了，早期开发团队做的是一个仅适用公司内部的视频会议系统，人少的时候没有问题，一旦人数乘 10，系统随时可能就挂了。所以他又重拾 PHP ，把整个产品重新开发了一遍。本次他的分享，即是希望把这个过程中的经验和教训，分享给大家。
互动直播的基本产品架构
酷熊是一个以星座话题为切入点的综合性视频平台，主要面对这样一个比较年轻的群体，产品主打单双人结合的互动直播。
1
图 1 是一个互动直播的基本产品架构， 分为视频系统、互动系统、用户系统，包括管理后台。视频系统包括直播和点播 2 大块；互动系统，就是在直播间里的一些消息，包括评论、弹幕、点亮、礼物、对主播的关注和粉丝的关注，还有就是把当前的直播分享出去；用户系统包括用户资料（头像、性别、年龄）、充值、好友关系等。
酷熊并没有做私信功能，赵琨更是建议刚开始做直播产品时不要加私信功能。为什么？因为加私信后主播没几天就容易被人挖走，酷熊是在权衡利弊之后，决定先不上私信功能的。”第一是我们平台没有那么大黏度把主播牢牢吸引住，第二是会有很多广告，比如注册一个账户过两天收一大堆的私信，这和酷熊直播文艺逗逼的气质不符合，所以酷熊干脆先不开这个功能。“赵琨如是说。
赵琨认为，一个早期的创业团队在产品开发上，一定要有一个优先级，优先级一定是前台优先，后台除了一些必要功能，其他的功能可以暂时往后放。赵琨还强调，不仅是酷熊这样一个小的团队，他服务过的很多很大的公司，后台其实也一直存在问题，但是后台确实能够提升管理和运营效率。
对直播的后台来说，用户管理、礼物管理、充值提现管理、房间管理、运营策略和数据，这几个功能是必不可少的。在用户管理上，有些用户可能在管理员巡查时发现存在问题，系统可以对他进行禁言和封禁。还有就是礼物的管理。直播平台礼物分大礼物和小礼物，大礼物是一出来之后有一个大动画，比如我们看映客中的飞机、法拉利、保时捷，这些属于大礼物，很贵，甚至有一些平台有土豪套装，比如说帝王套，一个要花费几千人民币。还有小礼物，一毛两毛这样的礼物，可以连发，一发 99 个或者 520 个。
对于酷熊来讲，礼物分为两个部分，一部分有动画，一部分就是看到数量和一个小图片这种。小礼物可以随时更新，可以通过后台的管理，把这个礼物的图片上传到服务器，做动态的更新。但是对于大礼物来讲，前端需要做礼物的动画渲染。所以这部分礼物一般分为两种方式，一种是不经常更新，更新日期为三个月或者五个月。这些礼物一般先打包，然后会有一个加载速度，比如通知用户他将有一个新的礼物需要下载放到本地。这里酷熊踩过一个坑，发礼物的时候要到云端取一个包下来，送礼的人走了，主播和送礼的人还没有看到礼物长什么样子，因为卡在通讯这块。这是一个很可怕的事情，因为礼物在直播里面非常重要的一种提升用户体验的互动方式，而且是目前来讲直播的一个盈利模式之一。所以礼物系统非常重要，一定要做好。
另外一个是充值和提现，涉及到现金流的管理。还有是房间管理。对于房间管理有一点非常重要，无论是从做产品本身，还是从国家的政策法规，都务必做到可以马上关掉一个房间，否则的话你将会很危险。当酷熊的后台监控到一个房间有问题的时候，会立即关掉它。
最后是运营数据和运营策略。不同的行业面向的用户群体不一样，运营策略会有很大的区别。以上是互动直播最基本的产品架构。
除此之外，赵琨强调，当你为产品做完用户画像以后，你一定要知道用户是谁，他们喜欢什么东西。例如，在礼物设计方面，同道大叔有一个形象，就是胡子拉擦的老头（其实他本人很帅），这个逗逼的形象非常符合酷熊的产品气质，也因此在酷熊平台上被大量的使用。再比如，酷熊 Logo 的那个小熊源自同道十二星座里摩羯座的形象，酷熊礼物里面的锤子一砸下去屏幕像碎了一样。赵琨说，酷熊会做很多好玩的礼物设计，经常会有主播说，酷熊的礼物很有意思。
酷熊的另外一个尝试是机器人。赵琨表示，几乎所有的直播平台都有机器人，只是没有说而已，但是他们的机器人最多能够点亮，通过这样的方式跟你做简单的互动。但是酷熊里面进机器人的时候，他会去和主播互动。比如他会告诉主播，其实我们机器人很可爱，你不要嫌弃我们，我们是酷熊的第一批原住民，比你来得早。比如说主播你觉得我这个机器人萌不萌。主播突然发现机器人居然能说话了，而且说话很有意思。后来他们跟机器人聊天，后来发现机器人不理他，因为我们没有主播跟机器人聊天。所以后来有机器人，进来以后跟主播讲，主播你好我是机器人，如果一会儿不理你的话，你不能怪我，我的网你懂得。通过这种方式，给了主播一个很有意思的体验，观众也觉得很有趣。甚至后来机器人可以模拟很多用户说话，通过提炼一些场景里用户经常说话，用户在看主播房间时，发现那个话是他说过的，也会增强用户体验。赵琨说，酷熊在产品体验用户体验上，没有强大到做真正的人工智能，所以就用这样的方式尽可能先简单化，但是这是酷熊的未来战略。
酷熊直播服务端架构
2
图 2 是酷熊产品的服务端架构。首先是建立 API 控制器集群，包括用户的控制器，房间管理的控制器，礼物的控制器，经验签名的控制器等。App 发起请求后，通过中间件对用户进行验证。对于跨域的请求，通过路由解析。然后中间加一层控制器管理，传统的方式路由直接是到控制器去了，但是这样在将来做分布式架构时可能会产生一些问题，所以在这里加了一个控制器的管理，也就是说路由过来以后通过控制器管理决定到哪个控制器，让它执行哪一段。这在将来做分布式的时候，可以起到很大的作用。甚至包括用哪个库哪个表，执行什么服务器，都会起到非常重要的作用。
另外是 Service 的集群，比如对直播开发流的鉴权、消费系统的鉴权、回调、消息系统、推拉流、转码、推送这些都是通过服务端来完成的。这里，赵琨特意提及他之前朋友公司的一个例子：当时系统遇到非常大的并发压力，一组一组拼命地加服务器都没法解决。原来是五台服务器一组，后来是五十台，但是发现无论加多少组该挂还是会挂。后来他们的投资人请了一个很牛的技术团队去帮助他们重新梳理架构，用了一段时间帮助他们把代码彻底的分离，形成一个基于控制器和 Service 集群的架构，然后把它分布到不同的服务器，对于数据的穿透又进行了一些改造，问题才得以解决。
一些小的创业公司，尤其老板不懂技术的时候，大家急着上线，往往是先把产品上了以后再说，然后后面再调。赵琨说，他所知道的能叫出名字的就有两三家公司，现在非常火，在早期也都遇到这样的问题。所以他认为，在早期开始创业时，就应该尽可能把这些问题绕开，否则的话将来非常难弄。他强调，做架构的时候接口和服务一定要分离，因为首先要保接口，接口的服务器可以无限的扩，比如说内存压力、CPU 的压力，通过监控系统看到压力过大，可以增加服务器解决你的压力问题。
就在分享的前一天，酷熊做了一天的压力测试，因为要推广导流。现在酷熊有两台服务器跑接口，基本上是 16 核 CPU、64G 内存的配置。做压力测试的时候，客户机，比如几台 PC 跑的时候，都挂了，完全跑不动了，但是服务器性能还是很好，CPU 的空闲在 50% 到 60%，内存表现也不错。
对此，赵琨的经验是这样的：
在结构设计合理的情况下，你可以不断地扩充业务服务器来消化你的接口压力。所以接口是第一重要的，就是用户要能够打开，进到房间后能够产生互动。
第二个就是 Service 集群，Service 集群把它分布到另外一台服务器上。如果将来你的服务，请求过于频繁，你可以把服务拆开，拆到不同的地方，然后通过中间件来控制，他到哪个服务器要这个服务请求。现在微服务有很多服务容器，我们可以尽可能地把服务拆的越细越好，这样可以避免你代码里面的一些高的一些耦合的发生。尽可能让每个 API 每个接口能执行多短时间就多短时间。因为耦合度关联太大，用户体验包括服务器压力都有很大的问题。
另外就是快速的扩展部署。当你的服务器顶不住，你能够通过加服务器来解决你的性能问题，而不要出现怎么加服务器都没用的瓶颈，这种情况下很可怕。然后数据库的结构尽量扁平化，避免关联查询，避免多余索引。
最后是使用 Redis ,尽可能不要穿透数据库。数据缓存在帮助优化系统方面能起到非常大的作用。现在大家都用 Redis，我们知道微博整个系统，微博的数据库只起到对于数据持久存储的作用，微博无论从读到写都是来自于缓存。酷熊也是如此，几乎所有可能穿透数据库的代码全部改掉，所有的读写对于数据的请求，全部打到 Redis 上，不再传到数据库，然后生成日志文件，后台负责去更新 Redis 和数据库。
客户端用户体验优化
秒开的业务层性能优化当你点开一个直播间的时候，立刻呈现主播正在直播，是一个让人心情特别愉快的事情。但如果你看到的是一个 Loading 在那儿转来转去，哪怕只是闪现一下，心情也会不好。酷熊直播现在尽量能够做到看不到 Loading。但是如果网络稍微差一点，还是会看到那个的讨厌的东西转来转去，仍然存在优化的空间。
对于秒开，酷熊的经验是：
第一先把流拉起来，然后再去加载其他的信息，包括房间信息、列表信息等，一定先让用户看到主播。如果先加载房间信息，把资源占上，拉流就会变得非常慢，用户进去的时候就会看到 Loading 。赵琨表示，七牛云目前在直播秒开上已经优化得很好，如果做不到秒开一定是业务层或 CDN 层面的问题。
第二是进入房间设置 500 ms 的延迟。这个是用户体验的权衡，是很反人性的事情，不符合传统上对于用户体验的理解。以前无论做 Web 端还是 App ，第一时间就应该及时地给用户反馈，比如点击的时候一定时候给用户反馈，甚至点击后给一个等待中的提醒也是给用户反馈。但是在直播的设计上，现在没有比这更好的办法，所以只能设置 500 ms 的一个假延迟，利用这五百毫秒拉流。五百毫秒时间很短，在你没有反应过来的时候，直播已经加载出来，这是在业务流程优化的经验。
对于热门列表，酷熊并没有做优化。比如当主播端的网很差，码率达不到要求时，再怎么优化都没用，因为他那边就很糟糕。所以酷熊单独开了一个进程或者多个进程，不断地检查热门列表，如果对它的数据不好，系统就会把他从热门踢出去。要做到这点，有两个方案，一个方案就是不断检测推流状态，不好就不推热门。另外一种方案是，把一些优质节点提供给热门。所以你看到的永远都是好的，不好的那一堆都在其他地方。这是如何从技术层面去提升用户体验。
避开点亮这个大坑
当时真实的业务场景是这样的：Cos 圈里一位非常有名的声优在酷熊做直播，当时那个房间人数不是很多，一千五百多人，但是服务器的压力却很大，甚至一瞬间接口不反应数据。问题出在哪呢？后面发现：这一千五百多人，平均每个人点亮了 50 次，都是她的粉丝。因为点亮要增加主播和观众的经验值，所以就发生了： 1500*50=7.5 万次的接口调用和数据库的 Update 操作，并且消息服务器产生了 1500*50*1500=1.125 亿次的消息下发。酷熊用的消息云是从 2 亿次开始计费，一个房间就会产生 1.25 亿次的下发，每天如果两个这样的房间，那么一天为点亮就要付出很高的成本。这个代价很可怕的，所以点亮这个坑一定要做优化。
第一种方式，在业务需求不变的情况下，客户端记录点亮用户的 ID 和次数，使用服务端配置的 TTL 来向业务服务器发送调用接口及消息服务器的消息下发请求。如果压力很大，则延长这个时间让它向服务器发送消息和接口。也就是说我发的是用户是谁，和他点了多少次。
然后反过来让他在客户端做动画渲染就可以，这是一种方式。这也是酷熊现在使用的方式，调整以后，系统现在点亮的消息下发量不到以前的三分之一。
第二种方式， 根据房间人数多少来设置点亮的动画频率，只有一个观众在第一次点亮的时候下发消息，其它的使用动画效果替代。只要看到谁点亮了就可以了，后面的冒泡都是动画渲染的。大多数的直播平台是通过动画做渲染，这是从客户端的优化角度考虑。
酷熊的技术选型原则和技术提供者
在技术选型方面，酷熊遵循 2 大原则：
原则1：在资源能够匹配上的情况下，使用的技术越新越好，利用好创业公司的后发优势。
在技术选型方面，对于创业公司来讲一定是越新越好。但是我们需要平衡一个关系，我们的资源是否能配置上。无论是自己研发，还是请外包团队，我们至少要懂得在技术选型和架构上面的一些基本的东西，否则的话会吃很大的亏。酷熊在技术选型上，第一个要求是学习成本很低，对于整个团队的学习成本都很低，但是最新是目前最好的。
原则2：第三方服务尽可能选择能够陪伴你成长的，服务到位的。优秀的技术服务商是程序猿的福利。
做直播平台的时候，很多的东西并不是自己开发，所以我们对第三方服务或工具的选择很重要。对于 PHP7 来讲，赵琨建议大家看一下 2016 年的 PHP 开发者大会，里面包括 PHP 的核心人员、鸟哥的一些分享，分享了他们在 PHP 上面踩过的一些坑。酷熊在 PHP 框架上选择了 Lumen ，专门为接口而生。赵琨表示，他第一次使用这个框架的时候就被它迷住了，代码写出来非常优雅，甚至不需要写注释，效率非常高。而且这个框架是基于中间件、路由、控制器这样一个架构，然后返回给相关接口。他表示这个框架非常好用，强烈推荐给大家。同时他建议大家在看文档时一定看英文文档，因为中文文档更新非常慢。酷熊的 CDN 和直播云服务提供商都是选用的七牛云。赵琨表示，酷熊最早选用的并不是七牛的SDK，后来发现很多问题。后面服务商更换的主要原因是酷熊提出的问题得不到及时有效的解决。这也坚定了他们在技术选型方面的一个非常重要的原则：第一这家公司不能太小，第二这家公司不能太大，一定是能一起成长的公司。
QA
Q：刚才听到你讲机器人说话，那个都是人工想的吗？
赵琨：我们来自于两个，刚开始都是人想的，是我们产品经理导了一些很逗逼的词语。后来我们对一些用户说的有意思的话进行了提炼，自动更新我们的机器人语言库。我们后面还会进行升级，加入一些简单的学习功能。你说的直接对话不会，但是我们会根据主播的兴趣和房间用户的一些状态，然后选择性的说一些可能更靠谱一点的话。
Q：你们做深度学习的话，初期是怎样开展的？
赵琨：其实深度学习这块，这只是一个部分。其实我们将来更多的深度学习是对视频的深度学习，比如说对于星座的一些视频的挖掘，这是我们下一步的一些战略。但是这可能不是我们眼前做的事儿。因为七牛也做深度学习这部分，所以我们也会看这个方面怎么合作。
Q：刚才看到你说有一个最大的坑，有没有其他坑？从您个人经验来看还有没有其他的坑？
赵琨：我觉得最核心的，如果作为技术管理者，一个技术人员最难的就是知道什么是对什么是不对的。现在的开发门槛越来越低，遇到问题有百度可以分分钟搞定。但是作为程序员来讲，第一你得知道什么是对的，你知道什么是对的，你才知道自己干的事儿是不是错了，这是第一。第二我们不断的做升级，然后大家一起找一个最佳的解决方案。否则的话我这个东西丢给程序员他做完了以后，容易出问题。比如对于我们的 PHP 特别信任，后来过一段时间我发现系统有瓶颈的时候，里面一些常识性问题都表现出来了，这是很可怕的。所以在座如果是技术管理者，一定要确认好。
编辑推荐：架构技术实践系列文章（部分）：
- 赵琨：视频直播早期创业团队的技术架构与选型
- 卢誉声：分布式实时处理系统架构设计与机器学习实践
- 陈斌：架构师的必备素质和成长途径
- 林伟：高可用的大数据计算平台如何持续发布和演进
- 柳宗扬：蘑菇街直播实战技巧带你解决直播开发难题
- 胡骏：详解自动化运维平台的构建过程
- 黄日成：从UDP的连接性说起——告知你不为人知的UDP
- 林昊：阿里超大规模Docker化之路
- 罗金鹏：双11媒体大屏背后的数据技术与产品
- 袁岳峰：手机端创新体验——手把手教你搭建VR&AR架构
- 张铭：双11背后的网络自动化技术
- 王鹤：Vue.js 2.0源码解析之前端渲染篇
- 黄日成：从TCP三次握手说起–浅析TCP协议中的疑难杂症
- 厉心刚：JavaScript引擎分析
- 蓝邦珏：来看看机智的前端童鞋怎么防盗
- 陈志兴：让页面滑动流畅得飞起的新特性：Passive Event Listeners
- 唐聪：大规模排行榜系统实践及挑战
- 左明：半小时深刻理解React
- 王照辉：魅族自动化测试架构之路
- 翁宁龙：美团数据库运维自动化系统构建之路
- 何轼：美团外卖订单中心的演进
- 申政：唯品会多线程Redis设计与实现
- 阿刘：千万级用户的Android客户端是如何养成的
- 卜赫：大道至简——React Native在直播应用中的实践
- 陈爱珍：从运维的角度看微服务和容器
- 孙其瑞：VR应用在直播领域上的实践与探索
- 刘丁：bilibili高并发实时弹幕系统的实战之路
- 秦鹏：从应用到平台，云服务架构的演进过程
- 郭炜：从0到N建立高性价比的大数据平台
- 李智慧：宅米网技术变迁——初创互联网公司的技术发展之路
- 陶文质：分布式系统设计的求生之路
- 魏晓军：React Native实践之携程Moles框架
- 学霸君姜波：耳目一新的在线答疑服务背后的核心技术
- 爱乐奇麦凯臻：在线教育的内容研发和技术的迭代创新
- 长虹李玮：老牌消费电子企业如何拥抱Docker
- 徐汉彬：日请求过亿的Web系统PHP7升级实践
- 窦威：AcFun的视频架构演化实践
- 傅鸿城：QQ亿级日活跃业务后台核心技术揭秘
- 宁峰峰：尖峰日96万订单，59校园狂欢节技术架构剖析
- 梁阳鹤：每秒处理10万订单乐视集团支付架构
- 沈辉煌：亿级日PV的魅族云同步的核心协议与架构实践
- 李任：携程Docker最佳实践
- 王海军：游戏研发与运营环境Docker化
- 史海峰：当当网高可用架构之道
- 黄哲铿：应对电商大促峰值的九个方法
- 1号店交易系统架构如何向「高并发高可用」演进
- 京东闫国旗：从C10K到C10M高性能网络的探索与实践
- 李林锋：服务化架构的演进与实践
- 1号店架构师王富平：一号店用户画像系统实践
- 唯品会官华：实现电商平台从业务到架构的治理体系
- 沈剑：58同城数据库架构最佳实践
- 荔枝FM架构师刘耀华：异地多活IDC机房架构
- UPYUN的云CDN技术架构演进之路
- 初页CTO丁乐：分布式以后还能敏捷吗？
- 陈科：河狸家运维系统监控系统的实现方案
- 途牛谭俊青：多数据中心状态同步&两地三中心的理论
- 云运维的启示与架构设计
- 魅族多机房部署方案
- 艺龙十万级服务器监控系统开发的架构和心得
- 京东商品详情页应对“双11”大流量的技术实践
- 架构师于小波：魅族实时消息推送架构