谈谈高可用之压测与预案

前言

在电商大促、春运抢票等大流量来临前，开发人员需要对系统进行梳理，发现系统的性能瓶颈，然后通过调优等手段提升系统的可用性。一般可通过全链路压测手段找到系统的瓶颈，然后针对性地进行系统调优，如JVM调优，SQL调优，线程池参数调优等。但即使我们将调优做到极致了，也存在一些不可预知的因素，如网络的不稳地性，这就需要我们做应急预案，在出现这些问题时，及时将请求进行路由切换或者降级处理。换句话说，在这种大促活动前，我们需要对系统做全方位的压测和预案演练。

系统压测

压测指的是性能压力测试，较常见的压测工具有JMeter、Apache ab等。压测数据可以用来评估系统的稳定性和性能，我们也能通过它进行系统容量评估，从而根据实际情况决定是否需要扩容或缩容。

压测之前可制定相应的压测方案，如压测接口、并发量、压测策略（突发、逐步加压）、压测指标（如QPS/TPS/RT等），压测完成后要出压测报告，报告上面要包含机器负载（CPU、内存使用率等）、峰值TPS/QPS、响应时间（平均/最大/最小）、TP99/TP999等数据。拿到压测报告后，我们可做相应的系统优化和应急预案。

压测分类有很多，如读压测、写压测、单机压测、集群压测，仿真压测。

读压测和写压测很好理解，不多描述，但有一点需要注意，真实线上环境通常是读写操作混合的，因此不能仅仅做分开的读压测和写压测，也需要混合进行。

单机压测指的是对集群中的单台机器做压测，从而评估出单机服务的极限处理能力，找到单机的瓶颈，并将单机性能优化到极致。

集群压测指的是对分布式集群服务依赖的资源做压测，如数据库、分布式缓存等。

仿真压测指的是通过模拟真实流量进行系统压测，模拟的数据可以是人工构造，用程序构造，也可以使用TCPCopy复制线上的真实流量，然后引流到压测集群服务器进行压测。

系统优化和容灾

拿到压测报告后，接下来可以针对性的对系统做优化，比如硬件升级、机器扩容、架构优化（如加缓存、读写分离、消息队列等）、参数调优（如JVM）、Sql慢查询优化、代码优化（如同步改为异步）。在代码优化的过程中，可以审查有无不合理的参数配置，如超时时间、重试次数、降级策略、缓存时间等。在考虑是否需要扩容时，可以根据往年的流量、业务的发展趋势等因素来判断，预估出峰值流量，当然这不能保证准确性，所以还需要有应对突发情况的能力，如快速扩容。

系统应急预案

在完成系统优化和扩容后，还是会有一些不稳地因素，如网络抖动，某台机器负载过高，数据库宕机等情况，为了防止这些不可预知的因素导致系统不可用，我们需要提前做故障演练，并制定相应的应急预案，从而提升系统的可用性。
系统的每个层次每个链路，都有可能发生故障，因此我们可按照下面的表格对它们采取相应的措施。

网关接入层

应用接入层


Web应用层和服务层

数据层

系统监控

对关键资源和指标做监控报警是非常有必要的，包括服务器监控（CPU、内存、磁盘使用率等）、JVM监控（堆内存使用情况、GC频率/时间、线程数等）、接口监控（接口调用量（QPS/TPS等）、平均响应时间RT（TP999、TP9999等））。然后配置报警阈值、报警策略、通知方式，这样能够及时的发现故障并通知到相关负责人，并快速解决问题，必要时可先做应急处理，如限流降级。

参考资料：
《亿级流量网站架构核心技术》