\u0026#xD;
一、可用性如何定义
\u0026#xD;
- 可用性(availability)是关于系统可供使用时间的表述&＃xff0c;以不可用的时间为衡量指标。不可用时间越短&＃xff0c;可用性越高。通常用n个9来描述。比如4个9的可用性&＃xff0c;则是指一年中不可用时间在52分钟内&＃xff0c;平均每周不可用时间在1分钟。\u0026#xD;
- 可靠性(reliablity)是关于系统无故障时间间隔的描述&＃xff0c;以发生故障的次数为衡量指标&＃xff0c;故障次数越少&＃xff0c;可靠性越高\u0026#xD;
- 可维护性(maintainability)系统发生故障后&＃xff0c;恢复的时间来描述。时间越短&＃xff0c;可维护性越高。\u0026#xD;
从上面三者关系看出&＃xff0c;服务的可靠性、可维护性越高&＃xff0c;可用性就越高。这就要求我们在服务开发和管理中做到&＃xff1a;提高服务系统的稳定性、改善软件的可管理性和可维护性。
\u0026#xD;
对于SAE云计算平台而言&＃xff0c;可用性包含三个方面&＃xff1a;SAE自身服务可用性、网络可用性、SAE平台上数据可用性。
\u0026#xD;
二、如何打造高可用的平台
\u0026#xD;
1、软件设计和系统架构
\u0026#xD;
软件是互联网服务的载体。良好的软件对于服务的可用性至关重要。从可用性定义来看&＃xff0c;我们在软件设计时&＃xff0c;既要考虑可靠性&＃xff0c;又要考虑可维护性。
\u0026#xD;
可靠性&＃xff1a;这主要体现在软件本身的稳定性和容错性上。软件的稳定性很大程度上取决于代码质量&＃xff0c;设计再优良的系统都有可能在实现上质量控制不好而导致失败。软件的容错则主要体现在两个方面&＃xff1a;避免单点的高可用设计和自治独立原则。软件系统要做到足够健壮,在发生一些硬件或网络故障时就需要能够做到冗余&＃xff0c;继续提供服务。即发生故障的次数足够低
\u0026#xD;
比如某个服务&＃xff0c;可能有3个系统单元。每个单元都不应该存在单点&＃xff0c;某个服务器宕机不应当导致服务不可用。由于IDC故障的频繁&＃xff0c;现在越来越多的设计在考虑当某个IDC不可用时&＃xff0c;服务要能够继续提高服务&＃xff0c;即跨IDC机房的高可用。另外软件设计时要求足够自治独立&＃xff0c;不可过多依赖网络和其他服务单元&＃xff0c;对于互联网服务&＃xff0c;阻塞是最大的敌人&＃xff0c;在一个系统中由于一个微不足道的连接阻塞&＃xff0c;而导致整个系统服务不可用&＃xff0c;这样的例子实在是太多&＃xff0c;所以对于互联网服务&＃xff0c;需要牢记&＃xff1a;服务要足够自治独立&＃xff0c;避免阻塞。
\u0026#xD;
下图简单说明了SAE平台的负载均衡服务是如何避免单点故障的。
\u0026#xD;
\u0026#xD;
可维护性&＃xff1a;软件要易于管理维护&＃xff0c;能够和现有的运维系统整合&＃xff0c;比如说配置管理、日志管理等&＃xff0c;避免自立规范。软件的管理维护简单&＃xff0c;对于发生故障时缩短恢复时长是有重要帮助的。
\u0026#xD;
2、服务实施时引入破坏测试
\u0026#xD;
好的软件设计开发完成后&＃xff0c;在部署环节&＃xff0c;一定要实际测试在设计时定下来的目标&＃xff0c;比如说避免单点&＃xff0c;就需要部署时&＃xff0c;实际去破坏。对其他各种容错的处理是否真的到位。我们常见的做法是关机测试、重启检验服务自恢复能力、拔网线等测试&＃xff0c;同时观察软件系统是否运行正常。这主要仍然是围绕服务可靠性进行测试。
\u0026#xD;
3、实时的、立体的、可视化监控
\u0026#xD;
一个服务&＃xff0c;除了自身软件外&＃xff0c;还包含了监控&＃xff0c;监控应当视为服务的一部分。服务上线一定是包含了监控。监控是最好的质量保证措施。SAE平台在Alpha版上线时就有了各种监控&＃xff0c;监控是平台不可分离的一部分。对于监控&＃xff0c;我们积累了一些经验.
\u0026#xD;
实时&＃xff1a;要能够及时发现问题、抢在用户的前面发现问题
\u0026#xD;
立体&＃xff1a;这要求我们的监控是多层次的立体式的&＃xff0c;立体监控最大的好处是快速定位故障原因&＃xff0c;有助于快速解决问题。毕竟同样的现象&＃xff0c;背后可能有很多种可能。我们的监控包含&＃xff1a;系统监控(负载,磁盘IO等)、网络TCP三次握手监控(只要节点之间发生网络关系的都需要监控)、服务自身可用性监控、错误日志趋势监控(当服务的错误数量突然增加时可以捕捉到)
\u0026#xD;
可视化&＃xff1a;这是从监控工具的易用性而言。可视化更加有利于发现和分析问题。
\u0026#xD;
自我恢复&＃xff1a;这主要体现在服务监控里。服务的监控包含两个部分&＃xff0c;首先是根据服务所承诺的各项功能的黑盒测试&＃xff0c;这主要是模拟用户发起。其次是服务所在的节点上有部署自我检查自我修复的程序&＃xff0c;当自我诊断认为有故障时&＃xff0c;程序会尝试多种恢复方法。这极大降低了故障服务时长&＃xff0c;有效提高了服务可用的时间。SAE平台底层有这样一套系统在不间断地运行。
\u0026#xD;
报警&＃xff1a;监控是为了更快发现问题&＃xff0c;能够自动处理的让机器自动完成&＃xff0c;不能自动完成的就需要人工处理&＃xff0c;这就需要有报警机制。SAE内部开发了一个叫“报警网关”的系统&＃xff0c;所有的监控都是直接对接该报警网关。网关的优点是可以做分析、排重&＃xff0c;并且是有上下文的报警。我们报警的原则&＃xff1a;过犹不及。当运维人员收到过多报警&＃xff0c;并且包含了大量的误报时&＃xff0c;这样的报警时没有价值的&＃xff0c;要坚决抵制。
\u0026#xD;
故障响应&＃xff1a;相关人员接到报警后&＃xff0c;根据故障级别进行响应。
\u0026#xD;
严重故障&＃xff0c;影响到平台的稳定运行&＃xff0c;白天要求5分钟内响应&＃xff0c;夜间15分钟响应。
\u0026#xD;
次级故障&＃xff0c;不影响应用的运行&＃xff0c;但可能影响到用户的管理和使用白天要求15分钟响应&＃xff0c;夜间要求2小时响应
\u0026#xD;
警告级别故障&＃xff0c;这种报警不影响服务&＃xff0c;不影响使用&＃xff0c;但需要提示有隐患。白天要求1小时&＃xff0c;夜间不要求响应&＃xff0c;但要求早晨立刻处理&＃xff0c;避免故障升级。
\u0026#xD;
快速的故障发现、自我修复和故障响应&＃xff0c;是在故障一旦发生后&＃xff0c;缩短服务恢复时长&＃xff0c;提高服务的可维护性角度而言的&＃xff0c;从而间接提高了服务的可用性。对于互联网服务而言&＃xff0c;强大的运维团队是服务可用性的重要保障之一&＃xff01;
\u0026#xD;
下图是SAE平台访问量和访问用户的实时监测图表。
\u0026#xD;
\u0026#xD;
4、针对频繁的系统变更、软件迭代升级
\u0026#xD;
我们知道服务如果没有变更&＃xff0c;出问题的概率一般就很低。但是互联网服务变更恰恰是很频繁的&＃xff0c;这恰好体现了她的生命力。所以如何在不断变更升级的条件下保证平台的稳定可用显得更为迫切。SAE每周的各种变更升级在十次以上。SAE为更好地保证平台稳定性&＃xff0c;我们引入了旁路系统和灰度发布机制。
\u0026#xD;
旁路系统&＃xff1a;用户的请求进入负载均衡后&＃xff0c;除了会走正常流程外&＃xff0c;同时会引导到另外一个环境&＃xff0c;该环境和生产环境非常相近&＃xff0c;除了规模外。我们引入旁路系统的原因在于配置变更、软件升级等很频繁&＃xff0c;在生产环节每一个变更不管多么简单都是有风险的。其次是系统级别的软件更新升级等&＃xff0c;为了尽可能多尽可能早地发现一些隐藏的很深的bug&＃xff0c;旁路系统是一个不错的方案。因为旁路系统足够真实。并且还可以在旁路环境进行一些压力测试&＃xff0c;毕竟线上做压力测试危险太大&＃xff0c;线下做测试&＃xff0c;测试数据不够真实。在旁路系统变更完成后&＃xff0c;如何判断变更是安全的&＃xff0c;是一件相对比较有挑战的事情。我们的经验往往是观察变更涉及的服务&＃xff0c;错误日志比例是不是有明显上升。如果变更后服务无法使用或者挂了&＃xff0c;问题就更加明显。
\u0026#xD;
灰度发布&＃xff1a;旁路系统虽然足够真实&＃xff0c;但毕竟不是完全真实的生产环境&＃xff0c;变更有没有对应用造成影响&＃xff0c;有时需要用户反馈来配合。尽管旁路系统可以发现99%的问题&＃xff0c;但不可否认仍然有可能有隐藏的很深的我们无法发现。这就需要引入灰度发布。所谓灰度发布&＃xff0c;就是在升级时&＃xff0c;只引导部分应用来使用&＃xff0c;通过逐步增加使用的应用数量同时观察用户的反馈&＃xff0c;来验证变更是否存在问题。但是对于有状态的服务&＃xff0c;灰度发布实施比较困难。
\u0026#xD;
旁路系统和灰度发布都是从提高平台服务可靠性角度出发&＃xff0c;对变更做好风险控制&＃xff0c;尽量降低故障发生的次数。
\u0026#xD;
5、数据可用性
\u0026#xD;
数据可用性主要体现在数据冗余上。SAE平台数据类的服务包括MySQL、KVDB和Storage&＃xff0c;服务都提供有热备和冷备&＃xff0c;并可以从冷备中恢复14天内的数据。数据自助恢复功能目前正在开发中&＃xff0c;目前可以提供收费的人工数据恢复服务。
\u0026#xD;
6、多线路接入保证网络访问质量
\u0026#xD;
由于南北电信互联互通问题&＃xff0c;用户一旦跨网访问&＃xff0c;往往不可到达或由于电信运营商网络故障或IDC级别的故障&＃xff0c;用户到IDC之间的网络不可到达&＃xff0c;或丢包率很高。
\u0026#xD;
网络可用性更多的会依赖电信运营商的服务能力。但对于互联网服务而言&＃xff0c;必须要解决这样的困难才可以真正提供好的服务。
\u0026#xD;
目前SAE网络接入支持电信、联通、教育、移动等&＃xff0c;真正实现了国内大的运营商网络的覆盖&＃xff0c;这在国内是很罕见的。用户不须操心网络接入的复杂问题&＃xff0c;并且在某些链路访问质量出现问题时&＃xff0c;SAE平台通过云监控能够及时发现&＃xff0c;并会做出调整。最大限度保证全国范围内的用户的网络可到达。
\u0026#xD;
下图展示了SAE是如何保证多路访问质量的。
\u0026#xD;
\u0026#xD;
三、对于云计算的用户的建议
\u0026#xD;
尽管国外云计算的使用已经非常普及&＃xff0c;但不可否认&＃xff0c;国内的云计算市场尚处于起步阶段。这固然和国内企业和开发者的认知和接受度有关&＃xff0c;但也和国内云计算发展不够务实&＃xff0c;不贴近用户需求脱离不了干系。
\u0026#xD;
客户在选择是否使用云计算时&＃xff0c;往往有很多担忧&＃xff0c;总觉得没有放在自己的手里放心。但我们从实践中也发现&＃xff0c;大部分企业的网站&＃xff0c;其可用性可到达率都不算高&＃xff0c;虽然没有专业机构提供的中国网站可用性这样的报告。如果完全自己去实现自己的系统&＃xff0c;上面遇到的大部分可用性挑战&＃xff0c;相信都会遇到&＃xff0c;而且未必能做得更好。所以如果云计算足够成熟&＃xff0c;建议采用云计算&＃xff0c;让您的企业更“轻”点&＃xff0c;服务更可靠点。
\u0026#xD;
SAE平台目前的可用性已经可以达到99.95%&＃xff0c;我们正在朝99.99%的目标努力&＃xff0c;SAE对于更高可用性的追求是没有止境的。
\u0026#xD;
云计算平台的可用性&＃xff0c;相比传统互联网服务而言&＃xff0c;更加复杂和困难&＃xff0c;也更具有挑战性。以后有机会再谈谈云计算可用性设计有哪些特别的地方。
\u0026#xD;
感谢金明对本文的审校。
\u0026#xD;
给InfoQ中文站投稿或者参与内容翻译工作&＃xff0c;请邮件至editors&＃64;cn.infoq.com。也欢迎大家通过新浪微博&＃xff08;&＃64;InfoQ&＃xff09;或者腾讯微博&＃xff08;&＃64;InfoQ&＃xff09;关注我们&＃xff0c;并与我们的编辑和其他读者朋友交流。
京公网安备 11010802041100号