编者按：高可用架构分享及传播在架构领域具有典型意义的文章，本文由前 Google SRE 孙宇聪分享。转载请注明来自高可用架构公众号 ArchNotes。
我先做一下自我介绍，我是 07 年加入的 Google，在总部任 SRE，今年年初回到 Coding (http://coding.net) 任 CTO。SRE 的全称是 Site Reliability Engineering ，基本相当于国内的运维，但是更偏开发。 在 Google 我参与了两个比较大的 Project。 第一个是 YouTube，其中包括 Video transcoding，streaming 等。Google 的量很大，每个月会有 1PB 级别的存储量。存储、转码后，我们还做 Global CDN。到 2012 年的时候，峰值流量达到 10 TBps，全球 10 万个节点，几乎每台机器都是 16/24 核跑满， 10G uplink 也是跑满的状态。 然后我加入了 Google Cloud Platform Team， 也就是 Borg 团队。这个团队的主要工作是就是管理 Google 全球所有的服务器，全球大概有 100 万台左右。另外就是维护 Borg 系统，同时我也是 Omega 系统运维的主要负责人，很可惜这个项目最后由于各种各样的原因在内部取消了。 下面我想跟大家分享的是关于可用性、可靠性上面的一些理念和思考。 一、决定可用性的两大因素谈可用性不需要绕来绕去，大家只谈 SLA 即可。大家可以看下面这个图: 要谈可用性，首先必须承认所有东西都有不可用的时候，只是不可用程度而已。一般来说，我们的观念里一个服务至少要做到 99.9% 才称为基本上可用，是合格性产品。否则基本很难被别人使用。 从 3 个 9 迈向 4 个 9，从 8 小时一下缩短到 52.6 分钟的不可用时间，是一个很大的进步。Google 内部只有 4 个 9 以上的服务才会配备 SRE，SRE 是必须在接到报警 5 分钟之内上线处理问题的，否则报警系统自动升级到下一个 SRE。如果还没有，直接给老板发报警。 大家之前可能听说谷歌搜索服务可用度大概是全球 5 个 9，6 个 9 之间。其实这是一个多层，多级，全球化的概念，具体到每个节点其实没那么高。比如说当年北京王府井楼上的搜索集群节点就是按 3 个 9 设计的。 有关 SLA 还有一个秘密，就是一般大家都在谈年 SLA，但是年 SLA 除了客户赔款以外，一般没有任何实际工程指导意义。 Google 内部更看重的是季度 SLA，甚至月 SLA，甚至周 SLA。这所带来的挑战就更大了。 为什么说看这个图有用，因为 99%、99.9% 是基本可以靠运气搞定的哦。到 3 个 9 可以靠堆人，也就是 3 班倒之类的强制值班基本搞定。但是从 3 个 9 往上，就基本超出了人力的范畴，考验的是业务的自愈能力，架构的容灾、容错设计，灾备系统的完善等等。 说了这么多，作为一个架构者，我们如何来系统的分解“提升 SLA”这一个难题呢。 这里我引入两个工业级别的概念 MTBF 和 MTTR。 MTBF: Mean time between Failures。 用通俗的话讲，就是一个东西有多不可靠，多长时间坏一次。 MTTR: Mean time to recover。意思就是一旦坏了，恢复服务的时间需要多长。 有了这两个概念， 我们就可以提出： 一个服务的可用度，取决于 MTBF 和 MTTR 这两个因子。从这个公式出发，结合实际情况，就很好理清高可用架构的基本路数了。那就是： 要么提高 MTBF, 要么降低 MTTR。除此之外别无他法。 要注意的是，考虑 MTBF 和 MTTR 的时候都不能脱离现实。 理论上来说，作为一个正常人类，收到突发报警、能正确的分析出问题所在、找到正确的解决方案、并且 【正确实施】的时间极限大概是 【两分钟】。这个标准我个人觉得是高到天上去了。作为一个苦练多年的 Oncall 工程师，我 2 分钟能看清报警，上了 VPN，找到 dashboard，就不错了。就算是已知问题，有应对方案，能敲对命令，完全成功，也至少需要 15 - 20 分钟。所以如果按照这个标准的话，管理的服务如果想达到 4 个 9，那么一年只能坏 1 次，2 次就超标了。实现高可用基本靠运气～ 回过来接着说说 MTBF 吧。请各位想一下，影响服务MTBF的三大因素！
这个术语上叫 Age Mortality Risk。 一般一个服务只要你不去碰他一年都不会坏一次。更新越频繁，坏的可能性就越大。凡是 Software 都有 BUG，修 BUG 的更新也会引入新的 BUG。发布新版本，新功能是 MTBF 最大的敌人。 二、高可用性方案说了 MTBF 和 MTTR 这两个定义，那么具体究竟应该如何落地实践来提高可用性呢？ 首先说几个大家可能都听腻了的方案 一、提高冗余度，多实例运行，用资源换可用性。 虽然道理很简单，实现起来可不简单，有很多很多细节上的东西需要考虑。 第一个细节：N 2 应该是标配。 N 2 就是说平时如果一个服务需要 1 个实例正常提供服务，那么我们就在生产环境上应该部署 1 2 = 3 个节点。大家可能觉得 N 1 很合理，也就是有个热备份系统，比较能够接受。但是你要想到：服务 N 1 部署只能提供热备容灾，发布的时候就失去保护了。 因为刚才说了， 发布不成功的几率很高！ 从另一个角度来讲，服务 N 2 说的是在丢失两个最大的实例的同时，依然可以维持业务的正常运转。 这其实就是最近常说的两地三中心的概念有点像。 第二个细节： 实例之间必须对等、独立。 千万不要搞一大一小，或者相互依赖。否则你的 N 2 就不是真的 N 2。如果两地三中心的一个中心是需要 24 小时才能迁移过去的，那他就不是一个高可用性部署，还是叫异地灾备系统吧。 第三个细节：流量控制能力非常重要。 想做到高可用，必须拥有一套非常可靠的流量控制系统。这套系统按常见的维度，比如说源 IP，目标 IP 来调度是不够的，最好能按业务维度来调度流量。比如说按 API， 甚至按用户类型，用户来源等等来调度。 为什么？因为一个高可用系统必须要支持一下几种场景：
但是想要达到高可用，这些都是必备的，也是一定会遇到的场景。还是那句话，靠人是没戏的。 二、变更管理（Change Management） 还记得影响 MTBF 最大的因子吗？发布质量不提高，一切都是空谈。 第一点： 线下测试（Offline Test） 线下测试永远比线上调试容易一百倍，也安全一百倍。 这个道理很简单，就看执行。如果各位的团队还没有完整的线下测试环境，那么我的意见是不要再接新业务了，花点时间先把这个搞定。这其中包括代码测试、数据兼容性测试、压力测试等等。 台上一分钟，台下十年功。 可用性的阶段性提高，不是靠运维团队，而是靠产品团队。能在线下完成的测试，绝不拍脑门到线上去实验。 第二点：灰度发布 这个道理说起来好像也很普通，但是具体实施起来是很有讲究的。 首先灰度发布是速度与安全性作为妥协。他是发布众多保险的最后一道，而不是唯一的一道。如果只是为了灰度而灰度，故意人为的拖慢进度，反而造成线上多版本长期间共存，有可能会引入新的问题。 做灰度发布，如果是匀速的，说明没有理解灰度发布的意义。一般来说阶段选择上从 1% - |
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
注册
登录
