转载

北航视频总结

到7月底，北航视频项目基本告一段落，在此项目上花的时间也有近四个月了。在此将技术相关的内容加以总结，以明得失。

项目部署篇

北航视频后台使用Mediadrop进行二次开发，前台使用Django框架开发，中间使用nginx代理。在部署上分别分为前后台部署和nginx部署三部分。

前后台的部署更多的是安装一些依赖：npm，bower和python的一些模块等。个人认为学到的最基础的两个内容一个是在centos上安装新的python以及virtualenv，另一个内容则是nginx的使用（虽然只是简单的使用）。

在centos上安装python和virtualenv

在这一块主要是参考了一篇非常简明的博客： How to install python2.7 and python3.3 on centos

主要内容包括以下几个部分

预先安装依赖
需要注意的事项
- 字符集
- 共享库（share library）
- 使用make altinstall而不是make install
下载，编译，安装
下载，安装setuptools + pip
安装virtualenv，创建沙箱环境（貌似3.0以上版本自带了pyvenv）

nginx配置

在此前我在校内接触的一些项目中，使用的都是apache，而nginx还从为接触过，只是简单了解一下便能感觉到其强大之处。在nginx的学习上，主要参考了春哥的nginx文章。对nginx的工作机制，以及配置文件语法等有了简单的了解。

北航视频实际工作篇

前台&后台

在北航视频前台部分所做的工作，主要是前端的一些技术，比如使用bootstrap来写了一个观看历史记录下拉框，使用javascript写了提醒用户安装flash的功能。基本上对前端代码有了一个初步的认识与了解。后台方面主要是写了一个控制面板功能，主要是在数据库中取出内容显示到管理界面上。

北航视频前台使用的python框架是Django，后台使用的是pylons。二者都是基于MVC的框架，虽然有很多不同，但是通过前台与后台不同框架间的相互印证，对“框架”这一概念的理解还是加深了许多。

添加浙江卫视直播频道

2015年7月21日，添加浙江卫视直播结束，配置整个推流服务器的过程如下。

选择后台服务器2作为新的推流服务器（不知为什么1的数据盘开始没挂载上，导致图片等静态文件加载不上，导致所有的图片都显示灰色感叹号，后来重新挂载了一下才解决。)

ffmpeg以及nginx，redis配置：

下载ffmpeg，直接yum的似乎版本太旧
配置ipv6
安装需要的nginx模块，包括两方面内容，一是fmtp相关的模块，用来推流时使用。另一方面主要是以lua为中介，使nginx与redis进行交互，主要是与lua与和redis相关的模块，在现有服务器上，可以通过/usr/local/nginx/sbin/nginx -V 进行查询编译安装nginx时所带的参数，还可以使用 ldd /usr/local/nginx/sbin/nginx 查看一些模块的位置。
配置nginx，与cctv5的推流服务器nginx配置基本保持一致。（注意推流时是的rtmp地址是rmtp://ip/app/name，name这个字段的内容可以自己定义，但必须要带，不然会导致流无法播放，观察log时会发现提示是name为‘’，即空值）
修改前端和后台代码，原来的代码选择直接从redis中读取流服务器ip地址，而不是从数据库中直接读取。暂时不清楚其意图，但是添加新频道时很麻烦，于是修改了代码，直接根据id去数据库中取真实的推流ip，绕过了redis环节，完成这些之后，推流成功。
这个时候，发现播放时显示人数的功能失效了，经过查看代码，发现原来是使用各个推流服务器上的redis记录当前观看的人数，在nginx的fmtp应用中通过调用incr和decr函数来进行实时统计观看人数。然而使用curl“ http://host/function”来观察nginx的运行状态，发现nginx中装的一些模块缺失，而且用find命令也找不到这些模块。所幸在10.254.16.5这台服务器发现了/root/nginx文件夹，里面有所有需要的内容，省去了许多麻烦。
在完成推流服务器端的nginx和redis配置之后，发现后台部分和前台部分都几乎是写死的代码，目测是原来根本没考虑会加第二个直播，很多地方都不具备扩展性，所以此次添加直播，相关的地方也是work around的形式解决的，如果再添加直播频道，也需要添加一些相应的代码才可以。

搜索&调试篇

搜索

刚开始接触北航视频的时候，对linux和vim的搜索功能不熟悉，搜索意识也较差，总是出现这个方法找不到，那个语句找不到的情况。而且python这种动态语言不像c那样有ctags这样的神器可以各种查找跳转。多数内容需要手动去搜索，掌握一手搜索技能对于复杂项目往往起到事半功倍的效果。现在过了一段时间之后，在linux下常用的搜索命令是搜索内容的ack以及搜索文件名或文件夹名的find，以及vim下的简单搜索方法等。仅仅是掌握这些，就感觉以前那种经常找不到东西在哪里的情况大大减少了。当然搜索的内容还是很有讲究的，方法名，一些区别与其他文件内容的，定位性较强的内容都可以充当搜索的关键词。

调试

调试技巧的学习是这段时间内非常重点的部分，因为一直在调bug。记得最初的时候遇到keyerror的错误，不知道该怎么往下进行，于是去请教栢霖，栢霖直接在url中传入各种数据来调试，惊为天人。调试最需要注意的一点就是线索的连续性，辰哥说调试就像破案，最重要的就是线索，不断的找错误信息。我刚开始调试时，总是上来就瞅代码，看代码是不是有错。这其实是效率最低的一种方法，因为一个系统的错误，总是一个错误引起另一个错误，最初的那个错误是源头，而后来的错误并不是真正的错误，只是源头错误的副产物而已。

一个典型的调试案例是恢复北航视频搜索功能调试过程。

具体表现是：搜索视频时，总是为空结果，而搜索组织时则直接出现500error错误，错误信息极少。

错误信息少是非常棘手的局面，这个时候要想尽一切办法去获取错误信息，包括查log，url传参数等各种手段。于是首先tail -f *.log
观察log信息，发现了错误发生时的调用栈，定位是departments keyerror，根据调用栈里的代码去查看具体函数，以及http request的具体参数。
自己手动编写url（/api/departments?search=’somevalue’&limit=1&offset=1）观察返回信息。发现错误1429, 'Unable to connect to foreign data source: failed to connect to searchd。
网上搜索这个错误，事后来看，最有用的结果是 http://sphinxsearch.com/forum/view.html?id=2593 说是searchd服务没起来
于是在前台和后台查找searchd这个命令是否存在，找不到，直接用ack暴力搜，发现跟mysql有关系。去mysql服务器上寻找这个命令，果然存在，于是把两台机器的都启动后，恢复正常。

原因分析：在mysql服务器上用了searchd服务，应该还是上次断电时，该服务没有启动，导致搜索服务无法使用，搜索视频返回为空而组织返回500error，是因为相关函数给给了media的默认参数，而组织的没给，造成二者表现不同。

在经历过这次调试后，后来再次遇到直播人数显示问题时的调试时，基本流程是一样的，调试效率高了很多。

上面的调试过程使用的是python自带的出错机制以及调试机制。有时候并不是出了错误的bug才去调试，因为某些逻辑上的问题造成系统能正常运行，但是结果不符合预期或者是想了解程序的某个流程到底是如何走的。这个时候上面的调试就不好使了。这个时候使用ide来设置断点来调试是非常强大的方法。

个人用到的两个调试工具一是前端调试时使用chrome。二是在写北航统一认证登陆时的时候，使用了pycharm进行后台的调试，一步步追踪代码，最终发现了完整的认证流程。

git篇&运维篇

公司使用github作为版本管理和团队协作工具，git的好处自不必说，使用好git对多人合作项目非常有帮助。在此期间学到了git的基本应用，原来一个觉得麻烦的地方时合并分支时的冲突问题，后来学了解决冲突的方法之后真是帮助巨大。最重要的还是看文档啊！！！

北航视频是个长期的大型项目，期间出现各种问题都不奇怪，因此运维也是其中一个很重要的部分。

印象最深的就是北航视频用了多台服务器，但是这些服务器的作用，上面使用的各种应用都比较乱，也没有一个完整的文档来说明每台服务器的详情，这说明前期可能是对运维缺少重视。

这样做的后果，在一次服务器断电时间中完全体现出来了。五一的时候北航机房出现了一次机房断电故障，北航视频所有服务器都断电，电力恢复之后，发现系统完全不能正常运行。估计之前的服务都没有配置开机启动，各个服务器的服务没起来，远程数据盘挂载不上，关键是不知道各个服务器上都用了哪些服务，于是各种蛋疼，5.1断电，直到7月底，才把遗漏的搜索应用searchd服务启动了。这之中的痛苦可想而知。

运维上主要的教训是需要有条理，要谨慎。每台服务器配置，应用详情等都要有完整的文档，操作时一定要小心，比如又一次我删除一个软连接时，因为后面多加了一个/导致把整个软连接源文件而不是软连接本身给删了。

正文到此结束