大规模服务器设计与开发实践经验（阅读笔记）

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

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)