(古玩图片高清真实的)
概览
这是一个简单的交互图，表示典型的生产者、消费者和服务方之间的关系，他们在平台中关心的重点也会有所不同。
需要强调的是，我们今天主要讨论通过技术手段改进优化服务并为消费者带来更加完善的产品体验，关于用户内容的部分并不在此次讨论的范畴。
简单总结下平台中每方关切的重点：
服务方关心平台的服务质量。
发布速度
发送流程与关键性问题
客户端是一个iOS或Android平台应用。
此服务端转码的目的是：
我想大家可以很明显地看出来这里有三个关键性问题：
后来我们重写或者重构了每条链路上一些关键节点的服务代码。
关键技术优化
下面我来介绍一下几个关键的技术优化点:
（1）在客户端，我们会将编码与上传合并到同一个流程里，集成了一个监控编码器的线程以监测编码器完成Gop数据编码的数量。
一旦此数量累计到一定阀值后会触发客户端的上传操作，客户端将这部分数据进行单独分片并上传至WebServer，在WebServer收到所有分片之后会进行Merge操作，最后上传至存储服务。
当完成这次低复杂度转码后，调度器会进行一次更高复杂度的转码，此转码完成之后原播放链接会被替换，整个操作流程对用户而言是无感知的。
最终分片完成后，每一片会被调度器分发到不同的转码器同时进行转码。
总结与结果
上述流程中我们主要做了以下三点优化：
客户端：将编码与上传合并为一个操作。
服务端：分等级转码。在发布阶段只进行简单复杂度的快速编码。
观看体验
下面我想与大家分享一些关于观看体验的优化，分享之前先为大家介绍一下产品形态与观看场景：
（1）产品形态
（2）观看场景
如果我们只做一些发布阶段的工作，用户在不同场景下选择不同产品形态看到的都是同一份文件。这种方案可能在某些特定的场景下能够带来比较好的体验，但是我相信对于大多数场景这种方案的体验应该都不是最好的，甚至很糟糕。
服务端转码细化
第一项优化是在服务端进行转码的细化，简单地说就是从原来的一个输出变为多个输出，这些输出之间主要的差别大概是以下三个维度：
编码复杂度从简单编码到复杂编码。
下发策略优化
我们会在客户端构建一个定制化的下发策略，根据产品形态与用户的网络环境、设备类型、屏幕的尺寸等硬件配置来选择一个符合此场景需求的编码复杂度、分辨率、格式等输出参数。
A/BTest
接下来要讲的是一种常见方法叫做A/BTest，大概分为四个步骤：定义指标、选择对照组、变更设置、对比结果。
定义指标
选择对照组
关于选择对照组我们大概有两种方式：第一种是随机选择，就是从所有的微博用户中随机抽取20%分成两个对照组。
第二种是按特征选择，可以确定用户具体的某一个特征，例如是不是大V用户或粉丝数量处于何种量级，甚至可以按照用户登陆终端设备不同来进行选择。
变更设置
这里其实还有一些其他的调整，例如是否启用客户端的软编、硬编、或软解、硬解等等。
对比结果
需要说明的是，选择对照组、变更设置、对比结果是不断迭代的过程，通过不断的去调整各种设置最终达到优化指标的目的。
Wi-Fi环境下自动播放
方案一：固定长度下载
当时此功能上线之后我们就发现了两个比较明显的问题：
简单解释一下这两个问题的原因，其实这两个原因都和下载方式不正确有关系。
带宽占用飙升是因为自动下载导致用户下载得太多，卡顿感是因为自动下载下的内容还不足以支撑流畅的播放体验。
方案二：固定时间下载
在用户浏览信息流的同时和这些信息将与播放链接一起下发至客户端。需要进行解释的是这个三秒是基于我们反复调整测试最终得出的一个最佳值，可以在明显消除自动播放卡顿感的同时控制带宽的占用。
总结
简单总结一下对于观看体验方面的几项重要优化：
服务质量
这句话有两个关键点：稳定、省钱。为了保证稳定我们做得更多的其实是一些类似于多机房部署等架构方面的工作，在此不再赘述。
降低成本
省钱，是指成本优化方面。在这里主要有两个降低成本的思路：
思路一：保持画质，提高编码复杂度，降低码率。
以为例，官方给出的比较有代表性的数据是，相对于而言其编码复杂度大概提升至后者的10倍，而码率能够达到的50%。
业务特点
热点判断
方案选择
关于方案选择，在这里我只是提供一些可供选择的思路，大概是有三种：
意义与影响
思路二：保持画质，保持编码复杂程度，降低成本。
思路二优化：多输出转码
但这里有一个前提就是其输出并不是只有一个而是多个。这些输出之间的差别可能就是分辨率或格式，其他的大部分的参数是一样的。
意义与影响
通过这种方式，我们可实现整体转码耗时节省15%左右。
降低集群冗余度
我们都知道现在很多的互联网业务都会面临一个流量明显变化的过程，例如一天中某个时间段会出现流量的高峰或低谷。
如果希望集群能够经受住流量高峰的考验就需要保持一个比较高的冗余度，可能需要保持1.5甚至2倍的冗余，才能在流量高峰时段保证互联网服务的稳定进行。
以下是关于此方面我们进行的一些工作：
消除差异
这些服务所需要的配置、运行环境，甚至实现语言都是不一样的，而每个服务都有自己的流量高峰与低谷。
这便导致了这样一个问题：如果按传统方式，需要每个服务始终保持一个比较高的冗余度，那么所有服务加起来整个集群的冗余度就会显得非常高，从而造成一些浪费。
所以我们需要做的是抹除这些服务之间的差异。具体来说是通过最近几年在后端领域很火的Docker技术将包括配置代码在内的整个运行环境打包成一个镜像，可以简单理解为一个压缩包。
我们所有的服务依赖的都是这种Docker服务，只要在机器上安装Docker软件就可以随时启用所需服务。通过这种方式可以将之前处于高冗余度下的四个集群转变为一个集群，此机群只要保持一定的冗余度就可完成服务的承载。
定时扩容
上图是微博大致的每天流量变化趋势，最右边那部分是晚8点到次日凌晨0点的晚高峰，可以说几乎每天流量都是以这种趋势变化，晚高峰时段流量会比白天大部分时间段高出20%～30%的样子。
面对这种情况我们会在高峰时段通过一些公有云服务扩充出的一些计算资源承担这部分高峰流量；当高峰期结束便撤下这些公有云服务以尽可能降低服务的整体成本。
弹性扩容
上图是之前鹿晗发微博公开恋情的半个小时内，微博一些核心服务的流量变化。可以看到从12点的值到最高峰，不到半个小时流量基本翻了4倍。
这种量级的上涨是无法通过诸如降级或流量调配等人工干预手段有效应对，这便要求我们的服务器必须具备快速且大批量的弹性扩容能力。
当天我们也是从阿里云上紧急扩容了超过一千台的服务器，最终将此热点事件造成的流量爆炸性增长化险为夷。
成本优化总结
简单总结一下我们在成本优化方面做的一些工作：
第三是根据业务的流量变化通过一些弹性扩容的手段来动态调整集群的规模。
p[古玩那些事儿电视]