changs 2019-04-13 19:26:20 4467
通过《Spring Cloud Alibaba基础教程：使用Nacos实现服务注册与发现》一文的学习，我们已经学会如何使用Nacos来实现服务的注册与发现，同时也介绍如何通过LoadBalancerClient接口来获取某个服务的具体实例，并根据实例信息来发起服务接口消费请求。但是这样的做法需要我们手工的去编写服务选取、链接拼接等繁琐的工作，对于开发人员来说非常的不友好。所以接下来，我们再来看看除此之外，还支持哪些其他的服务消费方式。
changs 2019-04-13 19:26:20 2320
上篇文章《Spring Cloud中Hystrix 线程隔离导致ThreadLocal数据丢失》我们对ThreadLocal数据丢失进行了详细的分析，并通过代码的方式复现了这个问题。
changs 2019-04-13 19:26:20 2466
通过之前Spring Cloud系列教程中的《Spring Cloud构建微服务架构：服务容错保护（Hystrix服务降级）》一文，我们已经知道如何通过Hystrix来保护自己的服务不被外部依赖方拖垮的情况。但是实际使用过程中经常碰到开发反应“莫名”触发了降级逻辑的情况。为了更精准的定位触发原因，或是在降级逻辑中需要根据不同的异常做不同的处理时，在降级方法中，我们希望可以获取到主逻辑中抛出的异常信息。接下来就来介绍一下Hystrix两种不同实现方式中如何在降级逻辑中获取异常信息的方法。
changs 2019-04-13 19:26:20 2357
该类中该方法为发生异常的回调方法，由此可以看出如果抛出异常如果是 HystrixBadRequestException 是直接处理异常之后进行抛出（这里不会触发熔断机制），而不是进入回调方法。
changs 2019-04-13 19:26:20 2438
在之前发布的《Spring Cloud实战小贴士：Feign的继承特性(伪RPC模式)》一文中，我们介绍了如果使用Feign的继承特性来完成服务的提供以及服务的消费，实现了类似RPC的编程模式。但是，仔细一些的读者可能已经发现一个问题：当我们将服务消费者运行起来的时候，定义在服务提供方的那些请求映射关系也被加载到了服务消费者中，这就会带来两个问题：
changs 2019-04-13 19:26:20 2305
先来看看症状。比如下面的例子：
changs 2019-04-13 19:26:20 2371
当我们使用Spring Cloud Ribbon实现客户端负载均衡的时候，通常都会利用@LoadBalanced来让RestTemplate具备客户端负载功能，从而实现面向服务名的接口访问（原理可见《Spring Cloud源码分析（二）Ribbon》一文，如果对Spring Cloud中使用Ribbon进行服务消费还没有概念的话，建议先阅读《Spring Cloud构建微服务架构（二）服务消费者》一文。）。
changs 2019-04-13 19:26:20 2380
造成第一次服务调用出现失败的原因主要是Ribbon进行客户端负载均衡的Client并不是在服务启动的时候就初始化好的，而是在调用的时候才会去创建相应的Client，所以第一次调用的耗时不仅仅包含发送HTTP请求的时间，还包含了创建RibbonClient的时间，这样一来如果创建时间速度较慢，同时设置的超时时间又比较短的话，很容易就会出现上面所描述的显现。
changs 2019-04-13 19:26:20 4440
之前写了几篇关于Spring Cloud Stream使用中的常见问题，比如：
changs 2019-04-13 19:26:20 2345
Spring Cloud Feign是一套基于Netflix Feign实现的声明式服务调用客户端。它使得编写Web服务客户端变得更加简单。我们只需要通过创建接口并用注解来配置它既可完成对Web服务接口的绑定。它具备可插拔的注解支持，包括Feign注解、JAX-RS注解。它也支持可插拔的编码器和解码器。Spring Cloud Feign还扩展了对Spring MVC注解的支持，同时还整合了Ribbon和Eureka来提供均衡负载的HTTP客户端实现。
changs 2019-04-13 19:26:20 4428
Spring Cloud Ribbon是基于Netflix Ribbon实现的一套客户端负载均衡的工具。它是一个基于HTTP和TCP的客户端负载均衡器。它可以通过在客户端中配置ribbonServerList来设置服务端列表去轮询访问以达到均衡负载的作用。
changs 2019-04-13 19:26:20 2423
在之前介绍使用Ribbon进行服务消费的时候，我们用到了RestTemplate，但是熟悉Spring的同学们是否产生过这样的疑问：RestTemplate不是Spring自己就有的吗？跟Ribbon的客户端负载均衡又有什么关系呢？下面在本文，我们来看RestTemplate和Ribbon是如何联系起来并实现客户端负载均衡的。
changs 2019-04-13 19:26:20 4438
Spring Cloud是一个基于Spring Boot实现的云应用开发工具，它为基于JVM的云应用开发中涉及的配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等操作提供了一种简单的开发方式。
changs 2019-04-13 19:26:20 4449
在之前的《Spring Cloud构建微服务架构：分布式配置中心》一文中，我们介绍的Spring Cloud Server配置中心采用了Git的方式进行配置信息存储。这一设计巧妙的利用Git自身机制以及其他具有丰富功能的Git服务端产品，让Spring Cloud Server在配置存储和管理的上避开了很多与管理相关的复杂实现，使其具备了配置中心存储配置和读取配置的基本能力；而更上层的管理机制，由于不具备普遍适用性，所以Spring Cloud Server并没有自己去实现这部分内容，而是通过Git服务端产品来提供一部分实现，如果还需要更复杂的功能也能自己实现与定义。即便如此，对于Spring Cloud Server默认使用Git来存储配置的方案一直以来还是饱受争议。所以，本文将介绍一下Spring Cloud Config从Edgware版本开始新增的一种配置方式：采用数据库存储配置信息。
changs 2019-04-13 19:26:20 3717
之前我们已经通过《Spring Cloud Stream消费失败后的处理策略（一）：自动重试》一文介绍了Spring Cloud Stream默认的消息重试功能。本文将介绍RabbitMQ的binder提供的另外一种重试功能：重新入队。
changs 2019-04-13 19:26:20 4510
前两天我们已经介绍了两种Spring Cloud Stream对消息失败的处理策略：
changs 2019-04-13 19:26:20 4451
上一篇《Spring Cloud Stream消费失败后的处理策略（一）：自动重试》介绍了默认就会生效的消息重试功能。对于一些因环境原因、网络抖动等不稳定因素引发的问题可以起到比较好的作用。但是对于诸如代码本身存在的逻辑错误等，无论重试多少次都不可能成功的问题，是无法修复的。对于这样的情况，前文中说了可以利用日志记录消息内容，配合告警来做补救，但是很显然，这样做非常原始，并且太过笨拙，处理复杂度过高。所以，我们需要需求更好的办法，本文将介绍针对该类问题的一种处理方法：自定义错误处理逻辑。
changs 2019-04-13 19:26:20 2178
在Spring Cloud封装的Feign中并不直接支持传文件，但可以通过引入Feign的扩展包来实现，本来就来具体说说如何实现。
changs 2019-04-13 19:26:20 4471
我们在使用一些开源调度系统（比如：elastic-job等）的时候，对于任务的执行时间通常都是有规律性的，可能是每隔半小时执行一次，或者每天凌晨一点执行一次。然而实际业务中还存在另外一种定时任务，它可能需要一些触发条件才开始定时，比如：编写博文时候，设置2小时之后发送。对于这些开始时间不确定的定时任务，我们也可以通过Spring Cloud Stream来很好的处理。
changs 2019-04-13 19:26:20 4670
有的时候，我们对于同一通道中的消息处理，会通过判断头信息或者消息内容来做一些差异化处理，比如：可能在消息头信息中带入消息版本号，然后通过if判断来执行不同的处理逻辑，其代码结构可能是这样的：
changs 2019-04-13 19:26:20 4742
在上一篇《Spring Cloud Stream如何处理消息重复消费》中，我们通过消费组的配置解决了多实例部署情况下消息重复消费这一入门时的常见问题。本文将继续说说在另外一个被经常问到的问题：如果微服务生产的消息自己也想要消费一份，应该如何实现呢？
changs 2019-04-13 19:26:20 4816
Nacos作为注册中心和配置中心的基础教程，到这里先告一段落，后续与其他结合的内容等讲到的时候再一起拿出来说，不然内容会有点跳跃。接下来我们就来一起学习一下Spring Cloud Alibaba下的另外一个重要组件：Sentinel。
changs 2019-04-13 19:26:20 4599
之前我发过一篇《说说我为什么看好Spring Cloud Alibaba》，然后这两天有网友给我转了这篇文章《坑爹项目spring-cloud-alibaba，我们也来一个》，问我的看法是怎么样的，聊天时候简单说了一下。今天在家休息，抽空整理一下内容，逐点说一下我的看法，主要还是觉得这篇文章博眼球的成分高一些，因为这篇文章的解读与之前其他某些自媒体发布的《Eureka 2.0 开源工作宣告停止，继续使用风险自负》一文有异曲同工之“妙”，如果读者没有真正的理解Spring Cloud与Spring Cloud Alibaba，就很有可能会对它们有什么误解，然后产生这样的想法：
changs 2019-04-13 19:26:20 4536
最近对《Spring Cloud Alibaba基础教程》系列的催更比较多，说一下最近的近况：因为打算Spring Boot 2.x一起更新。所以一直在改博客Spring Boot专题页和Git仓库的组织。由于前端技术太过蹩脚，花了不少时间。大家不用担心，这个系列不会太监，因为我真心看好这个套件的未来，后续的更新也会继续赶上来。