大型分布式网站架构笔记二
接上篇：
4 系统稳定性
系统上线后，可能会发生各种各样的运行问题。如依赖的应用宕机、程序bug、线程死锁、黑客攻击、负载过高等。发生了问题如何快速定位，如何最大程度地保证线上系统的稳定性，都是本章将要探讨的问题。
4.1 在线日志分析
在线日志分析是出现问题时最常用的问题分析方式。日志中包含了程序在遇到异常情况所打印的堆栈信息。通过异常堆栈可以定位到产生问题的代码行；通过访问IP和请求url参数，排查是否遭到攻击；通过应用的响应时间、垃圾回收，以及系统load来判断系统负载，是否需要增加机器；通过线程dump，判断是否死锁及线程阻塞的原因；通过GC日志，对系统代码和JVM内存参数进行优化，减少GC次数与stw时间，优化应用响应时间。
日志分析命令和脚本网上资料很多，不展开详述。
4.2 集群监控
成熟稳健的系统往往需要对集群运行时的各个指标进行收集，如系统的load，CPU利用率，I/O繁忙程度，网络traffic，内存利用率，应用心跳等，对这些信息就行实时监控，如发现异常情况能够第一时间通知到相应的开发和运维人员进行处理。
4.2.1 监控指标
Load
系统的load是指特定时间间隔内运行队列中的平均线程数。每个cpu的核都维护了一个运行队列，系统的load主要由运行队列来决定。假设一个CPU有8核，运行的应用程序启动了16个线程且都处于运行状态。在平均分配的情况下，每个CPU的运行队列中就有2个线程在运行。假设这种情况维护了1分钟，则这一分钟内系统的load就是2。Load值越大，意味着系统的CPU越繁忙，每个线程获取CPU时间的间隔也越大。一般来说CPU的活动线程数不大于3是正常的，大于5表示系统负载高。
4.2.2 心跳检测
分布式系统一般都是以集群形式存在的，集群中任何一个节点出问题，都需要能够快速检测并且移除。因此对集群服务器和部署于其上的应用的心跳检测是必不可少的。
心跳检测有多重实现方案，作用除了用于检测节点故障之外，还可用于服务故障的检测。服务故障检测主要是针对业务层面的，可定期的发送一些无损的业务请求，以判断服务器是否正常提供服务。比如在博主的工作中，专门做了一个简单的心跳检测系统，通过定期调用其他业务系统的一些查询接口，来验证服务的可用性，以此达到心跳检测的目的。
4.3 流量控制
4.3.1 流量控制方式
任何系统都有承载上限，因此在分布式系统中，对超过上限的流量进行控制是必须的。流量控制可以从多个维度来进行，如对系统的总并发请求数进行限制，或者限制单位时间内的请求次数(如限制qps)，或者通过白名单机制来限制接入系统调用的频率。不同的机制适应不同的场景。
对于超载的流量最简单的处理方式是直接丢弃，不进行任何处理直接返回，但会给用户带来糟糕的用户体验。