流量来了，去努力保护好你的系统

怎么保护，又怎么努力。

保护，我们要有方法，勤梳理、扩机器、加限流、做降级。

努力，我们要在这些方法上进行有效、可持续落地。

今天，我们不谈具体的概念，或者是算法，比如限流，目前已有很多这方面的内容，我们一起来看一看如何有效地落地。

勤梳理

流量来之前，我应该怎么梳理我的系统呢。

仔细想，我们的系统中的请求流程，按照分类，大致有四种。

同步链路、异步链路、旁支链路、并发链路。我们可以按照这四种分类，把系统中的流程都梳理和归类。

这四种链路是如何定义的呢。

同步链路上的请求见文知意，上面的请求都是同步的调用。主要特点是强依赖。

链路上的服务是强依赖的，调用方需要等待被调用方执行完成后才能继续工作；

异步链路，同理，其中的请求都是异步的。主要是需要我们找出异步流量从哪里来，我们是否需要做蓄水，是否有消息重复消费。

链路上的服务没有强依赖关系，调用方不需要等待被调用方执行完成，可以继续执行后续工作，被调用方在另一个线程内执行完成后，通过回调通知调用方；

旁支链路，一般是非核心功能链路，比如商品某个评论的数量。主要是注意往往这类旁支功能容易被忽视，反而在大流量到来之时，如果没有做好相应隔离，打我们一个措手不及。

平时流量不大的”小“业务场景；

并发链路，这个是我们重点要防范的。主要是要找出高并发的爆点在哪里，哪个环节，哪个接口承受了最高的并发请求。

类似秒杀和红包雨这类；

你按照上面这四种类型去梳理好自己的系统，就能够有一个基本的因才施策的方法指导，它给你一个方向性的指导，不至于你，一头扎进系统代码里面不知道去梳理哪些内容。

我们在梳理的过程中，可以画什么图来辅助我们快速的识别到这些链路呢。

常用的图形思考方式有调用关系图、部署图和时序图。

我这里特意用了图形思考方式这个词，目的是通过画这些图来倒逼你去深入思考，并且是以体系化的方式去思考。

注意，在画这些图的时候，不要跟具体的形式和工具较劲，重内容轻形式。

扩机器

你可能说，流量来了，就直接堆机器呗。

看似简单的一件事情，可能也有些羁绊。主要是加机器不能仅仅只盯着服务本身资源的占用情况，还应该要同时关注对依赖资源的影响。

举一个例子。

某服务集群一共有 10 个容器实例，每个实例会建立约 100 个数据库连接，加起来就是约 1000 个连接，假设数据库总共支持的连接数为 1200 个，这是能够支撑现状的。但如果考虑到近期业务增长较快，会导致服务负载较大，需要扩容 5 个实例，那么总的数据库连接数大约会达到 1500 个，这就肯定支撑不住的，所以对服务进行扩容时，对数据库也需要同步扩容。

所以，有时候，我们只顾无脑地加机器了，结果把数据库给堆挂了。

再举一个服务发现上，长链接的例子。

在微服务体系中有一项服务发现机制，每个服务可以通过该机制获取被调用服务的位置。服务发现机制的一种实现方式是，由一个注册中心建立对每个服务实例的长连接，并维护一个服务状态列表，这样一旦服务状态发生变化，注册中心能够第一时间感知到并对服务状态列表进行更新。

还有一种情况，也是我们熟悉，但不注意也会阻碍我们加机器，就是状态。

如果你当前的服务集群是有状态的，那么你增加的任何一台机器，就必须要考虑如何把状态复制到新增加的机器上面。

这种羁绊，是业务上的，不是无状态的服务集群，将有很大的困难。也因此，我们常见的做法是将状态进行转移，比如远程缓存。

加限流

常用的限流算法，令牌桶、漏桶、滑动窗口、固定窗口，这些你在网上搜索能有很多的资料。

我们只想放一张图，来从更上一层角度，来说明限流需要注意的问题。

这张图说明的是我们正常情况下一个请求在一个分布式系统中的流向。分别经过了负载均衡、应用服务、数据库。

图自 吴俊龙 https://time.geekbang.org/column/article/375295

从这张图里面，我能够看到，每一层其实都有限流，而且每一层都不应该相信上层，”不要将自己的命运交给别人“。

每一层做好自己的限流，整体的限流体系才是最健壮、最可靠的。

从另外一个角度来讲，如果上一层没有防住，流量把你的系统压塌了，你是最痛的，本着谁痛谁推动的原则，你也应该提前考虑好。

做降级

降级的方法，跟限流一样，比较简单。同样，今天我们也不会讲到如何具体怎么做降级。

从降级策略上来分析。

降级分为，人工降级、自动降级、暴力降级、柔性降级。

涉及到业务情况的，自动降级判断比较复杂，可以增加人工降级作为最后的确认。

涉及流量大小，接口调用超时等，可以直接自动降级。

暴力降级，比如商品评论的数量统计出现问题了，直接将商品评论功能关掉了。

柔性降级，则是我可以不显示评论数量，其它功能可以继续保留。

暴力和柔性，这里面涉及一个模块当时的设计实现方式，如果你不能很好的模块化，可能也实现不了局部降级。

最后一点。

切记：降级操作一定要进行提前演练，降级的实现方式一般都是通过开关的方式，也一般是通过硬编码到程序代码里面。如果时间较为久远，有可能这个地方的代码环境变了，或者是被其他人改动了，导致降级功能失效了，都是有可能的。因此，我们一定要提前进行演练。

降级与限流有明显的区别，前者依靠牺牲一部分功能或体验保住容量，而后者则是依靠牺牲一部分流量来保住容量。

----END----

这里记录，我每周碰到的，或想到的，引起触动，或感动的，事物的思考及笔记。不见得都对，但开始思考记录总是好的。

与爱学习、爱思考、爱记录的你共勉。

参考资料

吴俊龙 《容量保障核心技术与实战》https://time.geekbang.org/column/intro/100078501?tab=catalog