构建健壮的大规模分布式系统

￡神魔★判官ぃ 2022-08-19 15:18 228阅读 0赞

**构建健壮的大规模分布式系统**

实际的生产环境中，经常会由于机器故障、机房掉电、网络异常、软件bug等原因，造成整个系统中某台机器、某些集群异常，无法提供稳定的服务；而系统也可能因为某些突发事件、外部攻击等原因，出现流量瞬间的大幅度增长，超过系统承载能力。因此，在系统设计时，需要充分的考虑系统的优雅降级、流量控制等。最近阅读了不少相关的文档，本文进行了整理，列举了一些构建大规模分布式服务的design principle如下。

### Design Target ###

在设计初期，就需要充分考虑可扩展性、系统的可用性、运维和管理的便捷性以及成本，几点说明如下：

*  Scalability : Resource usage increase linearly(or better!) with load
 *  Availability : Resilience to partial failure, Graceful degradation, Recoverability from failure
 *  Manageability : Simplicity, Maintainability, Diagnostics
 *  Cost : Machine cost and Operation cost

### System Availability ###

系统的可用度指标，需要明确两个指标MTBF和MTTR，定义如下

*  MTBR : Mean Time Between Failure (系统平均故障间隔时间)
 *  MTTR : Mean Time To Repair(系统平均修复时间)

[![image][]][image 1]

系统的可用度Availability = MTBF / (MTBF + MTTR)，因此，要提高系统的可用度，一方面要降低故障概率(理论上可无限降低，但实际上肯定不会为0)，更重要的一方面，需要提升系统的修复速度，如重启时间等。

### Design for failure ###

实际生产环境中，由于硬件老化、机房掉电、网络拥塞等，任何可能情况就会出现。所有的操作，都有可能故障，读写文件、读写网络等等。在系统设计和开发时，需要考虑任何失败下的异常处理。

*  Assume every operation will fail and resource may be unavailable
 *  Simple failure recovery path and tested frequently. never shutdown service normal, hard-fail for test.
 *  Be restartable at any time, Start fast.
 *  Decouple components, Fail fast, Isolate failures
 *  Allow emergency human intervention

### Partition the service ###

要构建强健的分布式服务，首先需要能够将整个服务进行拆分，分成不同的组件，进行故障隔离和恢复，动态的调整每个部件的容量，来保障服务的稳定性。

Functional Segmentation : Decouple different functional areas; Scale each component independently

Horizontal Split : Split strategies(Modulo,Range-based) ; Aggregation/Routing Proxy

Micro-partitions : load balancing, failure-recovery

Selective replication : Additional replicas to spread the load of hot partitions

### Automation ###

大规模分布式集群管理中，自动化非常重要，随着集群规模的不断扩大，频繁的故障的异常、机器的上架与下架、服务部署和重启，这些工作是无法靠几个人手工完成的，需要自动化集群管理工具，来完成以上的工作，并保证系统的稳定。

*  Service fail more frequently with system scale-up/out
 *  Automatic deployment and provisioning
    
     *  Failover fast, deploy new instance
     *  Configuration and code as a unit, keep deployment simple
 *  Staged rollout—scale-unit
    
     *  Split scale-unit with 1%, 5%, 10%, 20%, 50%, 100%
     *  each rollout with a scale-unit
 *  Automatic rollback when exception based on error-detection

### Monitor Everything ###

监控的重要性非常重要，才能保证系统出现大规模异常的前期和初期，进行快速定位修复，避免更大的损失，以下列举需要监控的部分内容。

*  Performance of all operations and specific span
 *  All the input data
 *  Log with warn/fatal/error level
 *  Fault tolerance mechanisms(系统中自动的一些降级操作等，也需要监控，明确当前系统的运行状态)
    
     *  Retry
     *  Turn-off/on advanced function
     *  Drop request

为了支持这种完善这样的监控，需要系统在设计时充分考虑Trace的需求，具体可以参考Google的Dapper论文，而Twitter的Zipkin是基于这个论文的一个开源版本实现。

### Failure Detection ###

除了数据监控，还需要通过日志等来进行实时预警发现系统中存在的异常，以及通过挖掘系统中的日志，寻找关联来发现更为深层次的原因，Ebay的Lessons给了我们一个样例：

*  Log requests, response, exception and external resource activity
 *  Message broadcast on message bus
 *  Listener automate failure detection and notification
    
     *  Real-time state monitoring : exception and alert
     *  Historical reports

[![image][image 2]][image_image 2]

### Quick Diagnose ###

数据监控、异常报警都快速的告知我们当前系统的运行状态，以及存在出现了部分异常，而异常的原因定位则更为关键，只有定位了根本原因才能快速的修复，缩短MTTR时间。

*  Give the detail information to diagnose
    
     *  500 requests failed is bad
     *  Here is the requests list and when they happened
 *  Chain of evidence : The path from beginning to the end of request
 *  Debugging in the production
    
     *  Support online debug
     *  Get the snapshot of specific modules, shipping it out of production
     *  Configurable logging
 *  Maintain and inspect interface
    
     *  Restful interface based on http
     *  Running data with key-value pair output

### Audit ###

最后是系统的审计(即任何影响系统的改动，如自动的数据更新、手动的修改部署等，都需要明确的记录并且方便的Dashboard查看，任何故障都是有原因的，绝大多数情况下，如果某个操作和故障的起始时间点match，这个操作或更新的嫌疑就非常大了。

*  Configuration audit trail
    
     *  Audit Configuration/Binary/Data changes
     *  What, when, who, which instances
 *  Dynamic data update history

### Alert is an art ###

报警是一个非常需要好好把握尺度的事情，包括报警的阈值、报警的接收人等，需要绝对的保证不漏报，尽可能不误报，并且减少不必要的打扰。

*  Minimal receivers of alert
 *  Alerts-to-trouble ticket ratio(with a goal of near one)
 *  Number of systems health issues without corresponding alerts.

参考的文章列表如下：

[On Designing and Deploying Internet-Scale Services][], [Lessons from eBay][], [Microsoft Autopilot][], [Google Dapper][]

**转载来源：[Leoncom][]\-[《构建健壮的大规模分布式系统》][Link 1]**

[image]: http://leoncom.org/wp-content/uploads/1465ef314739_1459E/image_thumb.png
[image 1]: http://leoncom.org/wp-content/uploads/1465ef314739_1459E/image.png
[image 2]: http://leoncom.org/wp-content/uploads/1465ef314739_1459E/image_thumb_3.png
[image_image 2]: http://leoncom.org/wp-content/uploads/1465ef314739_1459E/image_3.png
[On Designing and Deploying Internet-Scale Services]: https://www.usenix.org/legacy/event/lisa07/tech/full_papers/hamilton/hamilton_html/
[Lessons from eBay]: http://www.eos1.dk/qcon/sf2007/slides/public/RandyShoup_eBayArchPrinciples.pdf
[Microsoft Autopilot]: http://research.microsoft.com/pubs/64604/osr2007.pdf
[Google Dapper]: http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/pubs/archive/36356.pdf
[Leoncom]: http://leoncom.org/
[Link 1]: http://leoncom.org/?p=650845