大规模服务器设计与开发实践经验

1.简介

本文就设计与开发大规模服务器的话题进行总结，得出出一系列实践经验。 设计和开发大规模服务器是一个高速发展的领域，本文的目的是： （1）快速交付运维友好的服务； （2）避免凌晨收到报警短信的骚扰（深受其害啊）；

进入正题之前，提出三点原则，这三点贯穿后面讨论的主轴：

（1）故障时刻会发生； （2）KISS原则：时刻保持简单； （3）自动化；

2.整体设计实践经验

问题出现的时候，人们往往自然倾向于首先审视运维工作，因为这是问题实际产生的地方； 不过，绝大多数运维问题都可以归因于设计和开发，这些问题比较适合在设计和开发阶段解决； 在服务领域，将开发、测试、运维严格分离不是最有效的方式，它们之间应该紧密相关。

2.1为故障的发生而设计（Design for failure）

这应该是一条核心概念，大规模的服务集群，故障时时刻刻在发生， 如果一有故障就需要采取紧急措施来应对，那服务就无法以合理的成本来控制， 整个服务必须有承受故障，而不需要人工干预： （1）恢复故障步骤必须非常简单，并且经过反复测试； （2）不能使用优雅的停机方式测试故障恢复步骤，怎么粗暴怎么来； 如果没有粗暴的故障恢复测试，问题真正来临的时候，就可能溃不成军。

2.2冗余与错误恢复（Redundancy and fault recovery）

服务器集群是脆弱的，设计必须保证，集群中的任何部件的随时崩溃，仍能提供正常服务（SLA，Service Level Agreement）。 设计中必须包含数据的冗余，服务的冗余与恢复机制。

2.3廉价硬件（Commodity hardware slice）

所有服务器应该以廉价硬件为目标，因为： （1）大型服务器价格昂贵； （2）服务器性能增长速度比IO性能增长速度快很多，这样一来，给定容量的磁盘，小型服务器的CPU就能满足性能需求； （3）小型服务器集群故障时，可能只影响一部分服务，如果设计得当，可以不影响服务；

2.4单版本软件（Single-version software）

某些服务比多数打包产品开发费用更低，且发展速度更快： （1）软件只需针对一次性的内部部署； （2）旧版本无需做到N年的支持，企业软件产品本是如此 经济型的服务不会把对客户运行的版本的控制权交给他吗，通常只应该提供一个版本，把我好单版本软件，需要注意： （1）发布不同版本的产品之间的用户体验变更不宜太大； （2）版本的控制应该在内部实施、

2.5多重租赁（Multi-tenancy）

单一租赁将不同组别的用户分离在不同的集群中，而多重租赁相反，其成本更低。

2.6其他实践经验

（1）快速服务健康性测试：新功能的开发，只有通过快速健康性测试，代码才能check in； （2）在完整环境中开发：单元测试往往需要其他组件的配合； （3）其他组件零信任：设想任何组件都可能出现故障，确保组件有能力恢复并继续提供服务，技巧包括：系统只读，依赖缓存数据运行；冗余恢复过程中，仍能向一部分用户提供服务； （4）一个功能只保留在一个组件中：不要多个组件干类似的事，这样做很可能引入冗余代码，导致代码膨胀和质量恶化，增加维护成本； （5）不同集群尽量不互相影响、互相依赖：集群独立，一个集群出故障时，可以迁移流量； （6）十万火急时人工干预：如果全自动化成本太高，或者紧急情况发生，请考虑人工干预的方式； （7）保持组件的简单与健壮性； （8）全面的准入控制； （9）服务分区：由于内存限制，或者数据规模限制，需要垂直、水平分割服务； （10）不承认网络层的透明性；

2.7分析吞吐量和延时

必须全面了解和分析服务吞吐量与延时情况，了解它们的影； 到底哪个指标更加重要，每个服务都应该形成一个度量标准，用于性能规划。

2.8运维工具是服务的一部分

谁说运维工具就不需要测试？

2.9理解应用层访问模式

新特性的规划，必须考虑应用层访问模式； 服务模型与存储能完全抽象分开么？不要忘了，访问模式会对Cache和数据造成很大的冲击和影响。

2.10所有工作版本化

目标是单版本软件，谁能保证呢，服务器所有组件应该保证N版本和N+1版本能够共存。 （1）保持最新版本的功能测试； （2）避免单点，尽量设计无状态的服务器；

3.自动管理的实践

反思一下系统中是否存在以下问题： （1）是否为服务编写了大量出现故障时报警的代码，以便人工干预恢复服务，这种模式7*24小时运维成本很高； （2）运维工程师在出故障时，高压力情况下，艰难的决定，有很高的比例他们会犯错； 以下是一些自动管理实践经验： 3.1随时可以重启，并保持冗余 3.2支持地理分布 3.3自动预置与安装，保持环境一致 3.4配置是代码的一部分 3.5任何环境的变更必须有审计记录 3.6运维和管理服务器的角色，而不是服务器本身 3.7多组件故障是常见的，如机房故障 3.8重视服务级别的恢复 3.9不可恢复的信息，不能依赖于本地存储 3.10保持部署简单性 3.11定期停服务演习

4.组件依赖管理实践经验

组件间多多少少存在一定依赖关系，其中的实践经验有： 4.1时刻为延时做准备：配合组件随时可能超时； 4.2快速故障隔离：fail-fast设计原则，冗余足够时，快速挂掉重启可能是更好的选择； 4.3使用经过线上考验的组件：新技术的实施需要预留提前量； 4.4跨服务的监控与报警：运维工程师和开发工程师都能收到报警么，分别布置的监控么，运维工程师收到报警，但解决不了问题时，能及时找到接口的开发工程师么； 4.5附属服务的设计也需要遵循SLA原则 4.6组件尽量解耦

5.测试实践经验

如果条件允许，大部分服务都应该在一个与线上环境类似的环境下测试，并使用线上负载，以反映真实的状况。 以下原则必须遵守： （1）线上系统必须有足够冗余，在灾难性故障发生时，能够快速恢复； （2）数据不能丢失； （3）故障必须可检测，开发团队（非运维团队）必须监控系统健康度； （4）所有操作可回滚，所有回滚必须测试。 以下是一些实践经验： 5.1经常性交付：频繁的交付、测试，能够增强产品质量； 5.2使用线上数据来发现问题 （1）发布标准必须可度量，例如可用性必须达到99%，压力能承受100rps； （2）实时线上数据调优； （3）收集实际数据； （4）不能过度报警，过度报警会让运维人员麻木不仁； （5）趋势分析； （6）高透明度的系统健康性报告； （7）持续监控； 5.3在设计上加大投入：不是加大运维成本，而是花时间加强设计； 5.4支持版本回滚； 5.5保持版本兼容； 5.6降低环境搭建成本，支持快速单机部署（否则单元测试难度会很大）； 5.7压力测试必须高于线上负载； 5.8功能测试、性能测试必不可少； 5.9迭代性构建与部署； 5.10使用真实数据测试； 5.11系统级测试必不可少； 5.12在完整环境中测试与开发。

6.运维实践经验

我们的目标是：让一个8*5的运维团队高效维护整个高可靠的24*7系统。 一条普适规则是：如果没有经过频繁测试，任何操作与程序都无法正常工作，不要实现团队没有勇气使用的任何东西。 实践经验有这样一些： 6.1让开发团队承担责任：谁创建的就该谁管，如果不想运维团队半夜给你打电话，就做出一套自动化方案； 6.2只进行软删除，不要删除任何东西； 6.3跟踪资源的分配，了解系统开销； 6.4每次只变更一样东西； 6.5尽量让所有资源都可配置；

7.审核、监控与报警

原则是：所有关键事件都得报警，无需采取措施时没有报警。 有两条度量标准： （1）报警与实际故障比； （2）没有报警与故障数量比； 一些实践经验是： 7.1所有资源都必须进行检测； 7.2数据是最有价值的资产； 7.3从用户的角度看服务； 7.4检测与监控是线上服务必不可少的； 7.5延时是棘手的问题； 7.6细粒度的监控机制必须在早期建立； 7.7可配置的日志功能； 7.8外部化健康信息； 7.9所有错误可应对，无法采取措施的错误报告毫无意义； 7.10快速诊断；

8.优雅降级与访问控制

实践经验有： 8.1支持“大红开关(big red switch)”，能够在紧急状况时，卸载掉非关键负载； 8.2访问控制：系统能够方便的禁止某些负载么？ 8.3对访问的统计；

9.结束语

要降低大规模服务的运营成本并改善服务的可靠性，一切从编写服务时注重运营友好开始。

注：原文见On Designing and Deploying Internet-Scale Services

作者是：James Hamilton(Windows Live Services Platform)