浅尝服务，过载保护

浅尝服务过载保护

    首先，我们要对过载保护做一个简单的了解和认识。
    功能和过载保护类似的还有柔性服务。有些人也叫作有损服务。我谈一下自己对于过载保护的简单理解吧！在我看来过载保护有两个重要的点，一个是不要被别人拖垮了。一个是认怂。
    首先，说一下什么叫做过载。所谓的过载就是超出了服务本身的服务能力。达到服务运行的瓶颈了，用户体验已经崩溃了。这里举点例子来说说明过载的情况吧！

1. 07年售卖北京奥运会的门票时间
2. 各大城市的汽车拥堵情况，堵车十分严重。

    我们来说说保护，对于汽车拥堵的情况我们做了一个简单的处理，就是限号。这个一下子，感觉路上的车少了很多都不堵车了。简直不要太赞哈！
    那么对我们的Web服务或者站点的服务过载该是怎么一个情况呢？简单来说，后端系统的可以每秒接受100000请求，然后延时大家可以接受，同时CPU负载和内存都是正常的。那么当我们的网站搞了一个运营活动或者类似双十一的活动的时候。流量就别堆积在那几分钟甚至于在几秒钟的时候。我们的系统可能就不能正常工作了。 那么这个时候我们该怎么办呢？
首先，我们这里给出一种常用的模型。也就是服务请求处理的模型。

     这里有很多的请求进入我们的请求队列。然后分发给相应的线程来处理。我们这里一个线程同一时刻只可以处理同一个请求。处理完了然后才会释放线程，然后处理下一个请求。那么一下子来了20万请求，我们该怎么办呢？如果都进入到服务端。恐怕服务端就直接宕机卡死了吧！
       虽然，服务请求超过我们服务器的负载能力，有可能会发生这种宕机的情况。但是，我们发现其实并不是我们所有的接口请求量都是一样的。如果真个服务挂掉就不是很友好对吧！上图中的service是一个线程池，用于处理所有的请求。这个时候如果有个一请求量非常大，而且容易耗时的话。那么我们大多数的线程就可能会被这个一个接口所占据。这是一种很常见的情况。当然了还有一种就是正常流量上升。用户量暴增。因为，我们给用户发红包了！
    这里我们每一个请求都是需要单独一个线程去处理的。所以如果部分的接口访问量突增，比如被刷接口了。比如某些热点数据。这种情况下，会有部分的接口量突增。我们假设目前线程池里面有1024个线程在处理所有的请求。如果某一个接口的调用量突增。就可能会出现一种情况，大部分的线程池，都被同一种请求打满了。这种情况下，我们就会发现除了这个接口意外的其他接口都不可用了或者返回都十分的缓慢。我们是不可以忍受的。那么问题怎么解决呢。
    这种情况不仅仅会在调用突增的时候出现，当某一个接口返回时间很长的时候，也会发生这种情况的。一般会有以下的处理方法

• 做资源隔离，禁止某个请求占用大量的线程资源。
• 接口随机的进行直接返回操作

    过载保护其实并不是什么神奇的事情，主要应对上方流量突增的情况。这里过载保护一般只是少量接口，突然爆发大量请求。后面会有其他的部分问题讲解，比如下层出现调用超时，保证自己的服务可用。会提及服务降级和熔断策略。其实无论是过载保护还是熔断降级都是为了服务的高可用可用性考虑的。