高可用设计之隔离策略

1、静态资源隔离

以商品详情页为例，详情页面由html、js、css、image、font以及后端接口等内容组成，如果这些静态资源与后端服务都在同一个系统当中，那么很可能因为大量访问导致带宽打满，导致服务不可用。所以应该把静态资源放到CDN上，而且CDN有更好的访问速度，以就近访问原则，用户访问离自己最近的节点，响应更快速

2、线程隔离

一个服务里边，肯定有核心接口与非核心接口，核心接口一般是指影响主流程，影响面大的接口，这类接口定义为核心接口，一定是要保证高可用的。另一类例如说获取用户勋章之类的接口，相对没那么核心，哪怕失败或者超时，也不会造成非常恶劣的影响。

但是如果所有的接口请求都在同一个线程池处理，那么非常有可能非核心接口的超时，会导致核心接口不可用，占满整个线程池资源，导致服务假死。在这类场景下，同个服务内，一定要将接口分类处理，将不同类接口，划分到不同的线程池处理。更彻底的做法是拆分子系统，这个后面会介绍。

3、读写分离

从互联网项目的业务场景来看，大部分的业务场景都是读多写少，例如直播业务中的进房的操作，实际上就是从服务端获取直播间信息，公屏等相关信息，这几个场景都是读操作。

当遇到明星直播的时候，带来大量粉丝，大量粉丝进房需要获取直播间和公屏相关内容，就会对Redis造成非常大的读压力。此时需要将读的压力分散到各个从节点，以保证Redis的可用性，这是最基本的做法。另一方面也需要根据业务场景做本地缓存，尽可能让数据存储在本地内存中，不让请求打到Redis，会很有效的保护存储，只要注意好数据一致性问题即可。

4、服务拆分

创业初期的项目，为了快速上线，快速推出市场，一般情况下，都是做大而全的项目，几乎所有的业务都在同一个服务中，这在项目初期，初期量少的阶段，能够快速提高效率。

当业务持续发展，有了一定体量、QPS上来之后，大而全的项目缺点就会逐步暴露出来，一旦某个边缘模块出现Bug或者内存泄漏等问题，甚至OOM，就会导致整个项目不可用。为了解决这类问题，就需要进行服务的拆分，将大而全的项目，按照业务领域，根据DDD设计思想，将业务拆成不同的子项目，由子项目单独提供服务，量大的项目独立扩容，这样在一定程度上就避免了业务的相互影响，提高系统的可用性。

5、资源隔离

部署在Linux机器上的服务，都会占用机器的资源，这里的资源包括CPU、磁盘、网络等，如果这台机器上部署了5个服务，其中一个服务由于配置不当或者请求量激增，占用了几乎全部的CPU资源，或者日志量大，导致了非常大的IO操作阻塞磁盘，又或者网卡流量被打满。剩下的其余服务，会受到非常大的影响，导致别的服务不可用。

所以在部署项目的时候，就需要考虑资源隔离的问题，从大到小依次为：跨机房->跨机柜->跨交换机->跨机器，这其实很好理解，跨机房为了避免单机房故障导致的故障，跨机柜避免单个机柜出现问题，跨交换机为了解决交换机故障导致一批机器不可用，跨机器就更好理解了，一个服务至少要两个实例且不能在同一台机器。也可以考虑使用K8S来解决服务扩缩容以及资源隔离等问题。

真实机房部署环境中，有可能同一路电力下有多个机柜甚至整个机房都是同一路电力，那么电力的故障也会导致非常大的影响，所以机房内也需要考虑备用电源。

6、流量隔离

在对外的WEB服务中，无时不刻都在被爬、被刷，线上的各路搜索引擎都在爬取收录网站的内容，这一类请求一般情况下都有一些UserAgent的标志，可以通过UA将流量分离出去，避免影响正常业务，另一类恶意被刷内容，可以在Nginx等入口层将恶意请求拒绝掉，避免打垮服务。