线程池隔离
线程池隔离，同样是用于解决部分接口耗时长的一种方式。如果服务器开启 500 个线程处理请求，有可能因为某个接口处理耗时长 & 调用量大，进而占用所有的线程，进而影响其他本来耗时不长的接口。为此，使用线程池隔离，为不同类 or 计算程度 or RPC 调用准备一个小线程池，从而避免突发的高并发+部分接口处理时间增加，阻塞其他接口。
又或者用于隔离不同的处理逻辑，一个进程中三个线程池，分别负责订单任务、支付任务和配送任务。
机器隔离/调用者隔离/进程隔离
部分接口耗时长：对于一个服务来说，专门为最核心的调用者准备一组机器，从而避免其他调用者的长请求影响核心调用者的服务。比如，有些请求可能会耗费很多 CPU 时间，那么可能会占用 CPU 较长时间，从而影响其他核心但是占用 CPU 时间不多的调用方。
新增接口：又或者，本来是一个核心服务，因为某种原因增加了新功能/新接口，仅仅提供给某个调用方使用，可以将调用方隔离出来，不影响现有的功能。
成熟的 RPC 框架往往有隔离功能，根据调用方的标识（ID），把来自某个调用方的请求都发送到一组固定的机器中，无须业务人员写代码，用一个简单的配置即可搞定。
系统隔离：每个内外网服务都会部署在独立的集群内，同时每个项目都拥有自己的网关和数据库。而外网服务和内网必须通过网关才能访问，外网向内网同步数据是用 Kafka 来实现的。
网关隔离：外网调用内网的接口必须通过内网网关。外网请求内网接口时，内网网关会对请求的来源系统和目标接口进行鉴权，注册授权过的外网服务只能访问对其授权过的内网接口，这样可以严格管理系统之间的接口调用。
资源隔离
数据隔离：根据数据重要性、业务情况等，将数据所在的物理库彻底分开。
K8S 的 CPU、memory、GPU 的隔离，一个 pod 故障、OOM，不会影响其他 pod 的运行。
信号量隔离
信号量隔离是 Hystrix 提出的另外一种隔离方法，它比线程池隔离要轻量。一个机器能开的线程数是有限的，线程池太多会导致线程太多，线程切换的开销会很大。而使用信号量隔离不会额外增加线程池，只在调用线程内部执行。信号量在本质上是一个数字，记录了当前访问某个资源的并发线程数。在线程访问资源之前获取该信号量，当访问结束时，释放该信号量。一旦信号量达到最大阈值，线程获取不到该信号量，会丢弃请求，而不是阻塞在那里等待信号量。
同样，阿里巴巴公司的 Sentinel 也提供了并发线程数模式的限流，其实也是一种隔离手段，其原理和 Hystrix 的信号量类似，同时还可以结合基于响应时间的熔断降级。
其他隔离
机房隔离、集群隔离、虚拟机隔离…