互联网系统为大量的C端用户提供服务，如果隔三差五的出问题宕机，会严重影响用户体验，甚至导致用户流失。所以稳定性对互联网系统非常重要！接下来，我根据自己的实际经验来聊聊基于微服务的互联网系统的稳定性。

下面我们从雪崩、隔离、服务降级、突发流量、缓存、数据冗余、熔断、限流、CDN、数据库、CI、网络等方面，聊聊如何保证基于微服务的系统稳定性。

雪崩效应产生原因，如何避免？

服务化后，服务变多，调用链路变长，如果一个调用链上某个服务节点出问题，很可能引发整个调用链路崩溃，也就是所谓的雪崩效应。

举个例子，详细理解一下雪崩。如上图，现在有A，B，C三个服务，A调B，B调C。假如C发生故障，B方法1调用C方法1的请求不能及时返回，B的线程会发生阻塞等待。B会在一定时间后因为线程阻塞耗尽线程池所有线程，这时B就会无法响应A的请求。A调用B的请求不能及时返回，A的线程池线程资源也会逐渐被耗尽，最终A也无法对外提供服务。这样就引发了连锁故障，发生了雪崩。纵向：C故障引发B故障，B故障引发A故障，最终发生连锁故障。横向：方法1出问题，导致线程阻塞，进而线程池线程资源耗尽，最终服务内所有方法都无法访问，这就是“线程池污染”

为了避免雪崩效应，我们可以从两个方面考虑：

• 在服务间加熔断。解决服务间纵向连锁故障问题。比如在A服务加熔断，当B故障时，开启熔断，A调用B的请求不再发送到B，直接快速返回。这样就避免了线程等待的问题。当然快速返回什么，fallback方案是什么，也需要根据具体场景，比如返回默认值或者调用其他备用服务接口。如果你的场景适合异步通信，可以采用消息队列，这样也可以有效避免同步调用的线程等待问题。

• 服务内（JVM内）线程隔离。解决横向线程池污染的问题。为了避免因为一个方法出问题导致线程等待最终引发线程资源耗尽的问题，我们可以对tomcat，dubbo等的线程池分成多个小线程组，每个线程组服务于不同的类或方法。一个方法出问题，只影响自己不影响其他方法和类。

常用开源熔断隔离组件：Hystrix，Resilience4j

如何应对突发流量对服务的巨大压力？

促销活动或秒杀时，访问量往往会猛增数倍。技术团队在活动开始前一般都会根据预估访问量适当增加节点，但是假如流量预估少了（实际访问量远大于预估的访问量），系统就可能会被压垮。所以我们可以在网关层（Zuul，Gateway，Nginx等）做限流，如果访问量超出系统承载能力，就按照一定策略抛弃超出阈值的访问请求（也要注意用户体验，可以给用户返回一个友好的页面提示）。

可以从全局，IP，userID等多维度做限流。限流的两个主要目的：1，应对突发流量，避免系统被压垮（全局限流和IP限流）2，防刷，防止机器人脚本等频繁调用服务（userID限流和IP限流）

数据冗余

在核心链路上，服务可以冗余它依赖的服务的数据，依赖的服务故障时，服务尽量做到自保。比如订单服务依赖库存服务。我们可以在订单服务冗余库存数据（注意控制合理的安全库存，防超卖）。下单减库存时，如果库存服务挂了，我们可以直接从订单服务取库存。可以结合熔断一起使用，作为熔断的Fallback（后备）方案。

服务降级

可能很多人都听过服务降级，但是又不知道降级是怎么回事。实际上，上面说的熔断，限流，数据冗余，都属于服务降级的范畴。还有手动降级的例子，比如大促期间我们会关掉第三方物流接口，页面上也关掉物流查询功能，避免拖垮自己的服务。这种降级的例子很多。不管什么降级方式，目的都是让系统可用性更高，容错能力更强，更稳定。

缓存要注意什么？

1. 缓存穿透。对于数据库中根本不存在的值，请求缓存时要在缓存记录一个空值，避免每次请求都打到数据库

2. 缓存雪崩。在某一时间缓存数据集中失效，导致大量请求穿透到数据库，将数据库压垮。可以在初始化数据时，差异化各个key的缓存失效时间，失效时间 = 一个较大的固定值 + 较小的随机值

3. 缓存热点。有些热点数据访问量会特别大，单个缓存节点（例如Redis）无法支撑这么大的访问量。如果是读请求访问量大，可以考虑读写分离，一主多从的方案，用从节点分摊读流量；如果是写请求访问量大，可以采用集群分片方案，用分片分摊写流量。以秒杀扣减库存为例，假如秒杀库存是100，可以分成5片，每片存20个库存。

关于隔离的考虑

1. 部署隔离：我们经常会遇到秒杀业务和日常业务依赖同一个服务，以及C端服务和内部运营系统依赖同一个服务的情况，比如说都依赖订单服务。而秒杀系统的瞬间访问量很高，可能会对服务带来巨大的压力，甚至压垮服务。内部运营系统也经常有批量数据导出的操作，同样会给服务带来一定的压力。这些都是不稳定因素。所以我们可以将这些共同依赖的服务分组部署，不同的分组服务于不同的业务，避免相互干扰。

2. 数据隔离：极端情况下还需要缓存隔离，数据库隔离。以秒杀为例，库存和订单的缓存（Redis）和数据库需要单独部署！数据隔离后，秒杀订单和日常订单不在相同的数据库，之后的订单查询怎么展示？可以采用相应的数据同步策略。比如，在创建秒杀订单后发消息到消息队列，日常订单服务收到消息后将订单写入日常订单库。注意，要考虑数据的一致性，可以使用事务型消息。

3. 业务隔离：还是以秒杀为例。从业务上把秒杀和日常的售卖区分开来，把秒杀做为营销活动，要参与秒杀的商品需要提前报名参加活动，这样我们就能提前知道哪些商家哪些商品要参与秒杀，可以根据提报的商品提前生成商品详情静态页面并上传到CDN预热，提报的商品库存也需要提前预热，可以将商品库存在活动开始前预热到Redis，避免秒杀开始后大量访问穿透到数据库。

   

慢查询和大结果集问题

数据库层面主要考虑慢查询和大结果集问题：

1. 慢查询是系统故障的罪魁祸首，如何避免慢查询，也是我们必须思考的问题。我们的做法是所有新加和修改的sql语句都要经过DBA审核，并且做好线上慢查询监控。

2. 大结果集问题。如果用mybatis，某些字段传了空值或者忘传了，if 判断为假，就漏掉了相关条件，很有可能导致大结果集产生。为了避免大结果集，我们除了做好必传参数校验，还可以加一个拦截器，来限制所有结果集的条数，比如一个SQL最多查100条。

系统问题快速定位！

服务化后，一次请求会跨多个服务，追踪问题也会变麻烦。这时就需要能够追踪整个调用链路的工具，协助我们排查问题。常见的开源全链路监控工具有（pinpoint，skywaking，cat等），以Pinpoint为例简单介绍一下：

Pinpoint基于JAVA，利用字节码增强技术，对服务零侵入，以traceID串联各个服务，已Plugin的方式支持不同API和中间件的监控，灵活方便。

上图是一个请求的调用栈，我们可以清晰看到一次请求调用了哪些服务和方法以及各个环节的耗时，以及发生在哪个节点。如果发生错误，会显示为红色，错误原因也会直接显示出来。这样通过APM系统我们就能轻松定位线上性能问题和错误了！

CI测试&性能测试

CI测试，持续集成测试，在我们每次提交代码到发布分支前自动构建项目并执行所有测试用例，如果有测试用例执行失败，拒绝将代码合并到发布分支，本次集成失败。CI测试可以保证上线质量，适用于用例不会经常变化的稳定业务。

性能测试，为了保证上线性能，所有用户侧功能需要进行性能测试。上线前要保证性能测试通过。而且要定期做全链路压测，有性能问题可以及时发现。

监控

我们需要一套完善的监控系统，系统出问题时能够快速告警，最好是系统出问题前能提前预警。包括系统监控（CPU，内存，网络IO，带宽等监控），数据库监控（QPS，TPS，慢查询，大结果集等监控），缓存中间件监控（如Redis），JVM监控（堆内存，GC，线程等监控），全链路监控（pinpoint，skywaking，cat等），各种接口监控（QPS，TPS等）

CDN

可以充分利用CDN。除了提高用户访问速度之外，页面静态化之后存放到CDN，用CDN扛流量，可以大幅减少系统（源站）的访问压力。同时也减少了网站带宽压力。对系统稳定性非常有好处。

避免单点问题

除了服务要多点部署外，网关，数据库，缓存也要避免单点问题，至少要有一个Backup，而且要可以自动发现上线节点和自动摘除下线和故障节点。

网络带宽

避免带宽成为瓶颈，促销和秒杀开始前提前申请带宽。不光要考虑外网带宽，还要考虑内网带宽，有些旧服务器网口是千兆网口，访问量高时很可能会打满。

安全

1. 可以在网关层上面再加一层防火墙或者高防服务，来防御DDos，CC等分布式网络攻击。

2. 机器人脚本防刷，前面已经提到过，可以在网关层对下单等接口按userID限流。

此外，一套完善的灰度发布系统，可以让上线更加平滑，避免上线大面积故障。DevOps工具，CI，CD对系统稳定性也有很大意义。

OK，就分享到这。

特别推荐一个分享架构+算法的优质内容，还没关注的小伙伴，可以长按关注一下：

长按订阅更多精彩▼如有收获，点个在看，诚挚感谢