系统冰火两重天--如何做好“系统资源隔离”？

前言

最近在研究系统之间的优化措施，如何保证系统各个服务在高并发、大流量的情况下，遇到突发问题，能够最大限度的减少影响，柔性可用。今天主要介绍一下，如何做系统隔离。

常见的“隔离”方案

其实谈到“隔离”，这个概念并不陌生，大家时时刻刻都能体会到，比如操作系统各个进 程之间也做了隔离，你在使用word，word突然崩溃关闭了，不会影响你正在听的音乐。数据事务之间也有隔离特性。
在互联网大流量的催化下，常见的隔离方案比如hytrix提供的线程池隔离、信号量隔离，从硬件层面，部署隔离（不同集群之间隔离），还有另外就是单元化（不过单元化，不是主要做隔离的，这个后续再说）。

线程池 与 信号量 隔离

线程池与信号量隔离，其实主要是利用Hytrix的线程池 和 信号量隔离的方式。这里我们主要介绍他们的隔离思想，hytrix的使用，网上一大把的文章，大家可以去看。

如下图：
商品系统提供通用查询接口1，为业务系统提供查询服务，如何保证业务系统1、业务系统2、业务系统n 之间不受影响呢？

商品系统接口1提供通用查询能力，但是业务系统1 和 业务系统2 需要的数据不同，有的可能只要个价格，有的可能需要20+字段的消息，开销也不一样，还有的业务系统n 可能重要性大一些。
在目前不受改造的情况下，业务系统1，2，n之间因为共享这个接口的资源，互相之间会受影响。当然也可以考虑拆接口，但是不在我们这个讨论范围之内。

用线程池隔离的改造方案：

改造后，针对不同业务系统所要查询的业务可以用线程池隔离开来，同时可以单独配置线程池资源，这样即使业务A的流量过高，也可以通过线程池控制业务A的线程资源，不至于业务A的过高流量影响其他业务。
注意：这里是通过业务进行线程池划分。也可以通过上游系统，比如业务系统1 和业务系统2，不同的业务系统带不同的标记，创建线程池。

用信号量隔离方案

信号量方案，就是针对不同业务指定一定数量的信号量，不同业务不一样，根据业务特性决定，当请求获取信号量就执行，否则，就拒绝，达到资源隔离的目的。

关于两者优劣，我们做个简要的对比：

线程池隔离	信号量隔离
线程：与调用线程非相同线程，需要额外创建线程池，有资源开销	线程 ：与调用线程相同，无额外开销
原理：每个业务单独的线程池	原理 ：信号量计数器
开销：任务排队、调度、线程上下文切换	开销 ：无线程上下文切换
异步：支持	异步 ：不支持
并发：支持，线程池大小	并发：支持，信号量大小
超时：支持超时	超时：不支持超时

部署隔离

这种方式也比较常用，用线程池或者信号量隔离，毕竟服务部署在同一台服务器上，很多时候，会受同一台物理机器的影响。

上面没有考虑商品系统还有诸多下游的情况，如果考虑的话，可能还需要对下游的部署进行染色、引流，这里就不做介绍了。

单元化

单元化的概念比较大，单元化可以解决隔离问题，但它不仅仅是解决隔离问题。这里简单介绍一下，后续再写文章详细介绍。
其实单元化主要解决的问题是：1.容灾，跨地域备份。 2. 服务体量大，单一IDC满足不了诉求。3.流量隔离，故障隔离。
这里不做过多介绍，大家也可以了解一下。

总结

这里主要介绍了互联网常用的隔离方式，大家有问题可以随时留言，与我沟通交流～