徐立：今天跟大家讲的主题是PLIL的直播云服务实践。我跟别人有什么不一样，我觉得有几点，比较认真，我真的很认真。第二个，是有一个有产品的程序员，喜欢解决面对实际的问题，用具体的手段，解决一个非常具体的问题。今天这个主题分享是关于一群小伙伴们，经历的实际问题。解决问题过程当中，形成一个新产品，这样一个小故事。我们为什么会做这样一件事情，我们公司最早是做云基础的，但是在大部分大家接触的设施当中，用的协议，90%都是协议。我们遇到过比较特殊的，实际上就是我不想仅仅是通过上传下载的方式，进行输入和输出，我希望更快的方式来产生输入输出，所以我们做了这样一个事情。直播的特性，其实是面向成熟来讲，增加了标准输入和标准输出。
 
       直播的定义，它是指多媒体等数据，是以实时消息形式呈现给终端用户的技术。常见我写是这样，广告模型，有一个直播方，经过服务器，经过处理之后传递给终端，想看就是屏幕的分辨，或者是码率。具体的协议层面来讲，它其实比较混搭，输入这一层，推到媒体器上之后，可以转一些格式输出。还有HGL、HGS这些更丰富的协议呈现给观众，这是一个非常简单的模型。非常简单的模型，有非常难的技术挑战。本身来讲，TMP是实时消息协议，就是一个长链接，它收到的每个数据包，转发每个数据包，在整个网络层次，它的好处，它的颜色非常低，我们比如说现在非常多，我现在在讲，场外的观众是可以实时看到，这个基本上来讲，就是走向一个趋势。还有一种HLS，苹果提出来一个技术，苹果很认真，认真到你如果在苹果手机上播放视频，视频文件超过多大，不允许你通过视频方式进行点播，必须切片，就是下载的方式去进行点播。所以总得来讲，可以用来做这种直播，但是颜色会更高一些。
 
       这是一个更具体的对比，主要是跟平台相关的，RTMP的技术，在PC端在移动端需要做一些移值，所以平台上做移值。新旧的技术形态，直播的玩法比较高程度比较高，实施起来也比较困难。先让自己用一套服务或者是服务器，这样一个设施，其次还要购买这些商业的软件，再组成一个集群。同时还要去搞定网络的事情。这个其实本身来讲，技术的方案角度来讲，并没有什么优点，但是经济上会觉得更加可控。实际上来讲，这个是不言而喻。它的缺点也很明显，我们现在互联网的时代下，你的系统的附载，内网的很容易成为一个瓶颈，这是一个问题。另外一个问题，在移动端，你想有一些非常丰富的跟媒体的一些功能，但是如果就是说你用现有的路径来搭，自定义一些工藤的定义。技术玩法用我们现在已经做好的成熟技术，对开发者来讲，你只要用介入就可以方便，功能非常多，开发上面非常快，用户体验非常好，从经济层面角度来讲，唯一缺点，是有新的尝试，这个来讲也不算什么。
 
       这个是我们业务交互的逻辑。中间是我们服务的主体，上面AppServer，比如说一家互联网公司要做，可能有服务器也可能有终端。如果要用一个手机去做一个直播怎么做，服务器会先跟我们产生一个交互，之后拿到一个授权，分发给它的代授权。它的主播直接到我们这一边了。观众如果要看的时候，观众也是通过信息流，业务服务器，拿一个地址，拿到这个地址之后，这个播放页直接在我们这边产生直播的输出，不同的码率，等一些相关的参数。
 
       其实对我们来讲，就通了，但是从使用方角度来讲，它要做的事情要轻松，轻松的一个层面，它只需要一个代码就赋予了直播的功能。对它还来讲是一个纯透明的，多快好省，其次它跟我们的存储，它可以回放、点播，转成其他的格式提供下载。这个也是存储。基于我们这个存储，优势来讲，有一些技术上的红利。比如像我们刚才讲的存档，云端录制、转码、转存、下载，还有视频的提示转码，现在是播频，手机有不同的屏，经过不同的分辨率的情况下，需要转一下分辨率转一下格式。还有一个，像食品抽帧，截图，还有一些跟七牛现有API组合复用，这是什么意思，你可以把上一个输出和下一个输入连接起来，这是一个哲学。我们系统哲学，非常了解这一块，在这一点上，我们现有的和新的产品也是可以组合起来复用，还有我们昨天发布了，发现功能，很有限的情况下做一些处理，是一个扩展，功能性自定义的扩展。它的想像空间非常大，在业务需求的满意情况下，只你想不到，没有你做不到的事。
 
       这是它比较卡通的一张图，解释它有哪些模块，有转码的还有存储，有加速的，有打刀的。
 
       具体我们现在做这个服务，它已经解决哪些问题，或者说它已经开始解决一些场景化的问题。首先来讲，这个其实是非常普遍的，电台直播，可能大家日常生活中会听到很多，包括在手机上听到很多你在用音频，包括像一些网络电台，这是最直接的网络直播。还有教学直播，这个问题也是可以覆盖，到用户端。还有这种新鲜的，监控直播，有代表的，你可以在你手机上去看你家里，或者哪里的摄像头，可以看到那边实施的状态。还有一种现场直播，像我们今天这个活动，这个现场就是一个直播，这也是英文的场景。还有游戏直播，这个也是现在互联网领域里面，互动娱乐里面最火的一个就是游戏直播，手游的游戏直播。还有我们刚才提到的手机直播，大家的社交方向是这样，所有有很多移动互联网公司，从一片做的图片，社交，后来转视频的社交，发现没有太好的玩法之后，诞生一种新的玩法，就是手机直播的方式，随时随地拍直播，这里面我们提供了一个相应的手机直播，可以方便开发者很快用这样一个功能。还有一种场景，可穿戴设备，相机，里面可以装我们的直播的CDK，可以打通。
 
       它的产品是怎样的？我们自己是开发者，我们是做在那边开发这个服务，某种程度上是非常懂开发者的需求，产品形象是这样，服务器服务的意思。如果你要用真的就是代码进来，整个环节就打通了，并且在播控管理这块更加透明和开放。具体从技术的角度而言，直播数据是什么性质的数据，有什么不同和相同的地方？比如像直播的网络4跟成熟的网络还不太一样，成熟网络本身来讲不是传数据只是分发数据，数据本身，这个是有点不一样的地方。最典型的一个代表，延迟Delay。比如无线在做直播，场外要过多少分钟才能看到，所以延迟这块的要求非常高，延迟稳定的网络情况下，发送和接收的时间差，中间转发环节越多，延迟越大，这是网络层面的。
 
       这个延迟可具体计算，这是一个简单的表，是关于延迟的对比，我觉得还是非常敏感，大家觉得世界最敏感的生物可能是你们，但比你们最敏感是程序员。当你的系统实现的时候，你会需要用毫秒去度量一个东西，毫秒的概念一秒是一千毫秒，大家看到这个屏幕，你的差是40毫秒，根据爱因斯坦的定论，这实际从基础物理上限定了网络分子在进行这个过程中最高速率，比较可观非常快，每秒有30万公里，这仅仅只是在真空中的传输速度。我们现在网络实际上有物理这一层，或者介质，通过了这个介质之后有一定的折射力，比如像光纤，每秒可以传20万公里，这个算下来，从纽约到北美或者到伦敦或者整个地球跑一圈，它的延迟还是非常低，最多一次传递200毫秒，往返一次在400毫秒一秒之内就完成。
 
       信息科技带来不一样的地方，有非常大的价值。
 
       我们刚才讲的是物理延迟，一般很难区分你几秒延迟会怎么样。你的手机你将会延迟300毫米，如果有请求，刷一个图片，刷你的朋友圈，这个时候明显会感觉到你的图片在上传，这个时候跟这个延迟有非常大的关系。为什么？我们今天所有应用都是构建在这一层，它的普及在90%甚至95%以上，我们刚才讲的直播，其实也是GET，它的好处在不可靠的传输面上实现了一种可靠的传输的方式，它典型就是这样，每一次传的过程中，要经过这个过程，数据报往返过程，都会把往返延迟加进去。实际上大家可以很容易发现，如果短链接请求的话，复用长链接，这样的话可以提高。
 
       还有一个关键难点，是在抖动，就是网络突然抖了一下，这个时候从角度来讲，数据包是会重传，这实际上也会延迟。它会可控，非常精细这是一件非常困难的事。在传输速度这块，因为跟主播方跟观众是一个双边，有一个播放那端，另一边如果网络卡了，全局播放卡里，会受到全局的影响，卡了只是一个局部的影响。这里面你想作到高品质的数字，这实际上也是非常难。刚才讲直播整个网络都是在传数据，而且看上去的方式，就是每个数据包的经过，经过的延迟会多大性能上的损耗。
 
       这个是我们尝试之后，把我们架构进行改版。最早是这样的架构，前面有后面有一堆进行处理。这种方式有什么问题？其实也有问题，问题在于它专发邮件过多的时候，每一个都是要经过，在这种情况下如果你在进行转发，意味着你的开销存在增长。这样会带来，内部本身的延迟，实际上来讲还有一个不好的地方。后来我们最近一个架构的改版，其实把前端这些把内部的转换逻辑去掉了。它尽量如果过了一幕，就不在内幕有一个补充，产生一些大的性能上的开销，这样来讲它的好处变得更加快了，在性能上更加优异。
 
       第二个很快网络相关，最早的模型终端在我们这，再通过边缘网络分发，回到我们的集群。后来我们又进行了一个改版，推到我们这，边缘上进行广播。这样来讲，整个页面少有一些非常麻烦的环节。还有一个，终端是多种多样，对输出格式也是多追多样多样化的需求，有一种方式，是在更新，做转协议，再传递到边缘。这样的话，你在中心转多种格式之后，再转到边缘网络带宽也是非常拥挤的。这种情况下，你直接在节点之间直接通过实施协议，到节点之后在这个过程中处理，再产生输出。这样来讲，没有那么用度，在边缘进行一个输出的话，转发枢纽的话，对用户更好。
 
       另外一个经验值得分享是在多核时代，这个延续就是属于现在的传统。有这套服务器，这两个对比这个多，就只有两点，过去这种C语言按照内存编程的，内存会有大量的操作，包括安全锁这些东西，尤其是这些编程的时候非常复杂，但是在这里面，包括内存这块已经做得非常好。但是它在整个语言层面上由于田园的支撑，这样来讲的话，在你编写比较复杂的业务逻辑的时候，可以起到一个非常好的帮助你去理解业务的编程。
 
       所以就是说，PLIL这个东西，延续了我们的传统，我们最早是发布1.0的时候，就做了一个大规模的存储，它的可靠性是16个9，现在是11个9，我们在做另外一个产品的时候，都是这样，如果要做一个高的，也基本上是用G语言实现，做这个产品我们也是用Go语言实现企业级的直播云服务。这也是我们觉得比较有挑战的地方，因为我们在做这件事情当中，我们用了大量的文档，就是数据结构的定义，到逻辑的描述全部都参照了一遍，那些稳当都是几十页、上百页，按照那个标准进行一个实现，这里面的挑战非常大的。在整个社区找不到这个媒体跟媒体处理，你都找不到。我们去做这些哥伦布编码的时候，有时候还要直接去看英文，这里面遇到的挑战非常大。
 
       另外一个，我们刚才讲，我们是程序员，我们做这件事情也非常特别，我们的工作方式也特别，我们不在一块，分布在全国各地，是一种协同的方式，我们讲P2P多壳的方式，但是遵照P2P在网络概念里面是一种节奏，每个节点在P2P这个网络有这个网络的情况下，可以发挥它自己更大的作用。如果这个网络一旦丢失，个体其实不复存在，对应到团队管理当中，每个人在职级上就像平级的。但是有了存在，个人的价值可以更大，可以被放大，但是如果这个团队丢失，个体的价值也会非常微弱。
 
       所以说，我们在做这样一个事情的时候，我们也进行了一些新的尝试，在工作方式的尝试，这个尝试现在运行下来，到这个产品现在，已经做出来，成功的一次尝试。我们目前也在交替一些东西，这个有我们工程主页，大家有兴趣可以看一下，觉得我们这件事情有意义，也可以加入我们这样一个团队。谢谢大家！