高可用服务架构设计(9) - 基于Hystrix的信号量技术对地理位置获取逻辑进行资源隔离与限流
2019-07-14 18:20
525 查看
版权声明:署名,允许他人基于本文进行创作,且必须基于与原先许可协议相同的许可协议分发本文 (Creative Commons)
1 线程池隔离 VS 信号量隔离
Hystrix里面,核心的一项功能,就是资源隔离,要解决的最核心的问题,就是将多个依赖服务的调用分别隔离到各自自己的资源池内
避免对某一个依赖服务的调用,因为依赖服务的接口调用的延迟或者失败,导致服务所有的线程资源全部耗费在这个服务的接口调用上
一旦某个服务的线程资源全部耗尽,可能就会导致服务崩溃,故障甚至还会蔓延
Hystrix实现资源隔离,两种技术
- 线程池的资源隔离
- 信号量的资源隔离
信号量,semaphore
信号量跟线程池,两种资源隔离的技术,区别到底在哪儿呢?
- 线程池隔离和信号量隔离的原理以及区别
2 适用场景
2.1 线程池
适合绝大多数的场景,99%的,线程池,对依赖服务的网络请求的调用和访问,timeout这种问题
2.2 信号量
适合访问不是对外部依赖的访问,而是对内部的一些比较复杂的业务逻辑的访问,但像这种访问,系统内部的代码,其实不涉及任何的网络请求,那么只要做信号量的普通限流就可
因为不需要去捕获timeout类似的问题,算法+数据结构的效率不是太高,并发量突然太高,因为这里稍微耗时一些,导致很多线程卡在这里的话,不太好,所以进行一个基本的资源隔离和访问,避免内部复杂的低效率的代码,导致大量的线程被hang住
- 信号量的资源隔离与限流的说明
3 实践本地内存获取地理位置数据的逻辑
业务背景里面, 比较适合信号量的是什么场景呢?
比如缓存服务,可能会将部分量特别少,访问又特别频繁的一些数据,放在纯内存
一般我们在获取到商品数据之后,都要去获取商品是属于哪个地理位置,省,市,卖家的
可能在自己的纯内存中,比如就一个Map去获取.对于这种直接访问本地内存的逻辑,比较适合用信号量做一下简单的隔离
优点在于,不用自己管理线程池,不用担心超时,信号量做隔离的话,性能会相对来说高一些
4 采用信号量技术对地理位置获取逻辑进行资源隔离与限流
super(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("ExampleGroup")) .andCommandPropertiesDefaults(HystrixCommandProperties.Setter() .withExecutionIsolationStrategy(ExecutionIsolationStrategy.SEMAPHORE)));
参考
- 《Java工程师面试突击第1季-中华石杉老师》
X 交流学习
Java交流群
博客
Github
相关文章推荐
- 微服务架构实战,基于dubbo和springcloud实战大揭秘,分布式,高并发,高可用,高负载,互联网技术
- 高可用服务架构设计(16) - 基于timeout机制来为商品服务接口的调用超时提供安全保护
- 高可用服务架构设计(10)-Hystrix的线程池+服务+接口划分以及资源池的容量大小控制
- 微服务架构:基于微服务和Docker容器技术的PaaS云平台架构设计(微服务架构实施原理)
- 基于地理位置服务(LBS)技术平台
- 微服务架构:基于微服务和Docker容器技术的PaaS云平台架构设计(微服务架构实施原理)
- 高可用服务架构设计(14) - 深入理解hystrix的断路器执行原理以及模拟接口异常时的短路实验
- Python2.7基于淘宝接口获取IP地址所在地理位置的方法【测试可用】
- 微服务架构:基于微服务和Docker容器技术的PaaS云平台架构设计(微服务架构实施原理)
- 架构设计需要进行【服务隔离】
- 为什么架构设计要进行服务隔离?
- 基于即时通信和LBS技术的位置感知服务(二):XMPP协议总结以及开源解决方案
- 高可用架构设计---微服务
- Linux 高可用(HA)集群之heartbeat基于crm进行资源管理详解(二)
- Spring Cloud构建微服务架构Hystrix依赖隔离
- [原创]WCF技术剖析之三:如何进行基于非HTTP的IIS服务寄宿
- 基于微服务API级权限的技术架构
- 基于Dubbo的分布式系统架构-使用Dubbo进行规模服务化前的工程结构优化
- Web服务搜索与执行引擎(四)——基于(三)的系统架构设计
- 基于即时通信和LBS技术的位置感知服务(三):搭建Openfire服务器+测试2款IM客户端