hystrix

一、前言 在分布式系统架构中多个系统之间通常是通过远程RPC调用进行通信，也就是 A 系统调用 B 系统服务，B 系统调用 C 系统的服务。当尾部应用 C 发生故障而系统 B 没有服务降级时候可能会导致 B，甚至系统 A 瘫痪，这种现象被称为雪崩现象。所以在系统设计时候要使用一定的降级策略，来保证当服务提供方服务不可用时候，服务调用方可以切换到降级后的策略进行执行。 二、Hystrix 中基于自反馈调节熔断状态的算法原理 我们可以把熔断器想象为一个保险丝，在电路系统中，一般在所有的家电系统连接外部供电的线路中间都会加一个保险丝，当外部电压过高，达到保险丝的熔点时候，保险丝就会被熔断，从而可以切断家电系统与外部电路的联通，进而保障家电系统不会因为电压过高而损坏。 Hystrix提供的熔断器就有类似功能，当在一定时间段内服务调用方调用服务提供方的服务的次数达到设定的阈值，并且出错的次数也达到设置的出错阈值，就会进行服务降级，让服务调用方之间执行本地设置的降级策略，而不再发起远程调用。但是Hystrix提供的熔断器具有自我反馈，自我恢复的功能，Hystrix会根据调用接口的情况，让熔断器在closed,open,half-open三种状态之间自动切换。 open状态说明打开熔断，也就是服务调用方执行本地降级策略，不进行远程调用。 closed状态说明关闭了熔断

所谓的熔断机制和日常生活中见到电路保险丝是非常相似的，当出现了问题之后，保险丝会自动烧断，以保护我们的电器， 那么如果换到了程序之中呢？ 当现在服务的提供方出现了问题之后整个的程序将出现错误的信息显示，而这个时候如果不想出现这样的错误信息，而希望替换为一个错误时的内容。 一个服务挂了后续的服务跟着不能用了，这就是雪崩效应 对于熔断技术的实现需要考虑以下几种情况： · 出现错误之后可以 fallback 错误的处理信息； · 如果要结合 Feign 一起使用的时候还需要在 Feign（客户端）进行熔断的配置。 一、基于ribbon的Hystrix 基本配置 1、复制项目重命名为springcloud-moveServer-hystrix修改调用方 pom.xml 配置文件，追加 Hystrix 配置类： < dependency > < groupId > org.springframework.cloud </ groupId > < artifactId > spring-cloud-starter-hystrix </ artifactId > </ dependency > 2.修改程序 controller package com.pupeiyuan.controller; import java.util.ArrayList; import java.util.List;

雪崩效应 在微服务架构中，由于服务众多，通常会涉及多个服务层级的调用，而一旦基础服务发生故障，很可能会导致级联故障，进而造成整个系统不可用，这种现象被称为服务雪崩效应。服务雪崩效应是一种因“服务提供者”的不可用导致“服务消费者”的不可用,并将这种不可用逐渐放大的过程。 比如在一个系统中， A作为服务提供者，B是A的服务消费者，C和D又是B的服务消费者。如果此时A发生故障，则会引起B的不可用，而B的不可用又将导致C和D的不可用，当这种不可用像滚雪球一样逐渐放大的时候，雪崩效应就形成了。 熔断器（CircuitBreaker） 熔断器的原理很简单，如同电力过载保护器。它可以实现快速失败，如果它在一段时间内侦测到许多类似的错误，就会强迫其以后的多个调用快速失败，不再访问远程服务器，从而防止应用程序不断地尝试执行可能会失败的操作，使得应用程序继续执行而不用等待修正错误，或者浪费CPU时间去等到长时间的超时产生。熔断器也可以使应用程序能够诊断错误是否已经修正，如果已经修正，应用程序会再次尝试调用操作。熔断器模式就像是那些容易导致错误的操作的一种代理。这种代理能够记录最近调用发生错误的次数，然后决定使用允许操作继续，或者立即返回错误。熔断器是保护服务高可用的最后一道防线。 Hystrix特性 1.断路器机制 断路器很好理解, 当Hystrix Command请求后端服务失败数量超过一定比例

本文不进行Spring Boot Admin入门知识点说明 在 Spring Boot Actuator 中提供很多像 health 、 metrics 等实时监控接口，可以方便我们随时跟踪服务的性能指标。 Spring Boot 默认是开放这些接口提供调用的，那么就问题来了，如果这些接口公开在外网中，很容易被不法分子所利用，这肯定不是我们想要的结果。在这里我们提供一种比较好的解决方案。 被监控的服务配置 为被保护的http请求添加请求前缀 1 2 3 4 5 6 management: context-path: /example-context eureka: instance: status-page-url-path: ${management.context-path}/info health-check-url-path: ${management.context-path}/health 添加请求前缀 Spring Boot Admin 在启动的时候会去 eureka 拉去服务信息，其中 health 与 info 需要特殊处理，这两者的地址是根据 status-page-url-path 和 health-check-url-path 的值。 zuul 网关配置 zuul 保护内部服务http接口 1 2 zuul: ignoredPatterns: /*

1. Auth2认证流程 用户 授权 ，颁发服务令牌，服务拿着令牌去请求资源 2. 令牌分为哪几类？ 答： 分为 普通令牌和 JWT令牌 3. 向客户端返回的令牌 包括 哪几部分？ 答： token(短令牌)，刷新令牌，jwt令牌 4. 如何生成JWT令牌？ 答： 使用 JwtHelper生成令牌，根据(内容，私钥) //创建jwt令牌 @Test public void testCreateJwt(){ //密钥库文件 String keystore = "xc.keystore"; //密钥库的密码 String keystore_password = "xuechengkeystore"; //密钥库文件路径 ClassPathResource classPathResource = new ClassPathResource(keystore); //密钥别名 String alias = "xckey"; //密钥的访问密码 String key_password = "xuecheng"; //密钥工厂 KeyStoreKeyFactory keyStoreKeyFactory = new KeyStoreKeyFactory(classPathResource,keystore_password.toCharArray()); //密钥对（公钥和私钥） KeyPair

作者：SylvanasSun 原文：https://sylvanassun.github.io/2017/06/07/2017-06-07-IoC&AOP/ IoC 控制反转(Inversion of Control)是 OOP 中的一种设计原则,也是 Spring 框架的核心.大多数应用程序的业务逻辑代码都需要两个或多个类进行合作完成的, 通过IoC则可以减少它们之间的耦合度 . 实现方法 IoC 的主要实现方法有两种, 依赖注入 与 依赖查找 . 依赖注入 : 应用程序被动的接收对象, IoC 容器通过类型或名称等信息来判断将不同的对象注入到不同的属性中. 依赖注入主要有以下的方式: 基于 set 方法 : 实现特定属性的public set()方法,来让 IoC 容器调用注入所依赖类型的对象. 基于接口 : 实现特定接口以供 IoC 容器注入所依赖类型的对象. 基于构造函数 : 实现特定参数的构造函数,在创建对象时来让 IoC 容器注入所依赖类型的对象. 基于注解 : 通过 Java 的注解机制来让 IoC 容器注入所依赖类型的对象,例如 Spring 框架中的 @Autowired . 依赖查找 : 它相对于 依赖注入 而言是一种更为主动的方法,它会在需要的时候通过调用框架提供的方法来获取对象,获取时需要提供相关的配置文件路径、key等信息来确定获取对象的状态.

我们先认识一下SpringCloud的各个组件，然后知其所以然。 Spring Cloud架构的各个组件的原理分析 原理讲解前，先看一个最经典的业务场景，如开发一个电商网站，要实现支付订单的功能，流程如下： 创建一个订单之后，如果用户立刻支付了这个订单，我们需要将订单状态更新为“已支付” 扣减相应的商品库存 通知仓储中心，进行发货 给用户的这次购物增加相应的积分 如上，微服务的应用场景和核心竞争力： 降低耦合： 每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界。由于体积小、复杂度低，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性和开发效率。 独立部署： 由于微服务具备独立的运行进程，所以每个微服务也可以独立部署。当某个微服务发生变更时无需编译、部署整个应用。由微服务组成的应用相当于具备一系列可并行的发布流程，使得发布更加高效，同时降低对生产环境所造成的风险，最终缩短应用交付周期。 选型灵活： 微服务架构下，技术选型是去中心化的。每个团队可以根据自身服务的需求和行业发展的现状，自由选择最适合的技术栈。由于每个微服务相对简单，故需要对技术栈进行升级时所面临的风险就较低，甚至完全重构一个微服务也是可行的。 容错机制： 当某一组建发生故障时，在单一进程的传统架构下，故障很有可能在进程内扩散，形成应用全局性的不可用。在微服务架构下，故障会被隔离在单个服务中

发布时间：19-07-1720:12 一、引言 本文题为微服务和大数据性能指标参考，但实际上，无论是单体架构还是分布式架构、数据规模如何，在设计和开发各种功能性模块时，都需要提前考虑高性能需求水平并按需设计，对各种性能指标进行合理评估，从而尽量减少代码重构的可能性。 在完成功能模块的开发以后，还需要使用各种压力测试工具进行性能测试，从而判断代码是否能够满足性能要求，并找出性能瓶颈所在。 为了作出更加合理的性能评估值，我们需要先大概的了解一些常用的计算机操作所消耗的时间，从而心中有数的设计出一个符合需求、且易于实现的系统，减小线上系统失败的风险，并能够做到心中有数。 二、常用应用层性能指标参考标准 以下标准是使用PC X86 桌面机器的经验值，并不代表使用线上生产机器的经验值，仅供参考，评审时应该根据机器的不同进行调整。 2.1 通用标准 容量按照峰值的5倍冗余计算。分库分表后的容量一般可存储N年的数据（根据不同机器调整）。第三方查询接口吞吐量为5000/s。单条数据库记录占用大约1KB的空间。 2.2 MySQL 单端口读：1000/s。单端口写：700/s。单表容量：5000万条。 2.3 Redis 单端口读：40000/s。单端口写：40000/s。单端口内存容量：32GB。 2.4 Kafka 单机读：30000/s。单机写：5000/s。2.5 Flume HDFS

简介 在上一节中，我们讨论了feign+hystrix在项目开发中，除了考虑正常的调用之外，负载均衡和故障转移也是关注的重点，这也是feign + ribbon+hystrix的优势所在，本节我们就讨论一下在feign中使用ribbon，有两种方式 一、通过在配置文件application.yml配置，开启ribbon,并指定调用生产者相对上一节可以不做任何更改，可以看项目（microservice-consumer-movie-feign-with-hystrix-hystrix-factory） 项目结构如下： application.yml配置文件： spring: application: name: microservice-consumer-movie-feign-with-hystrix-hystrix-factory server: port: 7901 eureka: client: healthcheck: enabled: true serviceUrl: defaultZone: http://jacky:admin@peer1:8761/eureka/,http://jacky:admin@peer2:8762/eureka/,http://jacky:admin@peer3:8763/eureka/ instance: prefer-ip-address