每分钟访问10万+，11种策略教你保持亿级流量网站稳定性！

稳定性在大型网站运行中至关重要，面对每分钟 10 万次的网络访问，稍有不慎就会引起重大故障。今天这篇文章一起讨论下亿级流量网站在稳定性方面的一些做法，希望对您有帮助。

基础策略

配置化

配置化就是把很多业务流程相关的数据统一放在一个配置平台上，从代码中抽离出来，使得代码仅处理通用的业务逻辑。配置化之后，代码拥有处理所有场景的能力，通过配置数据来决定线上运行时具体操作什么样的数据。

配置化的设计使得我们能够对线上进行快速更改，做到实时的增加、变更和删除，对于快速处理问题有很好的效果。

业务开关

业务开关就是针对具体一个流程的开关，通过开关的打开和关闭可以实时控制处理逻辑。开关可以有多种类型，常用的有以下几种。

Boolean 类型：是否使能某个流程，如开启和关闭某个校验；

Number 类型：业务对应的数字配置；

String 类型：业务对应的文本配置；

Collection 类型：业务对应的集合开关，如指定特定类型的业务启动或关闭流程；

Map 类型：业务对应的映射开关，如指定特定类型的业务进行特定类型的处理。

部署策略

面对每分钟达 10 万次的访问流量，系统的部署是个很大的挑战。我们采用按机房、按机器分组进行分批次的部署策略，也就是在部署过程中，新版本与老版本共存，同时提供服务，整个的部署过程是一个逐步替换的过程。

灰度部署逐步提高新版本在服务中的比例，分流线上用户进行灰度测试。如果发现机器日志有异常或有用户反馈服务问题，可以第一时间进行新版本回滚，避免产生更大范围的影响。

错误处理

在软件架构中要对错误处理有一套统一的流程和规范，对错误码进行分类处理，做到根据统计到的错误码能够快速判断错误类型。要做到这一点，错误码需要约定好统一的格式，比如 CHK 开头表示校验失败、THD 开头表示第三方服务错误、SYS 表示当前系统错误，REQUIRED 结尾表示必填项未填、INVALID 结尾表示数据错误、EXCEPTION 结尾则表示出现异常。

日志收集

如果想学习Java工程化、高性能及分布式、深入浅出。微服务、Spring，MyBatis，Netty源码分析的朋友可以加Java进阶群：582505643，群里有阿里大牛直播讲解技术，以及Java大型互联网技术的视频免费分享给大家。

程序运行一定会产生日志，日志是排查线上问题的第一手原始资料。准确完整地记录下有意义的日志，才能进行有效的分析。比如基于日志，我们可以统计服务调用量并分析成功率，可以明确地看到错误信息，包括哪些用户出错、出错的原因是什么，并可以建立线上问题报警机制。

日志需要按照统一的格式打印，存储在一个统一的日志分析服务中，做到实时记录、实时搜索。

线上监控策略

链路跟踪

分布式系统的一个难题，就是如何跟踪处理链路。通常情况下，我们会在链路的起点为每一个请求生成一个唯一识别码，比如 UUID，并在以后的每一个处理节点都记录下识别码并传播给下一个处理节点。

基于这样的唯一识别码，我们可以从海量日志中完整地还原出一个请求在链路上的处理过程，以及输入输出数据，进行全链路分析。

异常监控

对 Java 抛出的异常进行处理，打印到日志中，可以建立起异常监控。在异常监控中，我们重点关注异常发生的次数、栈信息、变化趋势。

通过异常监控，可以快速定位线上问题，直接根据栈信息找到异常发生的地点。如果是第三方服务的异常，比如分布式调用超时，也能够快速分析并定位。

机器监控

机器监控则是重点关注机器的 CPU、内存、网络使用情况，JVM 的线程数量、内存使用、Full GC 次数等。流量洪峰到来时，服务器承压，很可能出现 CPU、内存不足等情况，也可能导致 JVM 内存不足进行 Full GC，进而引起服务崩溃。服务器运行状况如此重要，不能不重视。

面对流量洪峰的策略

服务降级

服务降级是指在特定情况下，比如双十一、双十二期间，当流量超过系统服务能力时，跳过特定的处理流程。比如在一个卖家下单后，我们可能需要进行风险评估、数据校验等一系列流程，当发生服务降级时，就跳过了数据校验逻辑，来保证服务的稳定性。

服务降级是面对流量洪峰保证用户体验和预防系统崩溃的有效手段。比如图片内容的校验通常都是比较耗时的操作，面对流量洪峰取消这样的校验可以避免用户的长时间等待、降低对下游链路的冲击，确保服务稳定。

服务限流

服务限流是指，根据服务的处理能力提前预估出一个阈值，当流量大于该阈值时直接放弃处理直接返回错误。服务限流是应对流量峰值时，系统进行自我保护的重要措施。比如双十一零点下单峰值、余额宝九点抢购峰值、活动结束商品编辑峰值，都需要进行相应的限流来保护系统。

在分布式部署中，基于 dubbo、Spring cloud 或 HSF 的数据统计功能，很容易推算出系统平时的流量压力。借助于全链路压测，可以很容易看到系统在流量峰值下的具体表现。因此，服务限流的实施并不困难。

故障容灾

单机系统的容灾能力几乎为零，一旦服务崩溃就马上变成不可用。分布式系统通过服务多活，可以不间断提供服务；借助于 nginx、Apache 进行负载均衡可以进一步提高可用性。

实际上，即便进行了负载均衡和服务分布式部署，系统仍然面临容灾问题。现在的大型服务，比如淘宝、天猫、微信、京东都进行了异地多活的部署。异地多活部署的主要目的，在于通过多机房提供服务，来降低单机房故障带来的影响，提高容灾能力。

总结

这篇文章大概整理了一个亿级流量网站在稳定性方面需要注意和做好的点，关于稳定性还有很多问题值得探讨和深思