#Spring Cloud

我们在使用Spring Cloud的Ribbon或Feign来实现服务调用的时候,如果我们的机器或网络环境等原因不是很好的话,有时候会发现这样一个问题:我们服务消费方调用服务提供方接口的时候,第一次请求经常会超时,而之后的调用就没有问题了。下面我们就来说说造成这个问题的原因,以及如何解决的方法。 问题原因造成第一次服务调用出现失败的原因主要是Ribbon进行客户端负载均衡的Client并不是在服务启动的时候就初始化好的,而是在调用的时候才会去创建相应的Client,所以第一次调用的耗时不仅仅包含发送HTTP请求的时间,还包含了创建RibbonClient的时间,这样一来如果创建时间速度较慢,同时设置的超时时间又比较短的话,很容易就会出现上面所描述的显现。 从日志中我们也能知道这一点细节,在第一次发起调用的时候我们可以从日志中看到如下信息: 2017-09-25 08:29:54,...

在整体应用架构中,非生产环境情况下,一般 1GB 或者 2GB 的 RAM 就足够了。如果我们将这个应用程序划分为 20 或 30 个独立的微服务,那么很难期望 RAM 仍将保持在 1GB 或 2GB 左右。特别是如果我们使用 Spring Cloud 的时候。 首先,准备三个服务,Eureka 服务 + 提供 REST API 的两个简单的微服务,并将微服务注册到 Eureka。此处,不以任何方式限制这些应用程序的内存使用。 提示:Spring Cloud 简单应用的搭建示例:https://www.ictgu.cn/share/6644e468 就像你在下图看到的一样,三个微服务大概占用了电脑 1.5GB 的 RAM 内存。这三个服务是最简单的应用程序,基本没有数据处理量,对于这样的内存消耗量,显然是不理想的。RAM 的最低使用量是用于 Eureka发现服务,最大的用于初始...

在前两篇文章:服务网关(基础)、服务网关(路由配置)中,我们了解了Spring Cloud Zuul作为网关所具备的最基本功能:路由。本文我们将具体介绍一下Spring Cloud Zuul的另一项核心功能:过滤器。 过滤器的作用通过上面所述的两篇我们,我们已经能够实现请求的路由功能,所以我们的微服务应用提供的接口就可以通过统一的API网关入口被客户端访问到了。但是,每个客户端用户请求微服务应用提供的接口时,它们的访问权限往往都需要有一定的限制,系统并不会将所有的微服务接口都对它们开放。然而,目前的服务路由并没有限制权限这样的功能,所有请求都会被毫无保留地转发到具体的应用并返回结果,为了实现对客户端请求的安全校验和权限控制,最简单和粗暴的方法就是为每个微服务应用都实现一套用于校验签名和鉴别权限的过滤器或拦截器。不过,这样的做法并不可取,它会增加日后的系统维护难度,因为同一个系统中的各...

在上一篇《Spring Cloud构建微服务架构:服务网关(基础)》一文中,我们通过使用Spring Cloud Zuul构建了一个基础的API网关服务,同时也演示了Spring Cloud Zuul基于服务的自动路由功能。在本文中,我们将进一步详细地介绍关于Spring Cloud Zuul的路由功能,以帮助读者可以更好的理解和使用它,以完成更复杂的路由配置。 传统路由配置所谓的传统路由配置方式就是在不依赖于服务发现机制的情况下,通过在配置文件中具体指定每个路由表达式与服务实例的映射关系来实现API网关对外部请求的路由。 没有Eureka和Consul的服务治理框架帮助的时候,我们需要根据服务实例的数量采用不同方式的配置来实现路由规则: 单实例配置:通过一组zuul.routes.<route>.path与zuul.routes.<route>.url参数...

HelloPWS(Pivotal Web Service),由 Pivotal 公司提供的 ,可以运行Java, Grails, Play, Spring, Node.js, Ruby on Rails, Sinatra or Go 等Web应用的服务。本文将介绍一个 Hello World 级别的 Spring Boot 应用发布到 PWS 的过程。 武器 CentOS 7.3 OpenJDK 1.8.0_141 Maven 3.0.5 准备战斗1、在 https://run.pivotal.io/ 注册一个账号,完成手机绑定。 2、在 Github 上克隆一个 Spring Boot 的 hello world 的项目。 git clone https://github.com/spring-guides/gs-spring-boot.git 好戏开场1、安装 cf CLI ...

通过之前几篇Spring Cloud中几个核心组件的介绍,我们已经可以构建一个简略的(不够完善)微服务架构了。比如下图所示: 我们使用Spring Cloud Netflix中的Eureka实现了服务注册中心以及服务注册与发现;而服务间通过Ribbon或Feign实现服务的消费以及均衡负载;通过Spring Cloud Config实现了应用多环境的外部化配置以及版本管理。为了使得服务集群更为健壮,使用Hystrix的融断机制来避免在微服务架构中个别服务出现异常时引起的故障蔓延。 在该架构中,我们的服务集群包含:内部服务Service A和Service B,他们都会注册与订阅服务至Eureka Server,而Open Service是一个对外的服务,通过均衡负载公开至服务调用方。本文我们把焦点聚集在对外服务这块,这样的实现是否合理,或者是否有更好的实现方式呢? 先来说说这样架构...

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

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

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

本篇作为《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 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 ...

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

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

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

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