Spring Cloud从学习到应用的翻车记录

前言

之前的系统一直使用dubbo来实现RPC，不得不说dubbo确实挺好的，不过每次都要写到共同的jar里面，让开发觉得操作过于麻烦，本着能躺着就不站着就懒人思维，再不停不被灌输Spring Cloud多么多么方便之后，我开启了从学习到应用的翻车之路。

多说几句

看了一些资料之后，觉得自己好像都会了，然后开始写demo，试着自己的搭的时候，突然发现原来坑不少啊，最后要上线我们正常使用的项目，做迭代的时候，我才明白，啥叫温水煮青蛙，要不是已经到这里了，我肯定不会继续了，毕竟dubbo也还可以。

Spring Cloud入门

这部分特别感谢大象O无形写的Spring Cloud入门教程，这部分写的真的很好，而且例子也简单，很适合学习，感谢大象老师，地址如下：
https://www.cnblogs.com/chry/p/7248947.html

一步一步对照着弄完，可以对Spring Cloud的使用有一定的了解。
大象老师的教程有一个小坑，这面标注一下，以便大家学习时，更快找到原因

第一节：服务注册

大象老师的地址如下：
https://www.cnblogs.com/chry/p/7248947.html
小问题：
1.application.yml文件的拼写错误，对于小白来说，可能直接复制不太容易发现问题所在。
2.使用application.properties的同学注意文件的格式转换。
3.由于大象老师写的比较早2017年左右写的，所有用的是Spring boot 1.5.3的版本，不同的boot版本也对应的不同的Cloud的版本，这部分需要自己注意一下
例如：我用的是2.1.3

	<parent>
		<groupId>org.springframework.boot</groupId>
		<artifactId>spring-boot-starter-parent</artifactId>
		<version>2.1.3.RELEASE</version>
	</parent>

那对应的

		<dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-eureka-server</artifactId>
        </dependency>

和

        <dependencies>
            <dependency>
                <groupId>org.springframework.cloud</groupId>
                <artifactId>spring-cloud-dependencies</artifactId>
                <version>Dalston.RC1</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>

就要换成

		<dependency>
			<groupId>org.springframework.cloud</groupId>
			<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
		</dependency>

和

		<dependencies>
			<dependency>
				<groupId>org.springframework.cloud</groupId>
				<artifactId>spring-cloud-dependencies</artifactId>
				<version>Finchley.RELEASE</version>
				<type>pom</type>
				<scope>import</scope>
			</dependency>
		</dependencies>

不同的boot版本，会对应不同的cloud的包，而且一些必要的包可能也会发生变化，当出现导入包错误的时候，记得百度看看，自己的版本号，对应那些正确的版本。

第二节：配置管理 配置自动刷新 分布式环境下自动发现配置服务

大象老师的地址如下：
https://www.cnblogs.com/chry/p/7250584.html
https://www.cnblogs.com/chry/p/7260778.html
https://www.cnblogs.com/chry/p/7262088.html
好吧，我承认我们配置管理基本没有使用这个，而且目前的业务发展，未来可能使用的可能性也不大，所以，我就看了看，随便弄了一下就拉到了，没办法，因为我懒。

第三节：Ribbon实现客户端的负载均衡

地址如下：https://www.cnblogs.com/chry/p/7263281.html
这部分略微有点小问题
1.原文 创建主类ServiceRibbonApplication的代码部分做了调整，调整后代码如下：

@SpringBootApplication
@EnableDiscoveryClient
@EnableCircuitBreaker
public class ServiceRibbonApplication {

	public static void main(String[] args) {
		SpringApplication.run(ServiceRibbonApplication.class, args);
	}

	@Bean
	@LoadBalanced
	RestTemplate restTemplate() {
		return builder.build();
	}
	@Autowired
	private RestTemplateBuilder builder;
}

2.这部分的教程没有application.yml，具体文件内容如下

eureka:
  client:
    serviceUrl:
      defaultZone: http://localhost:8761/eureka/
server:
  port: 8901
spring:
  application:
    name: ribbon

其他的就没有啥了，因为最后决定项目使用的是Feign，所以这部分就只是尝试了一下

第四节：用声明式REST客户端Feign调用远端HTTP服务

大象老师的地址如下：
https://www.cnblogs.com/chry/p/7266916.html
小问题：
1.feign-httpclient的版本号没有说明，这个就无所谓了，随便弄一下试试呗，我用了8.16.2

第五节：熔断机制 – 断路器

大象老师的地址如下：
https://www.cnblogs.com/chry/p/7279856.html
这部分就是在原来的基础上对代码进行一些修改，实现请求失败时进行降级等处理，大学老师讲的很清楚，没啥问题。

中间总结

后面的zuul同样重要，然而我们项目使用的nginx，所以这部分我就没有继续探究，还是因为我懒
这些学习差不多了，我自信满满，准备开始往实际项目中进行迭代，毕竟对我这种菜鸡来说，我觉得我会了，我就是会了，然后翻车才刚刚开始

翻车开始

第一坑：隔离时间

hystrix的熔隔离默认时间是100ms，我当时就疯了，国内的网络环境，但凡检索一下数据库，都不能100ms就搞定吧，尤其还是我们这种小公司，有个服务器就不错了。所以就要解决默认隔离时间。
先说明一下现象：

org.apache.catalina.connector.ClientAbortException: java.io.IOException: 您的主机中的软件中止了一个已建立的连接。
    at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:396) ~[catalina.jar:8.0.35]
    at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:426) ~[tomcat-util.jar:8.0.35]
    at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:339) ~[tomcat-util.jar:8.0.35]
    at org.apache.catalina.connector.OutputBuffer.writeBytes(OutputBuffer.java:421) ~[catalina.jar:8.0.35]
    at org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:409) ~[catalina.jar:8.0.35]
    at org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:97) ~[catalina.jar:8.0.35]
    at com.fasterxml.jackson.core.json.UTF8JsonGenerator._flushBuffer(UTF8JsonGenerator.java:1819) ~[jackson-core-2.1.0.jar:2.1.0]

上面的 您的主机中的软件中止了一个已建立的连接
服务器还美滋滋的往回发请求呢，hystrix已经隔离了。
其实解决办法也简单，就是在配置文件里面加上一句

hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=3000

就好了，改成了30秒，这里扩展一下，不同的请求不同的微服务，可以设定不同的隔离时间，不过我之前看过之后，没记下来，有需要的请自行百度吧，这里只提供一下，这个可能实现，顺便贴一下hystrix的所有配置，免得遇到比我还懒的，不想去查

hystrix.command.default和hystrix.threadpool.default中的default为默认CommandKey

Command Properties
Execution相关的属性的配置：
hystrix.command.default.execution.isolation.strategy 隔离策略，默认是Thread, 可选Thread｜Semaphore

hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds 命令执行超时时间，默认1000ms

hystrix.command.default.execution.timeout.enabled 执行是否启用超时，默认启用true
hystrix.command.default.execution.isolation.thread.interruptOnTimeout 发生超时是是否中断，默认true
hystrix.command.default.execution.isolation.semaphore.maxConcurrentRequests 最大并发请求数，默认10，该参数当使用ExecutionIsolationStrategy.SEMAPHORE策略时才有效。如果达到最大并发请求数，请求会被拒绝。理论上选择semaphore size的原则和选择thread size一致，但选用semaphore时每次执行的单元要比较小且执行速度快（ms级别），否则的话应该用thread。
semaphore应该占整个容器（tomcat）的线程池的一小部分。
Fallback相关的属性
这些参数可以应用于Hystrix的THREAD和SEMAPHORE策略

hystrix.command.default.fallback.isolation.semaphore.maxConcurrentRequests 如果并发数达到该设置值，请求会被拒绝和抛出异常并且fallback不会被调用。默认10
hystrix.command.default.fallback.enabled 当执行失败或者请求被拒绝，是否会尝试调用hystrixCommand.getFallback() 。默认true
Circuit Breaker相关的属性
hystrix.command.default.circuitBreaker.enabled 用来跟踪circuit的健康性，如果未达标则让request短路。默认true
hystrix.command.default.circuitBreaker.requestVolumeThreshold 一个rolling window内最小的请求数。如果设为20，那么当一个rolling window的时间内（比如说1个rolling window是10秒）收到19个请求，即使19个请求都失败，也不会触发circuit break。默认20
hystrix.command.default.circuitBreaker.sleepWindowInMilliseconds 触发短路的时间值，当该值设为5000时，则当触发circuit break后的5000毫秒内都会拒绝request，也就是5000毫秒后才会关闭circuit。默认5000
hystrix.command.default.circuitBreaker.errorThresholdPercentage错误比率阀值，如果错误率>=该值，circuit会被打开，并短路所有请求触发fallback。默认50
hystrix.command.default.circuitBreaker.forceOpen 强制打开熔断器，如果打开这个开关，那么拒绝所有request，默认false
hystrix.command.default.circuitBreaker.forceClosed 强制关闭熔断器 如果这个开关打开，circuit将一直关闭且忽略circuitBreaker.errorThresholdPercentage
Metrics相关参数
hystrix.command.default.metrics.rollingStats.timeInMilliseconds 设置统计的时间窗口值的，毫秒值，circuit break 的打开会根据1个rolling window的统计来计算。若rolling window被设为10000毫秒，则rolling window会被分成n个buckets，每个bucket包含success，failure，timeout，rejection的次数的统计信息。默认10000
hystrix.command.default.metrics.rollingStats.numBuckets 设置一个rolling window被划分的数量，若numBuckets＝10，rolling window＝10000，那么一个bucket的时间即1秒。必须符合rolling window % numberBuckets == 0。默认10
hystrix.command.default.metrics.rollingPercentile.enabled 执行时是否enable指标的计算和跟踪，默认true
hystrix.command.default.metrics.rollingPercentile.timeInMilliseconds 设置rolling percentile window的时间，默认60000
hystrix.command.default.metrics.rollingPercentile.numBuckets 设置rolling percentile window的numberBuckets。逻辑同上。默认6
hystrix.command.default.metrics.rollingPercentile.bucketSize 如果bucket size＝100，window＝10s，若这10s里有500次执行，只有最后100次执行会被统计到bucket里去。增加该值会增加内存开销以及排序的开销。默认100
hystrix.command.default.metrics.healthSnapshot.intervalInMilliseconds 记录health 快照（用来统计成功和错误绿）的间隔，默认500ms
Request Context 相关参数
hystrix.command.default.requestCache.enabled 默认true，需要重载getCacheKey()，返回null时不缓存
hystrix.command.default.requestLog.enabled 记录日志到HystrixRequestLog，默认true

Collapser Properties 相关参数
hystrix.collapser.default.maxRequestsInBatch 单次批处理的最大请求数，达到该数量触发批处理，默认Integer.MAX_VALUE
hystrix.collapser.default.timerDelayInMilliseconds 触发批处理的延迟，也可以为创建批处理的时间＋该值，默认10
hystrix.collapser.default.requestCache.enabled 是否对HystrixCollapser.execute() and HystrixCollapser.queue()的cache，默认true

ThreadPool 相关参数
线程数默认值10适用于大部分情况（有时可以设置得更小），如果需要设置得更大，那有个基本得公式可以follow：
requests per second at peak when healthy × 99th percentile latency in seconds + some breathing room
每秒最大支撑的请求数 (99%平均响应时间 + 缓存值)
比如：每秒能处理1000个请求，99%的请求响应时间是60ms，那么公式是：
1000 （0.060+0.012）

基本得原则时保持线程池尽可能小，他主要是为了释放压力，防止资源被阻塞。
当一切都是正常的时候，线程池一般仅会有1到2个线程激活来提供服务

hystrix.threadpool.default.coreSize 并发执行的最大线程数，默认10
hystrix.threadpool.default.maxQueueSize BlockingQueue的最大队列数，当设为－1，会使用SynchronousQueue，值为正时使用LinkedBlcokingQueue。该设置只会在初始化时有效，之后不能修改threadpool的queue size，除非reinitialising thread executor。默认－1。
hystrix.threadpool.default.queueSizeRejectionThreshold 即使maxQueueSize没有达到，达到queueSizeRejectionThreshold该值后，请求也会被拒绝。因为maxQueueSize不能被动态修改，这个参数将允许我们动态设置该值。if maxQueueSize == -1，该字段将不起作用
hystrix.threadpool.default.keepAliveTimeMinutes 如果corePoolSize和maxPoolSize设成一样（默认实现）该设置无效。如果通过plugin（https://github.com/Netflix/Hystrix/wiki/Plugins）使用自定义实现，该设置才有用，默认1.
hystrix.threadpool.default.metrics.rollingStats.timeInMilliseconds 线程池统计指标的时间，默认10000
hystrix.threadpool.default.metrics.rollingStats.numBuckets 将rolling window划分为n个buckets，默认10

之所以说这个是坑的原因是因为我找到好多关于这个时间的配置，但是都不好用，我不知道是不是版本问题。

第二坑：feign请求

这个坑说大不大，说小不小

feign请求返回的结构是 LinkedHashMap
feign请求返回的结构是 LinkedHashMap
feign请求返回的结构是 LinkedHashMap

这个会造成什么影响呢？
如果返回的结果是Object中放Object，那直接转换成实体会报错，就是这样。
所以，转换的话，需要根据自己的情况，在写方法转换

第三坑：feign传参数的时候，传递header里面的内容

其实这个我认为duck不必，因为在网关做了权限认证之后，这部分不觉得需要传token之类的东西，但是考虑到，万一有问题呢，就打算直接header里面的内容直接穿透过去，给微服务好了。
这里面有几个需要解决的问题
1.如何获取request里面的内容
写了如下代码

public class FeignConfig implements RequestInterceptor {
	@Override
	public void apply(RequestTemplate requestTemplate) {
		ServletRequestAttributes attributes = (ServletRequestAttributes) RequestContextHolder.getRequestAttributes();
		if (attributes == null) {
			return;
		}
		HttpServletRequest request = attributes.getRequest();
		//添加token
		requestTemplate.header("auth-token", request.getHeader("auth-token"));
	}
}

RequestInterceptor方法是feign提供的，可以在feign请求前做一些处理，我重写了他。
然后我发现attributes 是null，于是我想到了第二个问题
2.获取attributes
这里我的解决办法是写了一个监听

@Configuration
public class WebConfig {
	@Bean
	public RequestContextListener requestContextListener(){
		
		return new RequestContextListener();
	}
}

但是写了之后我发现，attributes还是null，这下我就懵逼了，经过查资料等一顿瞎折腾，发现了问题的所在，Feign是一种异步的调用，而RequestContextHolder 里面写着两个大大的ThreadLocal

public abstract class RequestContextHolder {
    private static final boolean jsfPresent = ClassUtils.isPresent("javax.faces.context.FacesContext", RequestContextHolder.class.getClassLoader());
    private static final ThreadLocal<RequestAttributes> requestAttributesHolder = new NamedThreadLocal("Request attributes");
    private static final ThreadLocal<RequestAttributes> inheritableRequestAttributesHolder = new NamedInheritableThreadLocal("Request context");

经过再次百度（没错，我就是面向百度开发），发现了新的结论
hystrix.command.default.execution.isolation.strategy 隔离策略，默认是Thread, 可选Thread｜Semaphore
当把hystrix的隔离策略换成Semaphore之后，就可以在ThreadLocal里面获取了。
当我以为我已经解决问题的时候，我发现hystrix的官网，不推荐Semaphore，不推荐Semaphore，不推荐Semaphore
？？？？？？？？？？？？？？？？？？？？？？？？？
好吧，当我已经懒得再弄，打算就这么将就的时候，我又看到了一篇blog，不得不说，有时候摸鱼可能解决很多问题。
http://www.itmuch.com/spring-cloud-sum/hystrix-threadlocal/
这篇blog中，周老师牛逼哄哄的自己写了一个并发策略，完美的解决了传参的问题。

第四坑：feign传参数的时候，传递结构体

1.当参数比较复杂时，feign即使声明为get请求也会强行使用post请求。
2.不支持@GetMapping类似注解声明请求，需使用@RequestMapping(value =“url”,method = RequestMethod.GET)
3.使用@RequestParam注解时必须要在后面加上参数名。
4.传递复杂参数对象需要用Post，另外需要注意，Feign不支持使用GetMapping 和PostMapping
5.在传递的过程中，复杂对象使用@RequestBody进行注解，同时接收端也需要使用@RequestBody这个注解。消费端使用了@RequestBody而服务端没有接收@RequestBody，这时参数会接收不完整。

第五坑：关于自定义Decoder

其实这部分不算是坑，算是个自己解决返回Response的方法吧，这里面可以自由去编辑Response里面的内容，解码的话需要引个包

        <dependency>
            <groupId>com.netflix.feign</groupId>
            <artifactId>feign-gson</artifactId>
            <version>8.18.0</version>
        </dependency>

我把header和body给分开了，防止以后需要header里面的内容，不知道在哪去找

	public Map<String, Object> decode(Response response, Type type) throws IOException, FeignException{
		Map<String, Object> result = new HashMap<>();
		Object resultBody = gsonDecoder.decode(response,type);
		Map<String, Collection<String>> resultHeader = response.headers();
		result.put("resultBody", resultBody);
		result.put("resultHeader", resultHeader);
		return result;
	}

写在最后

Spring Cloud的项目才刚刚启动，之后发现新的问题，如果不是很傻逼的问题，我也会及时更新。

再次感谢大象老师和周老师

参考资料：
[1]: https://www.cnblogs.com/chry/p/7248947.html
[2]: http://www.itmuch.com/spring-cloud-sum/hystrix-threadlocal/