为什么要资源隔离
常见的资源，例如磁盘、网络、CPU等等，都会存在竞争的问题，在构建分布式架构时，可以将原本连接在一起的组件、模块、资源拆分开来，以便达到最大的利用效率或性能。
资源隔离之后，当某一部分组件出现故障时，可以隔离故障，方便定位的同时，阻止传播，避免出现滚雪球以及雪崩效应。
常见的隔离方式有:
线程隔离进程隔离集群隔离机房隔离读写隔离动静隔离爬虫隔离
等等
线程隔离
网络上很多帖子，大多是从框架开始聊的，这儿说人话其实就是对线程进行治理，把核心业务线程与非核心业务线程隔开，不同的业务需要的线程数量不同，可以设置不同的线程池，来举一些框架中应用的例子，例如Netty中的主从多线程、Tomcat请求隔离、Dubbo线程模型。
Netty主从程模型
主线程负责认证，连接，成功之后交由从线程负责连接的读写操作，大致如下代码：
EventLoopGroupbossGroup=newNioEventLoopGroup(1);EventLoopGroupworkerGroup=newNioEventLoopGroup();ServerBootstrapb=newServerBootstrap();b.group(bossGroup,workerGroup);
主线程是一个单线程，从线程是一个默认为cpu*2个数的线程池，可以在我们的业务handler中做一个简单测试：
publicvoidchannelRead(ChannelHandlerContextctx,Objectmsg){System.out.println("threadname="+Thread.currentThread().getName()+"serverreceivemsg="+msg);}
服务端在读取数据的时候打印一下当前的线程：
threadname=nioEventLoopGroup-3-1serverreceivemsg="..."
可以发现这里使用的线程其实和处理io线程是同一个；
Dubbo线程隔离模型
Dubbo的底层通信框架其实使用的就是Netty，但是Dubbo并没有直接使用Netty的io线程来处理业务，可以简单在生产者端输出当前线程名称：
threadname=DubboServerHandler-..1.:-thread-2,...
可以发现业务逻辑使用并不是nioEventLoopGroup线程，这是因为Dubbo有自己的线程模型，可以看看