hystrix

之前我们引入过dashboard 配置项，暴露正常可以访问的安全的端口， 启动类，之前加的dashBoard的注解 如果想用集群监控就必须继承Turbine。Hystrix的监控弊端比较大，所以一般来讲，微服务里面，我们绝大多数不会用Hystrix去做监控，实在是很麻烦的一件事情。 所以这给大家演示一下， 开始在加载一次数据了，监控还是比较耗性能的。 我们用postman多访问几次请求 页面就开始有数据了 随着点击，数字在增加 nowPage传比较正常的 dashboard的图的意思 强调这两个 理论上系统的峰值大概就是99这个级别。 在互联网项目里，这三个数是非常重要的指标。 当你的请求越多，这个圈就会越大，请求里面错误数越多，就会偏向于红色，全红的时候就是全错。 Hystrix里面默认就是2分钟之内的监控，我们正式的系统一般都是需要一个长期的监控，例如我希望能看到历史数据。看到告警，应该怎么处理，为什么出现告警，这些都是我们需要反向去排查的 东西，例如双11这种情况，你2分钟之内的监控还能有用。 结束 来源： oschina 链接： https://my.oschina.net/u/4369262/blog/4267757

服务网关和Zuul 为什么要有服务网关： 我们都知道在微服务架构中，系统会被拆分为很多个微服务。那么作为客户端要如何去调用这么多的微服务呢？难道要一个个的去调用吗？很显然这是不太实际的，我们需要有一个统一的接口与这些微服务打交道，这就是我们需要服务网关的原因。 我们已经知道，在微服务架构中，不同的微服务可以有不同的网络地址，各个微服务之间通过互相调用完成用户请求，客户端可能通过调用N个微服务的接口完成一个用户请求。比如：用户查看一个商品的信息，它可能包含商品基本信息、价格信息、评论信息、折扣信息、库存信息等等，而这些信息获取则来源于不同的微服务，诸如产品系统、价格系统、评论系统、促销系统、库存系统等等，那么要完成用户信息查看则需要调用多个微服务，这样会带来几个问题： 客户端多次请求不同的微服务，增加客户端代码或配置编写的复杂性 认证繁杂，访问每个服务都要进行一次认证 每个服务都通过http访问，导致http请求增加，效率不高拖慢系统性能 多个服务存在跨域请求问题，处理起来比较复杂 如下图所示： 我们该如何解决这些问题呢？我们可以尝试想一下，不要让前端直接知道后台诸多微服务的存在，我们的系统本身就是从业务领域的层次上进行划分，形成多个微服务，这是后台的处理方式。对于前台而言，后台应该仍然类似于单体应用一样，一次请求即可，于是我们可以在客户端和服务端之间增加一个API网关

大版本对应： Spring Boot Spring Cloud 1.2.x Angel版本 1.3.x Brixton版本 1.4.x stripes Camden版本 1.5.x Dalston版本、Edgware版本 2.0.x Finchley版本 2.1.x Greenwich.SR2 在实际开发过程中，我们需要更 详细的版本对应：Spring 官方对应版本地址： ( https://start.spring.io/actuator/info )， 建议用firefox浏览器打开，你会看见格式化好了json信息： spring-cloud-dependencies 版本列表可查看： https://mvnrepository.com/artifact/org.springframework.cloud/spring-cloud-dependencies spring-boot-starter-parent 版本列表可查看： https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-starter-parent 在SpringCloud中，1.X和2.X版本在pom.xml中引入的jar包名字都不一样，比如有的叫spirng-cloud-starter-hystrix 有的叫spring

gateWay网关负载均衡报404错误，我的yml文件配置 spring: cloud: gateway: locator: enabled: true loadbalancer: # 服务找不到404 use404: true routes: # 认证中心 - id: lxyyf-auth uri: lb://lxyyf-auth predicates: - Path=/auth/** filters: # 验证码处理 - ValidateCodeGatewayFilter # 前端密码解密 - PasswordDecoderFilter #UPMS 模块 - id: lxyyf-upms-biz uri: lb://lxyyf-upms-biz predicates: - Path=/admin/** filters: # 限流配置 - name: RequestRateLimiter args: key-resolver: '#{@remoteAddrKeyResolver}' redis-rate-limiter.replenishRate: 10 redis-rate-limiter.burstCapacity: 20 # 降级配置 - name: Hystrix args: name: default fallbackUri: 'forward:/fallback' #

在hystrix的回退方法中做好报警通知就可以了，Hystrix的监控仪表盘在实际开发中用得不多，此处只是作为了解。 hystrix的监控可以检测消费者调用提供者的情况，hystrix是在消费者中设置的，hystrix的监控自然也是在消费者中设置的。 actuator 服务调用监控 1、在消费者中添加依赖： < dependency > < groupId > org.springframework.boot </ groupId > < artifactId > spring-boot-starter-actuator </ artifactId > </ dependency > 2、配置文件 management: endpoints: web: exposure: include: "*" 默认只会监控部分数据，此配置是监控服务调用所有的数据 3、在浏览器地址栏输入 127.0.0.1:8781/actuator/hystrix.stream ，ip、port都是消费者的 刷新一下服务调用，已经监控到数据 dashboard 仪表盘 上面密密麻麻的数据不直观，Hystrix提供了仪表盘可以将数据直观地展示出来。 可以在消费者中配置仪表盘，也可以单独写一个子模块作为仪表盘。 1、创建时勾选Spring Cloud Circuit Breaker -> Hystrix

缓存穿透 缓存系统，按照KEY去查询VALUE,当KEY对应的VALUE一定不存在的时候并对KEY并发请求量很大的时候，就会对后端造成很大的压力。 （查询一个必然不存在的数据。比如文章表，查询一个不存在的id，每次都会访问DB，如果有人恶意破坏，很可能直接对DB造成影响。） 由于缓存不命中，每次都要查询持久层。从而失去缓存的意义。 解决方法： 1、缓存层缓存空值。 –缓存太多空值，占用更多空间。（优化：给个空值过期时间） –存储层更新代码了，缓存层还是空值。（优化：后台设置时主动删除空值，并缓存把值进去） 2、将数据库中所有的查询条件，放到布隆过滤器中。当一个查询请求来临的时候，先经过布隆过滤器进行检查，如果请求存在这个条件中，那么继续执行，如果不在，直接丢弃。 备注： 比如数据库中有10000个条件，那么布隆过滤器的容量size设置的要稍微比10000大一些，比如12000. 对于误判率的设置，根据实际项目，以及硬件设施来具体决定。但是一定不能设置为0，并且误判率设置的越小，哈希函数跟数组长度都会更多跟更长，那么对硬件，内存中间的要求就会相应的高。 private static BloomFilter<Integer> bloomFilter = BloomFilter.create(Funnels.integerFunnel(), size, 0.0001);