浙江省建设厅官方网站信用平台,如皋网站开发公司,中企动力做网站的价格,建立一个网站 优帮云[每日一句] 也许你度过了很糟糕的一天#xff0c;但这并不代表你会因此度过糟糕的一生。 [背景介绍]
分布式系统的规模和复杂度不断增加#xff0c;随着而来的是对分布式系统可用性的要求越来越高。在各种高可用设计模式中#xff0c;【熔断、隔离、降级、限流】是经常被使…[每日一句] 也许你度过了很糟糕的一天但这并不代表你会因此度过糟糕的一生。 [背景介绍]
分布式系统的规模和复杂度不断增加随着而来的是对分布式系统可用性的要求越来越高。在各种高可用设计模式中【熔断、隔离、降级、限流】是经常被使用的。而相关的技术Hystrix本身早已算不上什么新技术但它却是最经典的技术体系。Hystrix以实现熔断降级的设计从而提高了系统的可用性。Hystrix是一个在调用端上实现断路器模式以及隔舱模式通过避免级联故障提高系统容错能力从而实现高可用设计的一个Java服务组件库。*Hystrix实现了资源隔离机制
请求合并的作用场景和原理 Hystrix请求合并用于应对服务器的高并发场景通过合并请求减少线程的创建和使用降低服务器请求压力提高在高并发场景下服务的吞吐量和并发能力 在正常的分布式请求中客户端发送请求服务器在接受请求后向服务提供者发送请求获取数据这种模式在高并发的场景下就会导致线程池有大量的线程处于等待状态从而导致响应缓慢同时线程池的资源也是有限的每一个请求都分配一个资源也是无谓的消耗了很多服务器资源在这种场景下我们可以通过使用hystrix的请求合并来降低对提供者过多的访问减少线程池资源的消耗从而提高系统的吞吐量和响应速度。 如下图采用请求合并后的服务模式 请求合并可以通过 构建类和添加注解的方式实现这里我们先说通过构建合并类的方式实现请求合并
请求合并的实现包含了两个主要实现类一个是合并请求类一个是批量处理类合并请求类的作用是收集一定时间内的请求将他们传递的参数汇总。*然后调用批量处理类通过向服务调用者发送请求获取批量处理的结果数据最后在对应的request方法体中依次封装获取的结果并返回回去
请求合并
可以在HystrixCommand之前放置一个『请求合并器』HystrixCollapser为请求合并器的抽象父类该合并器可以将多个发往同一个后端依赖服务的请求合并成一个。*Hystrix请求合并用于应对服务器的高并发场景通过合并请求减少线程的创建和使用降低服务器请求压力提高在高并发场景下服务的吞吐量和并发能力
下图展示了在两种场景未增加『请求合并器』和增加『请求合并器』下线程和网络连接数量假设所有请求在一个很小的时间窗口内例如 10ms是『并发』的
为什么要使用请求合并 在并发执行HystrixCommand时利用请求合并能减少线程和网络连接数量。 通过使用HystrixCollapserHystrix能自动完成请求的合并开发者不需要对现有代码做批量化的开发。 全局上下文适用于所有Tomcat线程 理想情况下合并过程应该发生在系统全局层面这样用户发起的由Tomcat线程执行的所有请求都能被执行合并操作。 例如 有这样一个需求用户需要获取电影评级而这些数据需要系统请求依赖服务来获取对依赖服务的请求使用HystrixCommand进行包装并增加了请求合并的配置这样当同一个JVM中其他线程需要执行同样的请求时 Hystrix会将这个请求同其他同样的请求合并只产生一个网络请求。 注意合并器会传递一个HystrixRequestContext对象到合并的网络请求中因此下游系统需要支持批量化以使请求合并发挥其高效的特点。 用户请求上下文适用于单个 Tomcat 线程 如果给HystrixCommand只配置成针对单个用户进行请求合并则 Hystrix 只会在单个 Tomcat 线程即请求中进行请求合并。 例如如果用户想加载 300 个视频对象的书签请求合并后Hystrix 会将原本需要发起的 300 个网络请求合并到一个。 对象模型和代码复杂度
很多时候当你创建一个对象模型适用于对象的消费者逻辑结果发现这个模型会导致生产者无法充分利用其拥有的资源。 例如这里有一个包含300个视频对象的列表需要遍历这个列表并对每一个对象调用getSomeAttribute()方法这是一个显而易见的对象模型但如果简单处理的话可能会导致300 次的网络请求假设getSomeAttribute()方法内需要发出网络请求每一个网络请求可能都会花上几毫秒显然这种方式非常容易拖慢系统。 当然你也可以要求用户在调用getSomeAttribute()之前先判断一下哪些视频对象真正需要请求其属性。
你可以将对象模型进行拆分从一个地方获取视频列表然后从另一个地方获取视频的属性。
但这些实现会导致API非常丑陋且实现的对象模型无法完全满足用户使用模式。 并且在企业级开发时很容易因为开发者的疏忽导致错误或者不够高效因为不同的开发者可能有不同的请求方式这样一个地方的优化不足以保证在所有地方都会有优化。
通过将合并逻辑下沉到Hystrix层不管你如何设计对象模型或者以何种方式去调用依赖服务又或者开发者是否意识到这些逻辑需要不需要进行优化这些都不需要考虑因为Hystrix能统一处理。
getSomeAttribute()方法能放在它最适合的位置并且能以最适合的方式被调用Hystrix 的请求合并器会自动将请求合并到合并时间窗口内。
请求合并带来的额外开销
请求合并会导致依赖服务的请求延迟增高该延迟为等待请求的延迟延迟的最大值为合并时间窗口大小。
若某个请求耗时的中位数是 5ms合并时间窗口为 10ms那么在最坏情况下注合并时间窗口开启时发起请求请求需要消耗 15ms 才能完成。通常情况下请求不太可能恰好在合并时间窗口开启时发起因此请求合并带来的额外开销应该是合并时间窗口的一般在此例中是 5ms。
请求合并带来的额外开销是否值得取决于将要执行的命令高延迟的命令相比较而言不会有太大的影响。同时缓存 Key 的选择也决定了在一个合并时间窗口内能『并发』执行的命令数量如果一个合并时间窗口内只有 1~2 个请求将请求合并显然不是明智的选择。
事实上如果单线程循环调用同一个依赖服务的情况下如果将请求合并会导致这个循环成为系统性能的瓶颈因为每一个请求都需要等待 10ms 的合并时间周期。
然而如果一个命令具有高并发度并且能批量处理多个甚至上百个的话请求合并带来的性能开销会因为吞吐量的极大提升而基本可以忽略因为 Hystrix 会减少这些请求所需的线程和网络连接数量。
请求合并器的执行流程 请求合并器的执行流程
请求缓存 在HystrixCommand和HystrixObservableCommand的实现中你可以定义一个缓存的 Key这个Key用于在同一个请求上下文全局或者用户级中标识缓存的请求结果当然该缓存是线程安全的。 下例展示了在一个完整 HTTP 请求周期内两个线程执行命令的流程 请求缓存例子
请求缓存有如下好处
不同请求路径上针对同一个依赖服务进行的重复请求有同一个缓存 Key不会真实请求多次 这个特性在企业级系统中非常有用在这些系统中开发者往往开发的只是系统功能的一部分。注这样开发者彼此隔离不太可能使用同样的方法或者策略去请求同一个依赖服务提供的资源
例如请求一个用户的Account的逻辑如下所示这个逻辑往往在系统不同地方被用到
Account account new UserGetAccount(accountId).execute();Observable accountObservable new UserGetAccount(accountId).observe();
复制代码Hystrix的RequestCache只会在内部执行run()方法一次上面两个线程在执行HystrixCommand命令时会得到相同的结果即使这两个命令是两个不同的实例。
数据获取具有一致性
因为缓存的存在除了第一次请求需要真正访问依赖服务以外后续请求全部从缓存中获取可以保证在同一个用户请求内不会出现依赖服务返回不同的回应的情况。
避免不必要的线程执行 在construct()或run()方法执行之前会先从请求缓存中获取数据因此Hystrix 能利用这个特性避免不必要的线程执行减小系统开销。 若Hystrix没有实现请求缓存那么HystrixCommand和HystrixObservableCommand的实现者需要自己在construct()或run()方法中实现缓存这种方式无法避免不必要的线程执行开销。 分享资源
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9sEg6B06-1691457511837)(https://pic.imgdb.cn/item/64d0dc6a1ddac507cc857b30.png)] 获取以上资源请访问开源项目 点击跳转
