hystrix

线程隔离这块，一定会有线程池，有线程池，我们一般会给他启用一个唯一标识。然后用来对于线程池进行一些相关的操作。就像我们有孩子，我们给他起名字张三、二狗，紧接着呢我想去召唤他什么的，我就用这个名字就可以了。这就是ThreadPoolKey的意思。 ThreadPoolKey不是必填项。Hytrix在你不指定ThreadPoolKey的情况下默认会使用GroupKey命名线程池。 添加线程池的方法 演示怎么改线程池的名称。 信号量是操作系统底层的一个概念。大家如果搜linux的信号量，应该能搜到具体的意思。Hytrix里面信号量的通俗的解释。可以认为它是一种计数器，没进来就加1.当信号量上限满了，我就不允许后面再进来了。说白了它就是一个排队的过程，你进来一个，我就加一个，这就好像停车场，来一个车，车位就数量减1，数量减没了就代表我所有的车就停满了。 信号量不是单起一个线程给你执行业务逻辑，它就在你的主线程上去执行，但是你主线程调用的次数我要限制，超过这个数量，我就不允许你在主线程上继续执行了。 就是信号量本身做的一个事情。这个事情不难理解。 官方图，用来讲解信号量和线程隔离。 当一个请求进来了，它就分为三种情况两大类去执行。首先左边这一块。这一块是线程隔离。 右侧的就是信号量。它有10个计数。 两者主要的区别就在这里，加Denpendency Thread依赖的线程

springcloud线上发布超时系列文章： springcloud线上发布超时之feign（ribbon饥饿加载） springcloud线上发布超时之grpc springcloud线上发布超时方案之终极杀招：预热（测试用例） 前言 经过上面两章的优化，超时报错有所减少，但是只是得到了缓解但是当流量切换时还是会有大量超时。 方案 这里又增加了一个启动后预热，即在程序启动后执行测试用例n次，让hystrix、web容器线程池等资源初始化。在测试用例执行完成之前，为了保证服务不对外提供服务，这里可以分两种。 延迟注册到注册中心 如果时使用注册中心来进行服务发现等，这里可以采用延迟注册来保证测试用例的成功执行， 如果时eureka为注册中心可以配置initial-instance-info-replication-interval-seconds参数，默认是40s，可以将其改为1分钟 如果是consul或者zk，可以修改响应的延时注册时间，或者修改服务端有效时间 kubernetes中增加服务ready延时时间 这里再deploy.yml中配置如下： spec: replicas: 1 template: spec: containers: - args: livenessProbe: failureThreshold: 5 httpGet: path: /health port:

Hytrix官方的 第一部分是这里。熔断依赖命令来实现的 可以认为是线程的入口，所有需要Hytrix支持的内容 都必须要走 HystrixCommand、HystrixObservableCommand：只有这两种形式，没有其他可选的形式。除非你们继承它实现了自己的子类 第二部分 都是入口，这四个的差异就是同步执行，还是异步执行。 第三步 不用处理后面逻辑了 这里有缓存，直接返回 第四步熔断 其实是个状态判断，Hytrix自身有个开关，可以认为是一把锁，如果说Hytrix这把锁打开，意思就是说我已经不让你进了。锁关闭就是允许你进。 你可以为是拧把手的锁。打开的意思就是锁弹开了。 熔断器打开，就是这里的yes，那你就不要继续往下走了。 熔断了去调用getFailBack或者resumeWithFallback方法。 调用getFailBack或者resumeWithFallback方法。，这个方法调用，如果工程了那么就返回，如果失败了就报错。 getFailBack就是之前说的快速失败，就是降级。降级业务其实是我们自己写的。熔断开启后，会直接调用我们预定义的getFailBack方法，这个getFailBack方法里面的内容就是即将要返回的内容。 熔断如果没有开启就调下面的方法。Hytrix给我们提供了熔断和信号量，无论是信号量还是线程池都是有上限的。 如果说这两部分都出上限了

构建演示的工程，轻量级的 在show工程下在单独新建工程 复制groupId 改成下划线即可 删除文件。没用的 修改配置文件为yml格式 test文件夹删除 复制过来parent节点 这里先都去掉 复制一个日志配置文件 配合文件复制过来 指定端口和服务名 父工程内加入这个模块 导入依赖 结束 来源： oschina 链接： https://my.oschina.net/u/4280983/blog/4260689

准备好的依赖包 把依赖包拷贝到我们的pom.xml内 新建test包，然后按照下面路径建包 首先演示command，那就先创建command包 创建CommandDemo 继承HystrixCommand指定泛型为String，然后实现Run方法。 上面之所以还会报错，是因为还需要构造函数，然后把name传递进来。 把name属性初始化，然后提供getter和setter方法 构造函数传递进来的name就赋值给我们内部的属性name run方法就是单词请求调用的业务方法 run方法就是在架构图中的这个位置。run方法就是Command业务的执行。 返回这个result 使用command 创建测试类。 我们现在要做的事情就是执行execute() 这里面有两个方法，一个是run方法，一个是execute。执行run方法就不去执行前面那一堆的逻辑 execute在前面。run在后面。 如果直接执行run。前面那些熔断都执行不到了。所以在这里我们不会执行run方法。 输出我们的返回值 加上Junit测试的注解 执行测试 command构建大概就是这样 结束 来源： oschina 链接： https://my.oschina.net/u/4397293/blog/4260687

spring cloud 使用feign 项目的搭建 在这里就不写了，本文主要讲解在使用过程中遇到的问题以及解决办法 1：示例 1 @RequestMapping(value = "/generate/password", method = RequestMethod.POST) 2 KeyResponse generatePassword(@RequestBody String passwordSeed); 3 在这里 只能使用 @RequestMapping(value = "/generate/password", method = RequestMethod.POST) 注解 不能使用 @PostMapping 否则项目启动会报 4 Caused by: java.lang.IllegalStateException: Method generatePassword not annotated with HTTP method type (ex. GET, POST) 异常 2：首次访问超时问题 原因： Hystrix默认的超时时间是1秒，如果超过这个时间尚未响应，将会进入fallback代码。 而首次请求往往会比较慢（因为Spring的懒加载机制，要实例化一些类），这个响应时间可能就大于1秒了。 解决方法： <1： 配置Hystrix的超时时间改为5秒 hystrix

缓存雪崩 简介： 缓存同一时间大面积的失效，所以，后面的请求都会落到数据库上，造成数据库短时间内承受大量请求而崩掉。 解决办法： 事前： 尽量保证整个 Redis 集群的高可用性，发现机器宕机尽快补上。选择合适的内存淘汰策略。 事中： 本地 Ehcache 缓存 + Hystrix 限流&降级，避免 MySQL 崩掉。 事后： 利用 Redis 持久化机制保存的数据尽快恢复缓存。 缓存穿透 简介： 一般是黑客故意去请求缓存中不存在的数据，导致所有的请求都落到数据库上，造成数据库短时间内承受大量请求而崩掉。 解决办法： 有很多种方法可以有效地解决缓存穿透问题，最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的 bitmap 中。 一个一定不存在的数据会被这个 bitmap 拦截掉，从而避免了对底层存储系统的查询压力。 另外也有一个更为简单粗暴的方法（我们采用的就是这种），如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。 文章转载于： https://www.cnblogs.com/andy6/p/9771365.html 来源： oschina 链接： https://my.oschina.net/u/4330791/blog/3376106

微服务全链路跟踪：grpc集成zipkin 微服务全链路跟踪：grpc集成jaeger 微服务全链路跟踪：springcloud集成jaeger 微服务全链路跟踪：jaeger集成istio，并兼容uber-trace-id与b3 微服务全链路跟踪：jaeger集成hystrix 背景 > 当springcloud服务集成hystrix，并且用了hystrixCommend注解到方法上时，jaeger链路会断掉 方案 在网上搜索到了大量jaeger遇到多线程时的处理方式，都是包装线程池来做到ThreadLocal传递，有很多都用到了阿里开源的 transmittable-thread-local 。 下面说一下当集成hystrix时，jaeger链路丢失问题，大家都知道hystrix默认是线程池隔离，所以归根结底还是遇到多线程线程变量没有共享的问题，网上也罗列了几种方案： 方案一：变更隔离方式 hystrix.command.default.execution.isolation.strategy: SEMAPHORE 当并发高时这里设置信号量隔离是有风险的，可以根据情况优化断路器配置来降低风险 方案二：自定义隔离策略 隔离策略官方文档有定义： 原先我就定义了一个feign传递request中header信息的策略，在原有的隔离策略下面参考 https://github.com

以下文章来源于阿里巴巴中间件 ，作者董艺荃 注：本篇文章整理自董艺荃在 Dubbo 社区开发者日上海站的演讲。 1、缘起 携程当初为什么要引入 Dubbo 呢？实际上从 2013 年底起，携程内主要使用的就是基于 HTTP 协议的 SOA 微服务框架。这个框架是携程内部自行研发的，整体架构在这近6年中没有进行大的重构。 受到当初设计的限制，框架本身的扩展性不是很好，使得用户要想自己扩展一些功能就会比较困难。另外，由于 HTTP 协议一个连接同时只能处理一个请求。在高并发的情况下，服务端的连接数和线程池等资源都会比较紧张，影响到请求处理的性能。 而 Dubbo 作为一个高性能的 RPC 框架，不仅是一款业界知名的开源产品，它整体优秀的架构设计和数据传输方式也可以解决上面提到的这些问题。正好在 2017 年下半年，阿里宣布重启维护 Dubbo 。基于这些原因，我们团队决定把 Dubbo 引入携程。 2、Dubbo 落地第一步 要在公司落地 Dubbo 这个新服务框架，第一步就是解决服务治理和监控这两个问题。 服务治理 在服务治理这方面，携程现有的 SOA 框架已经有了一套完整的服务注册中心和服务治理系统。对于服务注册中心，大家比较常用的可能是 Apache Zookeeper 。而我们使用的是参考 Netflix 开源的 Eureka 自行研发的注册中心 Artemis 。

前面使用ribbon拦截RestTemplate 实现服务的负载均衡 使用Hystrix进行熔断降级请求缓存 用原生的方式 将会有大量的模板代码，feigin就是rabbon和Histrix的整合 同 使用feign只需要通过接口对服务方的绑定 实现多处调用 使用例子 1.引入Pom依赖 < dependency > < groupId > org.springframework.cloud </ groupId > < artifactId > spring-cloud-starter-openfeign </ artifactId > </ dependency > < dependency > < groupId > org.springframework.cloud </ groupId > < artifactId > spring-cloud-starter-netflix-eureka-server </ artifactId > </ dependency > <!-- 开启端点 用于dashboard监控 --> < dependency > < groupId > org.springframework.boot </ groupId > < artifactId > spring-boot-starter-actuator </ artifactId > </