hystrix

序 本文主要研究一下HystrixPropertiesStrategy HystrixPropertiesStrategy hystrix-core-1.5.12-sources.jar!/com/netflix/hystrix/strategy/properties/HystrixPropertiesStrategy.java /** * Abstract class with default implementations of factory methods for properties used by various components of Hystrix. * <p> * See {@link HystrixPlugins} or the Hystrix GitHub Wiki for information on configuring plugins: <a * href="https://github.com/Netflix/Hystrix/wiki/Plugins">https://github.com/Netflix/Hystrix/wiki/Plugins</a>. */ public abstract class HystrixPropertiesStrategy { /** * Construct an implementation of {@link

壹 工作中的微服务架构,某个服务通常会被多个服务调用或者多层调用完成需求,如果某个服务不可用,导致一个系统功能不可用或者服务直接没用了的情况,这种情况称为雪崩效应 有A服务调用B服务,B服务调用C服务,如果B服务调用C服务出了问题,那么B服务会一直重试,等待会将资源耗尽,结果B服务也不可用,导致A服务调用B服务的时候,也出问题,这样的话,ABC服务都瘫了 为预防以上问题,在下面学习Spring Cloud Hystrix,防雪崩,容错机制,基于NetFlix的Hystrix Hystrix翻译中文是豪猪的意思,没见过也知道防御力很高的样子,还有之前学习的Eureka翻译中文的意思是找到了,就是后来词化成发现 Hystrix 供分布式系统使用，提供延迟和容错功能，隔离远程系统、访问和第三方程序库的访问 贰 Spring Cloud Hystrix ①服务降级 ②服务熔断 ③依赖隔离 ④监控(Hystrix Dashboard) 根据以上特性功能开始学习 服务降级 这个功能其实我们平时也都见过,比如访问某宝页面抢购,某奇艺看东西会提示: 网络开小差了,请稍后再试 等类似的提示 服务降级主导思想是区分业务,详细体现在优先核心服务,非核心服务不可用或放低其可用度,就有一种弃车保帅的意思,舍小保大 假设一个电商系统,某天的交易有巨大的流量出现,摆好的服务器资源就这么多,那么优先保证商品、订单

　　概述 　　毫无疑问，Spring Cloud是目前微服务架构领域的翘楚，无数的书籍博客都在讲解这个技术。不过大多数讲解还停留在对Spring Cloud功能使用的层面，其底层的很多原理，很多人可能并不知晓。因此本文将通过大量的手绘图，给大家谈谈Spring Cloud微服务架构的底层原理。 　　实际上，Spring Cloud是一个全家桶式的技术栈，包含了很多组件。本文先从其最核心的几个组件入手，来剖析一下其底层的工作原理。也就是Eureka、Ribbon、Feign、Hystrix、Zuul这几个组件。 　　一、业务场景介绍 　　先来给大家说一个业务场景，假设咱们现在开发一个电商网站，要实现支付订单的功能，流程如下： 　　创建一个订单后，如果用户立刻支付了这个订单，我们需要将订单状态更新为“已支付” 　　扣减相应的商品库存 　　通知仓储中心，进行发货 　　给用户的这次购物增加相应的积分 　　针对上述流程，我们需要有订单服务、库存服务、仓储服务、积分服务。整个流程的大体思路如下： 　　用户针对一个订单完成支付之后，就会去找订单服务，更新订单状态 　　订单服务调用库存服务，完成相应功能 　　订单服务调用仓储服务，完成相应功能 　　订单服务调用积分服务，完成相应功能 　　至此，整个支付订单的业务流程结束 　　下图这张图，清晰表明了各服务间的调用过程： 　　好!有了业务场景之后

序 本文主要研究一下HystrixThreadPool HystrixThreadPool hystrix-core-1.5.12-sources.jar!/com/netflix/hystrix/HystrixThreadPool.java /** * ThreadPool used to executed {@link HystrixCommand#run()} on separate threads when configured to do so with {@link HystrixCommandProperties#executionIsolationStrategy()}. * <p> * Typically each {@link HystrixCommandGroupKey} has its own thread-pool so that any one group of commands can not starve others from being able to run. * <p> * A {@link HystrixCommand} can be configured with a thread-pool explicitly by injecting a {@link HystrixThreadPoolKey} or via the * {@link

问题 Task java.util.concurrent.FutureTask@27d69e27 rejected from java.util.concurrent.ThreadPoolExecutor@61d1c14e[Running, pool size = 10, active threads = 10, queued tasks = 0, completed tasks = 62058] 问题原因 并发数过大，超过了线程池线程的处理能力； 线程池未启用缓冲队列； 排查 hystrix配置 hystrix: threadpool: default: coreSize: 10 配置项 说明 coreSize 核心线程数：10 default 说明配置的所有的feigin client hystrix 官方配置 配置项 默认值 说明 maxQueueSize -1， 默认不开启缓冲区；设置为-1，那么使用SynchronousQueue BlockingQueue的最大队列数 coreSIze 10 工作线程数，同Java线程池 maximumSize 10 线程池最大值 queueSizeRejectionThreshold 5 缓冲区拒绝服务阈值，如缓冲区为100，阈值为80.则达到80的话，缓冲区就不允许写入了 keepAliveTimeMinutes 1 设置存活时间

SpringCloud微服务学习笔记 项目地址： https://github.com/taoweidong/Micro-service-learning 单体架构(Monolithic架构) Monolithic比较适合小项目 单体架构优点： 开发简单直接，集中式管理, 基本不会重复开发功能都在本地，没有分布式的管理开销和调用开销。 单体架构缺点： 开发效率低：所有的开发在一个项目改代码，递交代码相互等待，代码冲突不断 代码维护难：代码功能耦合在一起，新人不知道何从下手 部署不灵活：构建时间长，任何小修改必须重新构建整个项目，这个过程往往很长 稳定性不高：一个微不足道的小问题，可以导致整个应用挂掉 扩展性不够：无法满足高并发情况下的业务需求 微服务架构 ​ 微服务是指开发一个单个小型的但有业务功能的服务，每个服务都有自己的处理和轻量通讯机制，可以部署在单个或多个服务器上。微服务也指一种种松耦合的、有一定的有界上下文的面向服务架构。也就是说，如果每个服务都要同时修改，那么它们就不是微服务，因为它们紧耦合在一起；如果你需要掌握一个服务太多的上下文场景使用条件，那么它就是一个有上下文边界的服务，这个定义来自DDD领域驱动设计。 ​ 微服务架构模式（MicroservicesArchitecture Pattern）的目的是将大型的、复杂的、长期运行的应用程序构建为一组相互配合的服务

Hystrix 是一套完善的服务保护组件, 可以实现 服务降级 , 服务熔断 , 服务隔离 等保护措施 使用它可以合理的应对高并发的情况 做到保护服务的效果 1. 导入依赖 <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-hystrix</artifactId> </dependency> 2. 在程序启动类添加@EnableHystrix注解, 开启Hystrix 3. 编写方法无法访问时的默认返回数据 String fallback(){ return "服务器繁忙"; } 4. 在接口上添加@HystrixCommand(fallbackMethod = "方法名")注解, 开启Hystrix服务保护 5. 配置 application.yml文件 hystrix: command: default: execution: timeout: enabled: false 6. 开启压力测试 来源： https://www.cnblogs.com/zhainan-blog/p/11641592.html

本期内容 微服务系列文章的第一篇介绍了微服务架构模式，讨论了使用微服务的优缺点，以及为什么微服务虽然复杂度高却是复杂应用程序的理想选择。 在决定以一组微服务来构建自己的应用时，你需要确定应用客户端如何与微服务交互。 在单体式程序中，通常只有一组冗余的或者负载均衡的服务提供点。在微服务架构中，每一个微服务暴露一组细粒度的服务提供点。在本篇文章中，我们来看它如何影响客户端到服务端通信，并提出一种使用 API 网关的方法。 简要概述 让我们想象一下，你要为一个购物应用程序开发一个原生移动客户端。你很可能需要实现一个产品详情页面，展示任何指定商品的信息。 下图展示了 Amazon Android 应用在商品详情页显示的内容。 即使只是个智能手机应用，产品详情页面也显示了大量的信息。该页面不仅包含基本的产品信息（如名称、描述、价格），而且还显示了如下内容： 购物车中的商品数量 历史订单 客户评论 低库存预警 送货选项 各种推荐，包括经常与该商品一起购买的其它商品、购买该商品的客户购买的其它商品、购买该商品的客户看过的其它商品 其它的购物选择 使用单体应用程序架构时，移动客户端通过向应用程序发起一次 REST 调用（GET api.company.com/productdetails/）来获取这些数据。负载均衡器将请求路由给 N 个相同的应用程序实例中的其中之一。然后

I have microservices project with Spring Cloud, the snippet from parent: <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>1.5.7.RELEASE</version> </parent> <dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-dependencies</artifactId> <version>Dalston.SR3</version> <type>pom</type> <scope>import</scope> </dependency> All services are running under Eureka server: All services are running fine. I can call make appropriate calls with Postman and everything works

在微服务架构中，根据业务来拆分成一个个的服务，服务与服务之间可以相互调用（RPC），在Spring Cloud可以用RestTemplate+Ribbon和Feign来调用。为了保证其高可用，单个服务通常会集群部署。由于网络原因或者自身的原因，服务并不能保证100%可用，如果单个服务出现问题，调用这个服务就会出现线程阻塞，此时若有大量的请求涌入，Servlet容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩”效应。 为了解决这个问题，业界提出了断路器模型。 一、断路器简介 Netflix has created a library called Hystrix that implements the circuit breaker pattern. In a microservice architecture it is common to have multiple layers of service calls. . —-摘自官网 Netflix开源了Hystrix组件，实现了断路器模式，SpringCloud对这一组件进行了整合。 在微服务架构中，一个请求需要调用多个服务是非常常见的，如下图： 较底层的服务如果出现故障，会导致连锁故障。当对特定的服务的调用的不可用达到一个阀值