转：架构师实践日｜亿级短视频应用秒拍的架构实践
转自: http://mp.weixin.qq.com/s?__biz=MjM5NzAwNDI4Mg==&mid=2652190131&idx=2&sn=6672422564e9cf0816d0314824cb77bd&3rd=MzA3MDU4NTYzMw==&scene=6#rd
架构师实践日｜亿级短视频应用秒拍的架构实践
秒拍的系统架构
产品的演进、用户量的增长推动了技术的变革，下面是秒拍的技术架构图。
最上面 Web 和 App 是直接面对用户的，还有微博和其他合作方的合作也是在最上面一层。直接面向服务的是业务逻辑的 API，比如一些活动和视频的列表展现和用户的一些列表展现，都是在 API 里面有提供。这些 API 视频和用户分为用户服务和视频服务，现在已经在划分了。用户服务和视频服务他们依赖于很多底层服务，比如说用户关系、计数、搜索、Push、推荐、敏感词过滤、Feed、存储等。
用什么写业务
一开始秒拍是用 Java 加 Mongodb 做的，之后因为 PHP 平台开发效率很高，再加上 Mongodb 写的一些限制，所以我们迁移到了 PHP、Redis、Memcache、Mysql 等典型的后端语言和基础设施。我们的机房部署主要是新浪私有云平台，还有一些业务放在阿里云。
大并发、大数据量下的一些小问题
去年小咖秀突然火起来，秒拍和小咖秀的视频和用户量爆增，暴露出了业务中的一些问题，比如 Web Server 大爆503，体现在业务中大范围不可用，主要是联通机房，503报警频繁。直接原因主要是 PHP 连接时间过长，导致 PHP 超连接数，根本原因是因为 Mysql 业务需求变更，新来的需求加个索引，如果这个表里面没有数据，会与其它表连表查，这样就会导致问题积累，table连接过多，子表查询也太多。还有很多 count（＊）计数，count（＊）计数本身是非常耗 DB 的 CPU 的，统计频繁会导致 DB 的 CPU 压力过大，返回时间过长。PHP 这边写业务主要是因为它快，它处理完后，快速结束，快速释放资源，它如果堵塞时间过长的话，Server 这边等待连接过多，就会有频繁的503。另外一个问题就是 Mysql 断连。因为 DB 列表肯定需要设置一些 timeout ，防止连接超时时你的 sql 不释放连接，一直卡在 DB 这边。所以如果业务查询压力过大，或者是表连接过长，或是表格的复杂操作，超过 timeout 时间就会导致断连。因为业务中没有兼容，500就会突然增多。解决方案是我们这边 count 查询统一走计数器，计数器迁移出来作为一个基础微服务。同时，我们把数据表结构，重新进行了 review，把不合理的字段重新划分，相应的索引进行划分，还有一些不合理的产品需求也进行了更改，还有就是部分字段进行了冗余存储，因为查询一次写之后它基本上就是不会变更了，然后就进行冗余存储。优化结果是503、500基本上没有了，业务查询 SQL 更简洁，查询效率也很高，开发人员写起来也比较爽。
还有一个问题就是 mysql 这边因为历史数据堆积，历史数据没有进行拆库拆表，单库、单表的容量很大，DDL 操作成本会很大。增减一个表的字段或者加索引的话，很容易影响主从同步，还会会拖慢业务请求。同时 DBA 这边心理压力也比较大，因为新加一个字断，改一个字断，加一个索引，会影响业务，投诉会很多。这样可能会表的修改会拖慢，查询性能也会下降。mysql 这边有些数据是放在 redis 这边，redis 这边主要的问题集中在实例过少，还有就是数据分布不均匀。因为你的业务不能用到实例就去连一下，另外一个业务用的另外一个实例又去连一下，业务它的用量可能分布不均匀，就会导致数据分布不均匀。关键就在于有的业务一个 key 里面存放了大量的数据，然后它如果有一个复杂操作，Redis 这边又不太兼容，就会影响到其它的服务。解决方案也就是比较常见的，就是进行拆库，拆表。然后我们这边也划分了核心业务和非核心业务，根据业务属性，拆分数据库，核心业务与非核心业务互不干扰。Redis 这边也根据业务类型、操作复杂度，划分了 Redis 实例，业务、服务之前互不干扰，离线计算不影响在线业务。
我们还做了其他业务优化，比如说耗时在线逻辑异步离线处理。缓存治理是优化不合理缓存、复用缓存、减少不必要字段查询、降低网络传输延时。还有一个是功能模块服务化，比如说关系服务。请求合并与压缩是正在做的，业务逻辑 API 一层直接提供客户端，但是它的内部可能会分成很多的子模块，传统方式是一个子模块一个子模块，一个子服务一个子服务地去请求，出问题以后重试一次。我们这边做的是获取服务的数据，降低网络延迟。视频上传完之后，在业务层要做处理，比如说消息 fanout，通知后端服务，后续处服务进行异步化。
核心业务上传和播放
秒拍是短视频，每个视频大小基本是两三兆以内，我们是直接用了 HTTP 协议进行播放和上传处理的。上传流程可以简单看一下，如下图。
客户端向业务逻辑服务器申请上传，然后业务逻辑服务器告诉它使用哪个上传点上传，之后它可以选择七牛或者是新浪 S3存储上传分片，传完之后进行合并，七牛云服务器会通知业务服务器，它已经长传完了，之后业务服务器去做视频传完之后状态的更新，然后再到客户端，处理完成。接下来进行转码和截图服务，转码和截图服务很多是依赖第三方的服务，比如七牛、新浪 S3。其实上传工作我们这做了很多优化，比如特效预览、特效处理我们是放在手机端处理，如果放在业务服务器或者是业务服务里面，它会承受很多转码处理的压力，然后客户端资源是闲置的。而且手机端它需要处理完之后预览，用户未必说选择这个特效之后就不用另外一个特效了。再加上手机端的功能现在已经比较强大了，所以视频处理可以先在客户端做好转码压缩之后，再向业务服务器进行上传。
接下来讲播放，播放流程最简化的就是客户端先去请求资源地址，因为是 http协议，它下载了之后，直接播就行。这是最简单的，但是我们一开始不是提供的源文件地址，而是走我们的一个调度服务器，然后调度服务器去请求播放。它的视频有可能被审核删除了，它会去请求我们的这个服务器，然后我们的调度服务器给他验证他视频的状态。
还有一个是我们这边做了一个 GSLB 的播放调度，对用户按地区的播放情况，进行实时分析，然后预算结果放在调度上面，客户端请求的时候会直接拿到播放的最优的 CDN。我们在第三方 CDN 之上也做了一层播放数量统计和分析调度。我们是通过 Nginx+Lua，它请求之后，根据它的上网信息然后快速返回给它调度的 CDN。请求完之后，快速给用户想要的，轻量又高效。
上传完成后续处理
视频上传完之后，它在业务接口里面只是改了一下状态，用户可以正常播，然后后续处理是异步来做的。比如说 Feed、审核、Push、封面图处理、还有其他服务。这些消息 fanout 成多份，然后通知其它的服务。
Feed 是基于好友关系的视频列表，Feed业界比较常用的数据更新模式一个是推，一个是拉。推的话就是一个用户上传完视频之后，把我们的视频信息推到每个用户的个人 Feed 列表里面。然后是请求完之后，我去取一下看看我关注的人是不是更新视频了，再对之进行排序展示。我们这边针对大粉丝用户，粉丝Feed其实是采用拉的方式，然后部分用户采用推的方式。推的时候也要基于用户粉丝活跃度进行推送，因为他粉丝有一些事僵尸粉，或者是一些不活跃的，这些就不给他推。
这主要是 Feed 流程，用户发布一个视频，然后它自己增加一条 Feed 记录之后，Feed 服务会根据用户关系更新好友粉丝的 Feed 列表，如果好友想看一下我关注的人发了什么内容，很快的可以看到。
然后是封面图审核和处理。虽然是视频处理尽量往客户端走，但是客户端处理审核截图本来就是不太合理的，一个是传输它需要往服务端传，这个和用户的正常使用其实是没有多大关系的。我们这边审核服务是对视频帧进行抽取的，生成审核截图提供给审核员使用。现在我们也有使用第三方的服务，比如说图谱。所以现在的审核机制就是自有审核+图谱分析+人工审核。还有就是我们秒拍跟其它合作方合作，可能会生成各种不同尺寸的封面图，这也是一个独立的子服务。
核心业务的一些高可用设计
因为上传和播放属于我们的核心业务，如果一个区域或者 APP 不能上传，会影响到整个公司的业务，播放也一样。针对于这些核心业务，我们做了一些措施。上传高可用，主要是我们采用的多云的方式，主要是新浪 S3和七牛，可以多源站备份。假如说七牛或者是新浪出现问题，我们可以在上传这一步，业务服务可以让他选择从哪个节点上传，出现了问题之后我们可以直接切换过去。前段时间新浪 S3出现问题，新浪内网中断，直接就不能用了，直接就进行切换，不影响业务服务。播放高可用。调度这块除了对播放情况收集外，还做了可用性检测。如果这个节点频繁出问题的话，我们可以不给他调度返回相应的 CDN 的地址。然后 CDN 这边如果优先选了一个源，如果一个源不存在的话，或者出问题的话，它会切换到另外一个源进行播放。
其它核心组件
除此之外还有视频不相关的一些核心服务，比如说 Push。IOS 有自建 APNS 通信通道和新浪内部基础服务。安卓主要是它需要和服务方、设备方维持连接，成本关系采用的是新浪基础服务＋第三方合作服务，基本可以保证Push保证秒级可达，成本可控。
搜索引擎。搜索我们是基于 ELASTICSEARCH 的分布式搜索引擎，相对于其它搜索引擎来说，处理索引要实时，实时搜索、稳定、可靠、快速扩容、性能保障、提供搜索。搜索服务也是一个独立的服务提供给业务方。
敏感词过滤。我们是基于分词加布隆过滤器的敏感词过滤服务。
海量日志分析和监控
日志的构成主要有：serveraccess log、error log、service log、app log、用户 log 等。
相信大家都有这些痛点：日志量太大，业务出现问题时不能知道各服务的状态，不能快速定位问题，查不出来，问题相关的人都会收到通知一块去查看，查到之后却已经拖了很长时间了；grep／awk 只可以单机运行,大日志搜索难以满足；日志形态不可视。
对此，秒拍当前做了基于ELK实时日志分析系统，业务日志来了之后就可以对它进行分析，可以图表化快速反馈各项服务状态和一些统计信息，出问题了可以很快的感知，同时还有基于ELK的服务监控。
