这是一个创建于 3090 天前的主题，其中的信息可能已经有所发展或是发生改变。
网易视频云是网易倾力打造的一款基于云计算的分布式多媒体处理集群和专业音视频技术，为客户提供稳定流畅、低时延、高并发的视频直播、录制、存储、转码及点播等音视频的 PASS 服务。在线教育、远程医疗、娱乐秀场、在线金融等各行业及企业用户只需经过简单的开发即可打造在线音视频平台。现在，网易视频云与大家分享一下如何打造高可用系统。
引言： 系统稳定性就像阳光、空气、水一样， 只有失去了才知道珍贵。 谨以此文写给稳定系统后面默默支撑的朋友， 以及不稳定系统背后勇于担当、拼命挣扎的朋友们。 本文节选自《网易后台技术中心分布式白皮书》 可用率是衡量系统稳定性的指标， 任意时刻系统工作正常的概率称为可用率， 而所谓“工作正常”是指系统能达到它许诺的服务质量 SLA （ Service Level Agreemenet ）。 各类系统 SLA 差别较大， 典型的 SLA 有： 1 ） memcache 等 key-value 服务 SLA 通常是 99.9%的读写请求在 5s 内返回。 2 ） hadoop 系统的 SLA 是确保计算任务在每天早上 7:00 前完成， 按时完成率 98%, 即全年发生延误次数不超过 7 次；
如上表所示， 业界通常使用几个 9 来衡量可用率， 以 amazon s3 为例， 其承诺可用率为 4 个 9 ，即 99.99%， 那么一年中最多 52 分钟不可用。 做到 4 个 9 难度很大， 相当有技术含量， 按照我们的经验， 从发生故障到运维响应和修复故障， 整个过程控制在半个小时内就算不错了（包括周末和半夜哦）， 所以 4 个 9 意味着一年最多出两次故障。 aws 大牛 james hamilton 说过单机房的可用率最高 4 个 9 ， 如果一个系统号称是 4 个 9 ，但是没做跨机房高可用方案， 那就是耍流氓， 是在碰运气。 要想打造一个真正高可用（稳定）的系统， 必须确定可用率目标。 根据业务特点重要程度定义 SLA 指标， 过高过低都不行， 一般来说， 核心业务的 SLA 较高， 非核心业务或者离线计算业务 SLA 要求较低。 按照一定时间周期统计可用率， 使用可用率衡量 SLA 达成情况， 将可用率作为团队的重要考核指标。 理想情况下， 系统应该自动统计可用率，然而实际业务却很复杂， 因此大多采用事故评审机制评审事务造成的不可用时间， 人工统计维护可用率。 举个例子， 一个系统可能有多个重要程度不等的功能点， 针对多租户又有不同的 SLA 要求， 不同事故可能影响不同功能点， 影响不同租户， 很难自动计算出一个可用率。 既然很多时候是人工统计可用率， 必然存在作弊可能性。关于可用率最常见的误区是“隐瞒事故”， 这种行为虽然提高了账面可用率， 殊不知小错误易藏， 大问题难躲， 如此不重视可用率，把风险隐藏起来， 草草了事，对长期可用率有很大伤害。 可用率 = MTBF / (MTBF + MTTR) ， 其中 MTBF ， Mean Time Between Failure ， 是平均无故障时间， 而 MTTR ， Mean Time To Repair ，是平均修复时间。 从上述计算公式可以看出， 可用率与 MTBF 成正比， 与 MTTR 反比, 因此提高可用率的办法也可以分为故障避免和故障快速修复两类。 一、故障避免措施 运行好好的系统不会无缘无故的出问题， 一定是发生了某些变化，引发变化最可能因素是： 1 ） 线上变更， 包括上线、扩容等等，只要碰到线上系统的都算。 2 ） 软硬件故障， 包括进程异常退出， 操作系统死机， 磁盘故障，网络故障，服务器故障等。 3 ） 负载变化， 最常见的是负载上升。 故障避免措施也相应的分为三类
- 变更管理措施。 （ 1 ）不管是代码发布上线，还是配置修改； 不管是扩容，还是缩容； 不管是变更 1 台机器，还是百台机器， 只要碰着线上都算是线上变更。 （ 2 ） 所有变更都应该经过测试和演练。 以我们自己的云计算项目为例， 我们会准备功能测试环境，性能测试环境， 联调环境，演练环境， B 级线上环境（不太重要）， A 级线上环境等。 一个线上变更， 应该经过各种环境测试验证，确保变更不会影响系统本身以及关联系统。 测试验证之后， 一般是灰度发布上线， 而且通常先发布到不重要 B 级环境，稳定一段时间之后再发布到 A 级环境。 （ 3 ） 此外， 线上变更应该是可验证和可回滚的。 一方面， 一定要有一些手段要验证上线结果， 持续观察一段时间确认上线成功。 另外一方面， 线上变更不可能 100%成功， 务必准备一个回滚方案, 遇到升级不成功时第一时间回滚，而不是在线上定位和修复问题。
- 软硬件故障。由于在大型分布式系统中， 磁盘、服务器等软硬件故障是常态， 容错应该作为一个系统特性， 在设计之初就充分考虑。 （ 1 ） 简化问题。 降低系统出错概率的首要原则是尽可能简化设计，简化架构， 简化算法， O(N2)复杂度但简单可靠的算法不见得不能用。 尽量避免过早优化，或者只能小幅度提升性能的优化。 （ 2 ）提高组件可用性，譬如使用可靠的硬件， 使用成熟的开源软件， 使用成熟的云计算服务。 （ 3 ）通过冗余提高容错能力。 冗余可细分为信息冗余， 计算冗余和时间冗余三种。 信息冗余技术包括，多副本、纠删码等， 可应对数据丢失故障。 计算冗余是指使用多份物理设备，或者服务进程， 单个故障不影响整体可用性， 避免出现单点故障。 时间冗余涵盖重试、重传等技术， 能处理瞬时故障， 保证服务成功。 容错技术的副作用是掩盖系统自身 BUG ， 加大了系统测试和调试的难度， 因此任何容错行为都应该有日志记录。 3 ）过载处理 。 一个没有过载保护措施的系统，遇到过载时所有请求都会超时， 服务能力下降为零！ 过载保护措施必不可少。 （ 1 ） 做好容量规划， 增强弹性扩容能力， 避免过载。 （ 2 ） 过载保护。 系统应当可以识别有效请求和无效请求（请求排队太久， 发起请求的客户端已经超时， 所以请求无效）， 过载时只处理有效请求， 不处理无效请求， 不做无用功， 尽其所能提供服务 。 （ 3 ） 过载隔离。 故障隔离的目标是减小故障影响面， 避免系统雪崩， 常用技术是超时、防水隔板、泳道模式、保险丝模式.[1] 二、故障修复措施 故障避免措施说了一大堆， 但是故障终究难以避免， 当出现故障时， 关键是降低故障恢复时间:
- 可运维的系统。 充分而及时的报警， 详细的系统日志和系统运行状态， 好用的问题诊断工具， 性能分析工具， 运维工具， 这些都是可运维系统的特征。
- 训练有素的运维团队， 没有高素质的运维，以及成熟的管理机制， 很难保障系统稳定。 小结 如何打造一个高可用系统？ 说起来容易做起来难， 一切尽在细节中， 在于严瑾和坚持， 在于事故中磨练出来的团队。
 |
1
gcodexman 2016-06-17 10:42:23 +08:00 via Android
滚 和乐视比差远了 人家乐视免费 就在前面贴点广告而已
|
 |
4
qw0258 2016-06-17 11:49:50 +08:00
@gcodexman 优酷也可以去广告，免台标（这部分收费）。 自定义播放器的意义在于哪？与网站 VI 更贴合，还是能放自己的 logo?
|
 |
6
thomaspaine 2016-06-17 12:54:38 +08:00
@cai72738 感觉他本来就不想辩论，发泄情绪而已
|
|
7
qw0258 2016-06-17 13:00:12 +08:00
@thomaspaine http://www.v2ex.com/t/285685#reply16 看看 3 楼，似乎突然明白了什么
|
 |
8
weihongchang 2016-06-17 13:03:29 +08:00
这帖子的排版，密集恐惧症， 不能弄好看 顺眼一点吗
|
 |
9
shipinyun2016 OP @weihongchang 下次一定好好排版~
|
 |
12
qiukun 2016-06-17 19:00:10 +08:00 via Android
👍 metrics first 。
|
Select Language