概念：本质上对系统或资源进行分割，从而实现当系统发生故障时能限定传播范围和影响范围，即发生故障后只有出问题的服务不可用，保证其他服务仍然可用。
隔离类别大体可分为三大类
一、服务隔离
动静分离、读写分离（CQRS：https://zhuanlan.zhihu.com/p/115685384）
二、轻重隔离
核心、快慢、热点
三、物理隔离
线程、进程、集群、机房
动静隔离
小到CPU的cacheline false sharing、数据库MySQL表设计中避免BufferPool频繁过期，隔离动静表，大到架构设计中的图片、静态资源等缓存加速。本质上都体现一样的思路，即加速/缓存访问变换频次小的。比如CDN场景中，将静态资源和动态API分离，也体现了隔离的思路。
- 降低应用服务器负载，静态文件访问负载全部通过CDN
- 对象存储费用低
- 海量存储空间，无需考虑架构升级
- 静态CDN带宽加速，延迟低
例如日志上报，高并发时也可以通过CDN汇集回传到源服务器
服务隔离
将高频访问的字段隔离，MySQL BufferPool是用于缓存DataPage的，DataPage可以理解为缓存表中的行，如果频繁更新DataPage会不断置换，会导致命中率下降的问题，所以在表设计中，仍可以严重类似的思路，其主表基本更新，在上游Cache命中，穿透到MySQL，让然有BufferPool缓存。
- 读写分离：主从、Replicaset、CQRS
轻重隔离
- 核心隔离：业务按照level进行资源池划分
- 核心/非核心的故障域的差异隔离（机器资源、依赖资源）
- 多集群，通过冗余资源来提升吞吐和容灾能力
- 快慢隔离
在日志传输体系的架构设计中，整个流都会投放到一个Kafka topic中，流内会区分不同的logid，logid会有不同的sink端，它们会出现速差，比如HDFS抖动吞吐下降，ES正常水位，全局数据就会整体反压。
按照各种维度隔离：sink、部门、业务、logid、重要性
业务日志也属于某个logid，日志等级就可以作为隔离通道。
- 热点隔离
热点即经常访问的数据，很多时候我们希望统计某个热点数据中访问频次最高的TopK数据，并对其访问进行缓存。比如- 小表广播：从remotecache提升为localcache，app定时更新，甚至可以让运营平台支持广播刷新localcache
- 主动预热：比如直播房间页高在线情况下，bypass监控主动防御
物理隔离
账号多活
-
进程隔离
容器化（docker）
容器编排引擎（k8s）
应用托管、在线应用弹性公有云、离线yarn、在线k8s、弹性公有云配合自建IDC做到离线混合云架构 -
集群隔离
多集群方案，即逻辑上是一个应用，物理上部署多个应用，通过cluster区分 -
线程隔离
主要通过线程池进行隔离，也是实现服务隔离的基础。把业务进行分类交给不同的线程池进行处理，当某个线程池处理一种请求服务发生问题时，不会将故障扩散和影响到其他线程池，保证服务可用。
对于go来说，所有IO都是Non-Blocking（非阻塞），且托管给了Runtime，只会阻塞Goroutine，不阻塞M（即工作线程OS thread），我们只需要考虑Goroutine总线控制，不需要线程模型语言的线程隔离。
Case
- 转码集群被超大集群攻击，导致大量转码延迟（可用轻重隔离，视频处理可分为大、中、小视频，同时做垃圾视频处理）
- 缩略图服务，被大图实时缩略耗尽所有的CPU，导致正常的小图503（可使用大、小图压缩处理隔离）
- INFO日志量过大，导致ERROR日志采集延迟（可使用日志等级进行隔离，由不同Kafka Topic消费）