亿级流量架构怎么做资源隔离？口琴这篇写得太好了！

作者：等不到的口琴

链接：www.cnblogs.com/Courage129/p/14421585.html

为什么要资源隔离

常见的资源，例如磁盘、网络、CPU等等，都会存在竞争的问题,在构建分布式架构时,可以将原本连接在一起的组件、模块、资源拆分开来,以便达到最大的利用效率或性能。资源隔离之后，当某一部分组件出现故障时，可以隔离故障，方便定位的同时，阻止传播，避免出现滚雪球以及雪崩效应。

常见的隔离方式有:

线程隔离

Netty主从程模型

EventLoopGroup bossGroup = new NioEventLoopGroup(1);
EventLoopGroup workerGroup = new NioEventLoopGroup();

ServerBootstrap b = new ServerBootstrap();
b.group(bossGroup, workerGroup);

主线程是一个单线程，从线程是一个默认为cpu*2个数的线程池，可以在我们的业务handler中做一个简单测试：

public void channelRead(ChannelHandlerContext ctx, Object msg) {
 System.out.println("thread name=" + Thread.currentThread().getName() + " server receive msg=" + msg);
}

服务端在读取数据的时候打印一下当前的线程：

thread name=nioEventLoopGroup-3-1 server receive msg="..."

可以发现这里使用的线程其实和处理io线程是同一个；

Dubbo的底层通信框架其实使用的就是Netty，但是Dubbo并没有直接使用Netty的io线程来处理业务，可以简单在生产者端输出当前线程名称：

thread name=DubboServerHandler-192.168.1.115:20880-thread-2,...

可以发现业务逻辑使用并不是nioEventLoopGroup线程，这是因为Dubbo有自己的线程模型，可以看看官网提供的模型图：

• all 所有消息都派发到线程池，包括请求，响应，连接事件，断开事件，心跳等。

• direct 所有消息都不派发到线程池，全部在 IO 线程上直接执行。

• message 只有请求响应消息派发到线程池，其它连接断开事件，心跳等消息，直接在 IO 线程上执行。

• execution 只有请求消息派发到线程池，不含响应，响应和其它连接断开事件，心跳等消息，直接在 IO 线程上执行。

• connection 在 IO 线程上，将连接断开事件放入队列，有序逐个执行，其它消息派发到线程池。

通过看源码可以知道,Dubbo默认使用的线程池是FixedThreadPool ，线程数默认为200 ；

Tomcat请求线程隔离

线程隔离小总结

进程隔离

进程隔离这种思想其实并不陌生,Linux操作系统中,利用文件管理系统将各个进程的虚拟内存与实际的物理内存映射起来,这样做的好处是避免不同的进程之间相互影响,而在分布式系统中,线程隔离不能完全隔离故障避免雪崩,例如某个线程组耗尽内存导致OOM,那么其他线程组势必也会受影响,所以进程隔离的思想是,CPU、内存等等这些资源也通过不同的虚拟机来做隔离。

具体操作是,将业务逻辑进行拆分成多个子系统(拆分原则可以参考:Redis集群拆分原则之AKF)，实现物理隔离，当某一个子系统出现问题，不会影响到其他子系统。

集群隔离

如果系统中某个业务模块包含像抢购、秒杀、存储I/O密集度高、网络I/o高、计算I/O高这类需求的时候，很容易在并发量高的时候因为这种功能把整个模块占有的资源全部耗尽，导致响应编码甚至节点不可用。

像上图的的拆分之后,如果某一天购物人数瞬间暴增,电商交易功能模块可能受影响,损坏后导致电商模块其他的浏览查询也无法使用,因此就要建立集群进行隔离,具体来说就是继续拆分模块,将功能微服务化。

解决方案

可以使用hystrix在微服务中隔离分布式服务故障。他可以通过线程和信号量进行隔离。

线程池隔离与信号量隔离对比

这儿同上面的线程隔离,不多赘述,简单叙述一下hystrix的两种隔离方式的区别:

隔离方式	是否支持超时	是否支持熔断	隔离原理	是否是异步调用	资源消耗
线程池隔离	支持，可直接返回	支持，当线程池到达maxSize后，再请求会触发fallback接口进行熔断	每个服务单独用线程池	可以是异步，也可以是同步。看调用的方法	大，大量线程的上下文切换，容易造成机器负载高
信号量隔离	不支持，如果阻塞，只能通过调用协议（如：socket超时才能返回）	支持，当信号量达到maxConcurrentRequests后。再请求会触发fallback	通过信号量的计数器	同步调用，不支持异步	小，只是个计数器

信号量隔离

说人话就是,很多线程涌过来,要去获得信号量,获得了才能继续执行,否则先进入队列等待或者直接fallback回调

最重要的是，信号量的调用是同步的，也就是说，每次调用都得阻塞调用方的线程，直到结果返回。这样就导致了无法对访问做超时（只能依靠调用协议超时，无法主动释放）

官网对信号量隔离的描述建议

理解下两点：

机房隔离

机房隔离主要目的有两个,一方面是将不同区域的用户数据隔离到不同的地区,例如湖北的数据放在湖北的服务器,浙江的放在浙江服务器,等等,这样能解决数据容量大，计算密集，i/o（网络）密集度高的问题,相当于将流量分在了各个区域。

另一方面,机房隔离也是为了保证安全性,所有数据都放在一个地方,如果发生自然灾害或者爆炸等灾害时,数据将全都丢失,所以把服务建立整体副本（计算服务、数据存储），在多机房内做异地多活或冷备份、是微服务数据异构的放大版本。

如果机房层面出现问题的时候，可以通过智能dns、httpdns、负载均衡等技术快速切换,让区域用户尽量不收影响。

数据读写隔离

通过主从模式，将mysql、redis等数据存储服务集群化，读写分离，那么在写入数据不可用的时候，也可以通过重试机制 临时通过其他节点读取到数据。

多节点在做子网划分的时候，除了异地多活，还可以做数据中心，所有数据在本地机房crud 异步同步到数据中心，数据中心再去分发数据给其他机房,那么数据临时在本地机房不可用的时候，就可以尝试连接异地机房或数据中心。

静态隔离

爬虫隔离

一是限流，限制访问的频率;

二是将爬虫请求转发到固定地方。

• 登录/会话限制
• 下载限流
• 访问频率
• ip限制，黑白名单

一种是：它用爬虫抓取公司主站B的内容并放到自己服务器上显示；

无论怎样，都要禁止这种行为的继续。有两种方法解决：

从nginx日志观察，访问者的代理IP经常变，但是访问UA却是固定的，因而可以禁止UA。

nginx不仅可以处理ua来分离流量，还可以通过更强大的openresty来完成更复杂的逻辑，实现一个流量网关，软防火墙。

感谢您的阅读，也欢迎您发表关于这篇文章的任何建议，关注我，技术不迷茫！小编到你上高速。

    · END ·

推荐阅读