设计和部署互联网级别的可扩展服务--On Designing and Deploying Internet-Scale Services

On Designing and Deploying

Internet-Scale Services
James Hamilton– 2007.12
翻译与摘要 by watermelonbig at 2016.9

本文总结了用于设计和开发运维友好的服务的一系列最佳实践。

以下为三条基本原则，这三条原则形成了贯穿后面大多数讨论的主线。

1. Expect failures
2. Keep things simple
3. Automate everything

本节被分成如下10小节，每小节都覆盖了设计和部署运维友好的服务所需遵守的不同方面的要求：

1. 总体服务设计
2. 自动化管理和配置
3. 依赖管理
4. 发布周期和测试
5. 硬件选型和标准化
6. 运维和容量规划
7. 审计监控和报警
8. 优雅降级和准入控制
9. 客户和媒体沟通计划
10. 客户自配置和自助

总体设计

• Design for failure，一种最好的测试服务失败的方法就是，从不按正常的方式关闭服务。要频繁得测试失效恢复的手段。
• Redundancy and fault recovery，一种方法是security threat modeling:评估所有的风险因素并为之设计解决方案。
• Commodity hardware slice，使用廉价硬件，大规模的PC服务器一定要比小规模的小型机有更好的性价比，服务器计算性能的使用需求总是比I/O性能需求增长得更快，耗电量虽然随服务器数量的增长而线性增长但是却与计算机时钟频率的增加成3倍数增长，一个小型设备的失效对整体服务带来的影响会比较小。
• Single-version software
• implement Multi-tenancy，为服务设计提供多用户的复用。

设计出运维操作友好的系统的最佳实践是：

• Quick service health check，服务健康状况快速检查，使用在开发构建阶段执行的快速测试用例保证核心服务的正确。
• Develop in the full environment，开发工程师除了要做单元测试外还应该在一个部署完整应用的测试环境进行测试验证。
• Zero trust of underlying components，预期在开发的功能是不可靠且会发生失效故障的，为此准备数据冗余和服务恢复策略。
• Do not build the same functionality in multiple components，服务的快速增长要求项目代码注意减少重复冗余的内容。
• One pod or cluster should not affect another pod or cluster，确保一个系统或集群减少对外部系统或集群的资源依赖，避免发生因外部系统故障导致的自身服务不可用。
• Allow (rare) emergency human intervention，系统应该被设计成在大多数使用场景中都不需要人工干预而可以正确运行，但在极端灾难性故障中仍可以通过人工干预操作执行特定的灾难恢复计划。这类人工干预操作应该尽可能设计并开发成可验证测试的脚本，定期进行演练。
• Keep things simple and robust
• Enforce admission control at all levels，任何一个好的应用系统都会提供服务准入控制的功能，这在面对异常负载压力时应用服务降级策略以确保核心服务一定程序上的可用性是非常重要的。
• Partition the service，分区需要有良好的规划并支持灵活调整，建议使用一个中间层的数据查询表对规划分区和使用用户进行映射。一个良好规划的分区方案应该允许分区在不同主机之间的自由迁移。
• Understand the network design，在早期阶段就要评估出应用负载在不同主机之间、不同机柜间甚至多个数据中心之间的通信使用需求与负载分布。
• Analyze throughput and latency，分析系统的吞吐量与响应延时，掌握系统的最大负载能力。可以适当使用一些性能测试指标。
• Treat operations utilities as part of the service，在项目开发、测试和维护各环节开发或使用的运维工具也应该作为服务的一部分，执行代码review、纳入测试与发布计划。
• Understand access patterns，理解数据访问模型，在规划上线一个新特性时应该评估该特性的数据访问模型以及可能带来的性能负载大小。
• Version everything
• Keep the unit/functional tests from the last release
• Avoid single points of failure，避免系统中存在单点故障的环节。

Automatic Management and Provisioning

自动化管理与配置：

实现自动化的最佳实践：

• Be restartable and redundant，所有的服务维护都要能够重启，所有的持久化数据都是做到冗余存储。
• Support geo-distribution
• Automatic provisioning and installation
• Configuration and code as a unit
• Manage server roles or personalities rather than servers
• Multi-system failures are common
• Recover at the service level
• Never rely on local storage for non-recoverable information
• Keep deployment simple
• Fail services regularly，定期对生产环境进行服务故障应急演练

Dependency Management

依赖管理的最佳实践：

• Expect latency，提供服务调用的超时设计，避免对一个外部服务的依赖导致自身的不可用。
• Isolate failures，隔离失效的服务，进行快速失败处理，避免让依赖这些失效服务的其它应用服务花费大量时间在调用和等待超时上面。
• Use shipping and proven components，使用验证可靠的技术方案和稳定版本的软件。
• Implement inter-service monitoring and alerting，对依赖的其它服务进行监控和预警，应能恢复或尽快联系到依赖服务的运维人员进行恢复。
• Dependent services require the same design point
• Decouple components，适当得解耦组件间的强依赖性，这样即使在一个组件临时无法访问时，其它组件仍然能够继续提供服务，哪怕是在一个降级的模式下。

Release Cycle and Testing

发布周期与测试工作的最佳实践：

• Ship often，经常发布
• Use production data to find problems，使用生产环境数据或在生产环境中测试，以发现问题
• • Measureable release criteria，定义出适当的应用发布关键指标，用以评定发布的成败
  • Tune goals in real time
  • Always collect the actual numbers，经常收集实际的运行指标数据
  • Minimize false positives，最小化应用输出的假性错误日志，避免过度报警或操作人员要学会忽略这部分信息
  • Analyze trends
  • Make the system health highly visible，使用一个website展示服务的运行状态信息是一个很好的办法
  • Monitor continuously
• Invest in engineering，很多公司更容易采取扩容运维团队的办法去处理日益增长的运维工作内容，而不是花些时间在系统架构的扩展性、可靠性方面做出优化。
• Support version roll-back，请使用适当的版本控制软件管理应用发布代码以提供发布版本回滚的能力。
• Maintain forward and backward compatibility
• Single-server deployment，提供单机部署和运行服务的能力对于单元测试很重要，否则会有很多测试内容只能被动得跳过。此外这样处理也能让开发人员更多的从系统整体的视角看待某个功能组件的实现。
• Stress test for load，上线前的压测
• Perform capacity and performance testing prior to new releases，对新版本服务进行容量和性能测试
• Build and deploy shallowly and iteratively，尽早得在线上构建、部署服务，即使暂时无法提供什么可用功能，也能为开发和测试带来很多好处，这对开发一些服务类应用时尤其明显。
• Test with real data
• Run system-level acceptance tests
• Test and develop in full environments

Hardware Selection and Standardization

硬件选型与标准化的最佳实践：

• Use only standard SKUs，只使用和维护少量的硬件设备型号对于实现公司线上业务系统的自动化管理、监控和服务的标准化都很重要，太多的个性化硬件设备型号会让这些提高运维水平的尝试变得艰难
• Purchase full racks，整机柜的部署设备以减少每台设备的平均上架成本
• Wr i t e to a hardware abstraction，撰写一份硬件选型的通用规范，但要避免掺杂进那些过细的技术指标。
• Abstract the network and naming，使用DNS、CNAMEs来管理设备的命名空间，这样在个别设备发生故障后，可以方便得使用新设备进行替代
  

Operations and Capacity Planning

运维和容量规划：

• 一般而言一个服务都需要提供24*7的高可用，但只需要一个8*5的小规模团队进行维护
• 任何依赖于手工的sql处理、生产数据同步操作，都可能因人为运维操作引发灾难性故障，因此需要预先开发和实现自动化的故障处理与服务转移功能。应急恢复脚本需要经常在生产环境中进行演练测试，否则这些应急恢复功能会很快失去其可用性。经常能看到，一些重要的系统因为个别服务环节没能实现自动化的故障转移能力，最终引发和导致了整个系统的故障。
• Make the development team responsible，amazon在这方面的管理要求是，谁开发、谁维护。
• Soft delete only
• Tr a c k resource allocation
• Make one change at a time
• Make Everything Configurable

Auditing, Monitoring and Alerting

审计、监控与预警的最佳实践：

• Instrument everything , 利用一切能用到的工具
• Data is the most valuable asset
• Have a customer view of service
• Instrumentation required for production testing
• Latencies are the toughest problem
• Have sufficient production data
• • Use performance counters for all operations
  • Audit all operations
  • Track all fault tolerance mechanisms
  • Asserts
  • Keep historical data
• Configurable logging
• Expose health information for monitoring
• Make all reported errors actionable
• Enable quick diagnosis of production problems
• • Give enough information to diagnose
  • Chain of evidence
  • Debugging in production，要减少直接在生产环境中调试的机会
  • Record all significant actions

Graceful Degradation and Admission Control

服务降级与准入控制的最佳实践：

• Support a ‘big red switch.’，这个概念的意思是在遇到意外高的业务负载时要提供这样的手段，可以保证核心功能继续可用而临时停用或延迟那些次要功能、高级功能。当然也有另外一种处理方式是采用队列方式应对暴涨的负载。这种服务降级切换的功能必须是可逆的。
• Control admission，过高的负载只会大幅拉低服务的处理性能，可以设计多种维度的准入规则，在遇到大业务负载情况时把一部分负载关在门外而优先处理准入的那部分流量。
• Meter admission，可计量的负载控制能力，在一个服务发生故障并恢复后，需要先分配少量的负载流量过去以验证服务的正确性，再视测试情况逐步分配更多的负载流量。

Customer and Press Communication Plan

面向客户与媒体的沟通计划：

• 及时向客户通报服务故障情况与处理进度、恢复时间等信息，会极大提高客户的满意度；
• 一些会产生较严重后果的服务故障，需要通过媒体进行信息发布，应该预先准备好类似事件的沟通计划安排；

Customer Self-Provisioning and Self-Help

客户的自配置与自助服务：

这可以降低企业成本，且提高客户满意度。