低调的牛肉

我们现在的系统，最开始只面向内网系统，这种情况下，访问量都不是特别的大并且比较平稳，最近开始接了一些互联网区的系统，访问量一下子上来了，所以也不得不考虑这方面的问题。

首先要说明，我们公司虽然也号称上了云，但是基本上还是基础的IasS这个级别，并没有PasS，也没有容器管理平台什么的，所以网上说的那些自动的流量监控、自动扩容缩容什么的，我们并没有使用过；所以针对这种情况，基本上还是一些土办法。

流量估算

什么系统会调用？这些系统的使用用户是谁？每日调用量是多少？高峰期预计是多少？

每个公司的情况可能不太一样，我们公司也成了好多年了，这些数据参考之前的产品/活动/需求基本上可以评估个大概范围，比如一个业务场景下，每天大概会有10万的调用量，在开发、压力测试和生产资源申请的过程中，就按照（评估数量*N）的一个值进行估量。

如果是小公司的话，或者某个业务场景是第一次上，那么这个数量是比较难估计的，这时候只能猜一个数量，不过就算是猜的，也比没有强。

缓存

请求过来，基本的过程就是解析入参、查询DB、加工处理、返回参数，需要使用的资源包括：网络带宽、CPU、内存、磁盘IO等；如果请求量增加，总会有一个资源会遇到瓶颈，通常来看，最容易产生瓶颈的是磁盘IO，基本上是数据库的磁盘IO。

使用缓存，就是为了减少数据库的压力，避免在请求量突然增多的时候，数据库崩掉从而导致整个项目的瘫痪。

缓存也可以分成多级，包括客户端（浏览器）缓存、CDN、服务器级别的缓存（内存式缓存、分布式缓存）；

限流

限制用户的请求流量，例如使用计数器、页面设置多次提交的间隔时间、滴漏、请求排队等。

我们系统本身没有做什么限流措施，完全是依赖于API Gateway来做这些功能的；

有些项目甚至是这样做的，一个接口ABC三个系统都要调用，AB系统比较关键并且调用量稳定，C系统要求没那么高但是调用量比较大，那么接口被部署成两套环境，一套给AB系统使用，一套给C系统使用（数据库也使用备库），前者保证其稳定性，后者嘛...也会保证其稳定性，但是如果万一挂掉的话，至少不会影响到AB系统的使用。

服务降级

我认为这种方法在真实的业务场景中，是比较难实现的，不是说技术上不好做，而是业务上比较难操作。

通常服务降级不是IT说降就降的，这得业务（用户）说了算才行；就算是降级，也只能降那些不太重要的功能（接口），降级后页面显示成什么样子，接口返回什么内容，这些都是要提前设计好的；如果是关键性的功能（接口），是没有降级可能的。

希望我的回答，能够帮助到你！我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。

会点代码的大叔

对于软件系统而言，若特定时间段内流量暴增，那软件系统及相关API的性能瓶颈立马就会表现出来，服务器资源被占满，随之导致服务及系统不可用。所以我们要在系统架构时充分考虑到洪峰带来的性能压力，以达到“三高架构”。

什么是“三高架构”

架构领域所说的“三高”是指：

• 高并发：并行处理的请求越多则代表并发越高；
  

• 高性能：服务性能好，响应处理速度快；

• 高可用：服务不可用的时间短、或基本没有。

API接口如何应对暴增的流量？

如何使我们的API达到“三高”呢？可以通过一些技术方案来实现，我这里整理了一些以供大家参考：

1、合理的缓存设计

在API层提缓存，很多人就觉得API不应该加缓存，因为大多数接口数据对实时性都是有要求的，但这里说的缓存主要是指借助内存来缓解DB层的查询（因为内存读写速度比硬盘读写速度快得多）。

要知道，API的数据来源主要是从数据库中查询出来的，所以在流量洪峰时，所有的流量都会打到DB层，这样数据库的查询压力很大。我们建议在用Redis等NoSQL产品来同步一份热点数据，API直接从Redis中取数据，取不到数据再从DB层查询。

2、数据库主从同步、读写分离

单一的数据节点在高并发场景下是抗不住的，所以需要做主从同步+读写分离。读从库，写主库，能有效避免主服务器出现性能瓶颈、降低阻塞、并发能力提升。

3、服务限流

当系统资源无法应对大量请求时，为保证有限资源能正常使用，我们就需要就需要按照一定策略对服务做限流处理。

其实很好理解，举例说明一下：每逢假期热门景点就是人山人海，所以这些景区的门票都会做限制，防止人员过多导致隐患发生。

服务限流有很多种模式，在架构领域常见的有：

• 熔断：当服务出现问题若短时间内无法修复，则开启熔断，拒绝访问，避免大流量请求对后端造成的过载压力；然后系统能实时监测服务的修复情况，一旦服务正常后，就自动关闭熔断，恢复服务。

• 服务降级：一个大型系统会涉及很多服务，有些重要，有些不重要。当服务器负载严重时，可以对不重要的服务进行降级处理（即：停止服务），将资源回收提供给核心业务去使用。像电商平台每次做活动时，一些非核心业务都会临时关闭，这就是服务降级。

• 队列处理：我们可以将所有的请求放置在一个“队列池”里，后端服务从这个“队列池”中依次取出请求进行处理，这种排队机制很大程度缓解了后端服务器的压力，只不过它也带来一些延迟。

4、动态扩容

以硬件的扩容来应对大流量冲击，像现在的容器化部署都可以做到弹性扩容，当资源不够时秒级扩容。

网络圈

对于开发人员来说，在开发接口时是需要考虑高并发的情况的，在开发时要尽量优化代码提升接口性能，采用缓存机制以降低对数据库的操作；接口需要进行压力测试，并且将测试结果作为接口指标，在实际业务场景中，可以通过日常检测提前预估接口的访问情况，及时对服务器作出调整和扩容，以应对高并发的情况。

对于突然性的并发访问，可以采用流量限制的方式，通过对线程、数据库连接数等进行限制从而降低服务器的压力，如果是在分布系统中，也可以采用消息队列的模式，通过消息队列作为缓冲削弱访问压力；或者采用页面静态化的方式，将一些信息动态生成html页面，通过访问html页面降低对数据库的访问、提升效率；也可以搭建服务器集群，通过集群的图片分离、负载均衡等方式来分散访问压力，提升访问效率。

關鍵字: 系统 访问量 接口