Spring Cloud

Spring Cloud
问题描述在之前发布的《Spring Cloud实战小贴士：Feign的继承特性(伪RPC模式)》一文中，我们介绍了如果使用Feign的继承特性来完成服务的提供以及服务的消费，实现了类似RPC的编程模式。但是，仔细一些的读者可能已经发现一个问题：当我们将服务消费者运行起来的时候，定义在服务提供方的那些请求映射关系也被加载到了服务消费者中，这就会带来两个问题： 由于服务消费者并不提供这些接口，对于开发者来说容易造成误解 由于加载了一些外部服务的接口定义，还存在与自身接口定义冲突的潜在风险 问题分析那么这些外部请求接口定义是如何被加载到消费端的呢？我们先来看看Spring MVC处理请求映射的RequestMappingHandlerMapping实现片段： @Overrideprotected boolean isHandler(Class<?> beanType) &#...

Spring Cloud
通过之前发布的《Spring Cloud构建微服务架构：服务消费者（Feign）》，我们已经学会如何使用Spring MVC的注解来绑定服务接口。我们几乎完全可以从服务提供方的Controller中依靠复制操作，来构建出相应的服务接口客户端，或是通过Swagger生成的API文档来编写出客户端，亦或是通过Swagger的代码生成器来生成客户端绑定。即便如此，有很多的方式来产生Feign的客户端程序，依然有很多开发者热衷于利用公共的依赖接口来连接服务提供者和服务消费者的方式。由此，Feign的继承特性就能很好的派上用处。下面，我们来详细看看如何使用Spring Cloud Feign的继承特性。 动手试一试接下来的示例将分为三个模块： 服务接口定义模块：通过Spring MVC注解定义抽象的interface服务接口 服务接口实现模块：实现服务接口定义模块的interface，该...

Spring Cloud
这是一篇博客福利！ 相信很多关注Spring Cloud的爱好者们，不论是读我的系列文章和书籍还是看其他朋友们写的博客佳文，都不可避免的启动多个项目来体验Spring Cloud带来的整套微服务架构方案。其中，Eureka注册中心几乎是每个试验都必须要启动的应用。在整个学习过程中，我们不厌其烦的启动它，为了让微服务之间能够正常的发现并调用服务接口。 所以…我花了点业余时间，对Spring Cloud Eureka Server的UI增加了一些说明，并将在博客上公开出来给Spring Cloud的初学者和开发者们使用，大家可以方便的使用它来调试我博客和《Spring Cloud微服务实战》书中的诸多示例，或是利用此开发和调试自己的应用。 该Eureka注册中心关闭了自我保护机制，所以当各位开发者的服务下线后，稍等片刻就会被剔除，所以大家不用担心服务的长时间停留在该服务注册中心上。说...

Spring Cloud
本篇作为《Spring Cloud微服务实战》一书关于Spring Cloud Zuul网关在Dalston版本对异常处理的补充。没有看过本书的读书也不要紧，可以先阅读我之前的两篇博文：《Spring Cloud实战小贴士：Zuul统一异常处理（一）》和《Spring Cloud实战小贴士：Zuul统一异常处理（二）》，这两篇文章都详细介绍和分析了Spring Cloud Zuul在过滤器设计中对异常处理的不足。同时，在这两篇文章中，也针对不足之处做了相应的解决方案。不过，这些方案都是基于Brixton版本所做的，在最新的Dalston版本中，Spring Cloud Zuul做了一些优化，所以我们不再需要做这些扩展就已经能够正确的处理异常信息了。那么，在Dalston版中，Spring Cloud Zuul中做了怎么样的修改以达到之前我们自己扩展的效果呢？ 过滤器类型的变更读者...

Spring Cloud
之前在spring for all社区看到这样一个问题：当actuator端点设置了context-path之后，turbine如何聚合数据？首先，我们要知道actuator端点设置了context-path是什么意思？也就是说，此时spring boot actuator的端点都有了一个前缀，比如： management.context-path=/xxx 如果设置了上面的参数，那个对于收集hystrix数据的端点将变为：/xxx/hystrix.stream，如果我们还是拿上一篇Spring Cloud构建微服务架构：Hystrix监控数据聚合【Dalston版】中构建你的turbine应用，那么将会看到如下错误： INFO 7812 --- [ Timer-0] c.n.t.monitor.instance.InstanceMonitor : Url for ...

Spring Cloud
上一篇我们介绍了使用Hystrix Dashboard来展示Hystrix用于熔断的各项度量指标。通过Hystrix Dashboard，我们可以方便的查看服务实例的综合情况，比如：服务调用次数、服务调用延迟等。但是仅通过Hystrix Dashboard我们只能实现对服务当个实例的数据展现，在生产环境我们的服务是肯定需要做高可用的，那么对于多实例的情况，我们就需要将这些度量指标数据进行聚合。下面，在本篇中，我们就来介绍一下另外一个工具：Turbine。 准备工作在开始使用Turbine之前，我们先回顾一下上一篇中实现的架构，如下图所示： 其中，我们构建的内容包括： eureka-server：服务注册中心 eureka-client：服务提供者 eureka-consumer-ribbon-hystrix：使用ribbon和hystrix实现的服务消费者 hystrix-das...

Spring Cloud
在上一篇《服务容错保护（hystrix断路器）》的介绍中，我们提到断路器是根据一段时间窗内的请求情况来判断并操作断路器的打开和关闭状态的。而这些请求情况的指标信息都是HystrixCommand和HystrixObservableCommand实例在执行过程中记录的重要度量信息，它们除了Hystrix断路器实现中使用之外，对于系统运维也有非常大的帮助。这些指标信息会以“滚动时间窗”与“桶”结合的方式进行汇总，并在内存中驻留一段时间，以供内部或外部进行查询使用，Hystrix Dashboard就是这些指标内容的消费者之一。 下面我们基于之前的示例来结合Hystrix Dashboard实现Hystrix指标数据的可视化面板，这里我们将用到下之前实现的几个应用，包括： eureka-server：服务注册中心 eureka-client：服务提供者 eureka-consumer-r...

Spring Cloud
前言在前两篇《Spring Cloud构建微服务架构：服务容错保护（Hystrix服务降级）》和《Spring Cloud构建微服务架构：服务容错保护（Hystrix依赖隔离）》中，我们对Hystrix提供的服务降级和依赖隔离有了基本的认识。下面我们将继续说说Hystrix的另外一个重要元件：断路器。 断路器断路器模式源于Martin Fowler的Circuit Breaker一文。“断路器”本身是一种开关装置，用于在电路上保护线路过载，当线路中有电器发生短路时，“断路器”能够及时的切断故障电路，防止发生过载、发热、甚至起火等严重后果。 在分布式架构中，断路器模式的作用也是类似的，当某个服务单元发生故障（类似用电器发生短路）之后，通过断路器的故障监控（类似熔断保险丝），直接切断原来的主逻辑调用。但是，在Hystrix中的断路器除了切断主逻辑的功能之外，还有更复杂的逻辑，下面我们来看...

Spring Cloud
前言在上一篇《Spring Cloud构建微服务架构：服务容错保护（Hystrix服务降级）》中，我们已经体验了如何使用@HystrixCommand来为一个依赖资源定义服务降级逻辑。实现方式非常简单，同时对于降级逻辑还能实现一些更加复杂的级联降级等策略。之前对于使用Hystrix来实现服务容错保护时，除了服务降级之外，我们还提到过线程隔离、断路器等功能。那么在本篇中我们就来具体说说线程隔离。 依赖隔离“舱壁模式”对于熟悉Docker的读者一定不陌生，Docker通过“舱壁模式”实现进程的隔离，使得容器与容器之间不会互相影响。而Hystrix则使用该模式实现线程池的隔离，它会为每一个Hystrix命令创建一个独立的线程池，这样就算某个在Hystrix命令包装下的依赖服务出现延迟过高的情况，也只是对该依赖服务的调用产生影响，而不会拖慢其他的服务。 通过对依赖服务的线程池隔离实现，可以带...

Spring Cloud
前言在微服务架构中，我们将系统拆分成了一个个的服务单元，各单元应用间通过服务注册与订阅的方式互相依赖。由于每个单元都在不同的进程中运行，依赖通过远程调用的方式执行，这样就有可能因为网络原因或是依赖服务自身问题出现调用故障或延迟，而这些问题会直接导致调用方的对外服务也出现延迟，若此时调用方的请求不断增加，最后就会出现因等待出现故障的依赖方响应而形成任务积压，线程资源无法释放，最终导致自身服务的瘫痪，进一步甚至出现故障的蔓延最终导致整个系统的瘫痪。如果这样的架构存在如此严重的隐患，那么相较传统架构就更加的不稳定。为了解决这样的问题，因此产生了断路器等一系列的服务保护机制。 针对上述问题，在Spring Cloud Hystrix中实现了线程隔离、断路器等一系列的服务保护功能。它也是基于Netflix的开源框架 Hystrix实现的，该框架目标在于通过控制那些访问远程系统、服务和第三方库的...

Spring Cloud
前言 此文所述处理方式为本人在实践过程中研究分析得出的一种解决方案。 本文不仅希望能为 SC 学习者提供一种如题问题的一种解决方案，并且希望通过本文引出各位 SC 的朋友对如题问题的共同探讨和最佳实践方案的分享。 场景及痛点 单个项目是通过 Jersey 来实现 restful 风格的架构 发生异常时异常信息总是提示没有回调方法，不能显示基础服务抛出的异常信息 暂时没有考虑发生异常之后进行回调返回特定内容 业务系统通过 feign 调用基础服务，基础服务是会根据请求抛出各种请求异常的（采用标准http状态码），现在我的想法是如果调用基础服务时发生请求异常，业务系统返回的能够返回基础服务抛出的状态码 当然基础服务抛出的请求异常不能触发 hystrix 的熔断机制 问题解决方案分析解决思路 通过网上一些资料的查询，看到很多文章会说 HystrixBadRequestException...

Spring Cloud
Spring Cloud Config是Spring Cloud团队创建的一个全新项目，用来为分布式系统中的基础设施和微服务应用提供集中化的外部配置支持，它分为服务端与客户端两个部分。其中服务端也称为分布式配置中心，它是一个独立的微服务应用，用来连接配置仓库并为客户端提供获取配置信息、加密/解密信息等访问接口；而客户端则是微服务架构中的各个微服务应用或基础设施，它们通过指定的配置中心来管理应用资源与业务相关的配置内容，并在启动的时候从配置中心获取和加载配置信息。Spring Cloud Config实现了对服务端和客户端中环境变量和属性配置的抽象映射，所以它除了适用于Spring构建的应用程序之外，也可以在任何其他语言运行的应用程序中使用。由于Spring Cloud Config实现的配置中心默认采用Git来存储配置信息，所以使用Spring Cloud Config构建的配置服务...

Spring Cloud
通过前两篇《Spring Cloud构建微服务架构：服务消费（基础）》和《Spring Cloud构建微服务架构：服务消费（Ribbon）》，我们已经学会了在Spring Cloud中基本的服务调用方式。本文我们将继续介绍Spring Cloud中的另外一个服务消费的工具：Spring Cloud Feign。 Spring Cloud FeignSpring Cloud Feign是一套基于Netflix Feign实现的声明式服务调用客户端。它使得编写Web服务客户端变得更加简单。我们只需要通过创建接口并用注解来配置它既可完成对Web服务接口的绑定。它具备可插拔的注解支持，包括Feign注解、JAX-RS注解。它也支持可插拔的编码器和解码器。Spring Cloud Feign还扩展了对Spring MVC注解的支持，同时还整合了Ribbon和Eureka来提供均衡负载的HT...

Spring Cloud
通过上一篇《Spring Cloud构建微服务架构：服务消费（基础）》，我们已经学会如何通过LoadBalancerClient接口来获取某个服务的具体实例，并根据实例信息来发起服务接口消费请求。但是这样的做法需要我们手工的去编写服务选取、链接拼接等繁琐的工作，对于开发人员来说非常的不友好。所以，下来我们看看Spring Cloud中针对客户端负载均衡的工具包：Spring Cloud Ribbon。 Spring Cloud RibbonSpring Cloud Ribbon是基于Netflix Ribbon实现的一套客户端负载均衡的工具。它是一个基于HTTP和TCP的客户端负载均衡器。它可以通过在客户端中配置ribbonServerList来设置服务端列表去轮询访问以达到均衡负载的作用。 当Ribbon与Eureka联合使用时，ribbonServerList会被Discov...

Spring Cloud
通过上一篇《Spring Cloud构建微服务架构：服务注册与发现》，我们已经成功地将服务提供者：eureka-client或consul-client注册到了Eureka服务注册中心或Consul服务端上了，同时我们也通过DiscoveryClient接口的getServices获取了当前客户端缓存的所有服务清单，那么接下来我们要学习的就是：如何去消费服务提供者的接口？ 使用LoadBalancerClient在Spring Cloud Commons中提供了大量的与服务治理相关的抽象接口，包括DiscoveryClient、这里我们即将介绍的LoadBalancerClient等。对于这些接口的定义我们在上一篇介绍服务注册与发现时已经说过，Spring Cloud做这一层抽象，很好的解耦了服务治理体系，使得我们可以轻易的替换不同的服务治理设施。 从LoadBalancerCl...