Spring Cloud

已经有非常长的时间没有更新《Spring Cloud构建微服务架构》系列文章了,自从开始写Spring Cloud的专题内容开始就获得了不少的阅读量和认可,当然也有一些批评,其中也不乏一些很中肯的意见和深度的问题,对我来说也是进一步提高的契机,在此感谢所有关注我博客的读者们。 由于之前主要精力都花在的编写《Spring Cloud微服务实战》一书上,所以该系列文章就没有得到持续的维护和更新。由于漫长的写书过程和繁琐的出版流程,在本书一面世的时候,在版本上已经落后于当前的最新版本。虽然在书中前前后后加入了一些版本更新的注意事项,但是认识过程不是一蹴而就的,总是随着实践的深入慢慢发现的。所以,决定重写一下该系列文章,一方面将Spring Cloud的版本更新到Dalston,另一方面重新组织内容并增加一些之前没有写过的重要组件。希望通过这个系列,来帮助准备使用Spring Cloud的...

之前在我博客的问答平台和Spring4All社区均有关于Spring Cloud的发布策略实现问题。虽然大家都给力很多不错的思路和建议,但是都没有Charles He的这篇文章详细。因此经得作者同意,在这里转载了该篇内容,为了更好的阅读体验,稍作一些格式调整,分享给更多Spring Cloud爱好者。更多关于Spring Cloud的干货内容请持续关注我的博客和Spring4All社区。 Spring Cloud 实践源码地址:https://github.com/charlesvhe/spring-cloud-practice 项目结构config 配置中心端口:8888,方便起见直接读取配置文件,生产环境可以读取git。application-dev.properties为全局配置。先启动配置中心,所有服务的配置(包括注册中心的地址)均从配置中心读取。 consumer 服...

相信关注我们Spring Cloud中文社区(bbs.springcloud.com.cn)的朋友们最近已经在最新的横幅中发现了一个全新的社区:spring4all.com,相信从名字大家也能猜到该域名寓意Spring For All,那么我们为什么要重新创建这样一个社区呢? 关于Spring For All截止至今天,我们的论坛注册用户也已经有1000+名了,在维护Spring Cloud中文社区的过程中,我们收到了各种各样关于Spring Boot和Spring Cloud的不同问题。虽然我们论坛的核心定位在Spring Cloud,但是很多问题并非由Spring Cloud本身负责的,而是其他Spring项目所负责。那么为了说清楚这些内容,还是需要用户对Spring的其他相关项目有一定的了解之后才能弄明白其基本原理。 事实上,我们在实战过程中,就算采用了Spring Boo...

在前几天发布的《Spring Cloud实战小贴士:Zuul统一异常处理(一)》一文中,我们详细说明了当Zuul的过滤器中抛出异常时会发生客户端没有返回任何内容的问题以及针对这个问题的两种解决方案:一种是通过在各个阶段的过滤器中增加try-catch块,实现过滤器内部的异常处理;另一种是利用error类型过滤器的生命周期特性,集中地处理pre、route、post阶段抛出的异常信息。通常情况下,我们可以将这两种手段同时使用,其中第一种是对开发人员的基本要求;而第二种是对第一种处理方式的补充,以防止一些意外情况的发生。这样的异常处理机制看似已经完美,但是如果在多一些应用实践或源码分析之后,我们会发现依然存在一些不足。 不足之处下面,我们不妨跟着源码来看看,到底上面的方案还有哪些不足之处需要我们注意和进一步优化的。先来看看外部请求到达API网关服务之后,各个阶段的过滤器是如何进行调度的:...

在上一篇《Spring Cloud源码分析(四)Zuul:核心过滤器》一文中,我们详细介绍了Spring Cloud Zuul中自己实现的一些核心过滤器,以及这些过滤器在请求生命周期中的不同作用。我们会发现在这些核心过滤器中并没有实现error阶段的过滤器。那么这些过滤器可以用来做什么呢?接下来,本文将介绍如何利用error过滤器来实现统一的异常处理。 过滤器中抛出异常的问题首先,我们可以来看看默认情况下,过滤器中抛出异常Spring Cloud Zuul会发生什么现象。我们创建一个pre类型的过滤器,并在该过滤器的run方法实现中抛出一个异常。比如下面的实现,在run方法中调用的doSomething方法将抛出RuntimeException异常。 public class ThrowExceptionFilter extends ZuulFilter { pri...

通过之前发布的《Spring Cloud构建微服务架构(五)服务网关》一文,相信大家对于Spring Cloud Zuul已经有了一个基础的认识。通过前文的介绍,我们对于Zuul的第一印象通常是这样的:它包含了对请求的路由和过滤两个功能,其中路由功能负责将外部请求转发到具体的微服务实例上,是实现外部访问统一入口的基础;而过滤器功能则负责对请求的处理过程进行干预,是实现请求校验、服务聚合等功能的基础。然而实际上,路由功能在真正运行时,它的路由映射和请求转发都是由几个不同的过滤器完成的。其中,路由映射主要通过pre类型的过滤器完成,它将请求路径与配置的路由规则进行匹配,以找到需要转发的目标地址;而请求转发的部分则是由route类型的过滤器来完成,对pre类型过滤器获得的路由地址进行转发。所以,过滤器可以说是Zuul实现API网关功能最为核心的部件,每一个进入Zuul的HTTP请求都会经过...

由于我们在之前所有的入门教程中,对于HTTP请求都采用了简单的接口实现。而实际使用过程中,我们的HTTP请求要复杂的多,比如当我们将Spring Cloud Zuul作为API网关接入网站类应用时,往往都会碰到下面这两个非常常见的问题: 会话无法保持 重定向后的HOST错误 本文将帮助大家分析问题原因并给出解决这两个常见问题的方法。 会话保持问题通过跟踪一个HTTP请求经过Zuul到具体服务,再到返回结果的全过程。我们很容易就能发现,在传递的过程中,HTTP请求头信息中的Cookie和Authorization都没有被正确地传递给具体服务,所以最终导致会话状态没有得到保持的现象。 那么这些信息是在哪里丢失的呢?我们从Zuul进行路由转发的过滤器作为起点,来一探究竟。下面是RibbonRoutingFilter过滤器的实现片段: public class RibbonRouting...

今天在博客的交流区收到一条不错的问题,拿出来给大家分享一下。具体问题如下: 因为项目里面用到了redis集群,但并不是用spring boot的配置方式,启动后项目健康检查老是检查redis的时候状态为down,导致注册到eureka后项目状态也是down。问下能不能设置spring boot不检查 redis的健康状态 "redis": { "status": "DOWN", "error": "org.springframework.data.redis.RedisConnectionFailureException: Cannot get Jedis connection; nested exception is redis.clients.jedis.exceptions.JedisConnectionException: Could not g...

本文将继续讨论基于Consul的分布式锁实现。信号量是我们在实现并发控制时会经常使用的手段,主要用来限制同时并发线程或进程的数量,比如:Zuul默认情况下就使用信号量来限制每个路由的并发数,以实现不同路由间的资源隔离。 信号量(Semaphore),有时被称为信号灯,是在多线程环境下使用的一种设施,是可以用来保证两个或多个关键代码段不被并发调用。在进入一个关键代码段之前,线程必须获取一个信号量;一旦该关键代码段完成了,那么该线程必须释放信号量。其它想进入该关键代码段的线程必须等待直到第一个线程释放信号量。为了完成这个过程,需要创建一个信号量VI,然后将Acquire Semaphore VI以及Release Semaphore VI分别放置在每个关键代码段的首末端,确认这些信号量VI引用的是初始创建的信号量。如在这个停车场系统中,车位是公共资源,每辆车好比一个线程,看门人起的就是...

我们在构建分布式系统的时候,经常需要控制对共享资源的互斥访问。这个时候我们就涉及到分布式锁(也称为全局锁)的实现,基于目前的各种工具,我们已经有了大量的实现方式,比如:基于Redis的实现、基于Zookeeper的实现。本文将介绍一种基于Consul 的Key/Value存储来实现分布式锁以及信号量的方法。 分布式锁实现基于Consul的分布式锁主要利用Key/Value存储API中的acquire和release操作来实现。acquire和release操作是类似Check-And-Set的操作: acquire操作只有当锁不存在持有者时才会返回true,并且set设置的Value值,同时执行操作的session会持有对该Key的锁,否则就返回false release操作则是使用指定的session来释放某个Key的锁,如果指定的session无效,那么会返回false,否则就...

这是一篇翻译,关于大家经常质疑的一个问题:API网关Zuul的性能。原文:NETFLIX ZUUL VS NGINX PERFORMANCE作者:STANISLAV MIKLIK 如今你可以听到很多关于“微服务”的信息。Spring Boot是一个用来构建单个微服务应用的理想选择,但是你还需要以某种方式将它们互相联系起来。这就是Spring Cloud试图解决的问题,尤其是Spring Cloud Netflix。它提供了各种组件,比如:Eureka服务发现与Ribbon客户端负载均衡的结合,为内部“微服务”提供通信支持。但是,如果你想要与外界通信时(你提供外部API,或只是从你的页面使用AJAX),将各种服务隐藏在一个代理之后是一个明智的选择。 常规的选择我们会使用Nginx作为代理。但是Netflix带来了它自己的解决方案——智能路由Zuul。它带有许多有趣的功能,它可以用于...

太久没有更新,一时不知道该从哪儿开始,索性就从一个小技巧开始吧。 在之前的《Spring Cloud构建微服务架构》系列博文中,我们经常会需要启动多个实例的情况来测试注册中心、配置中心等基础设施的高可用,也会用来测试客户端负载均衡的调用等。但是,我们一个应用只能有一个端口号,这就使得在本机测试的时候,不得不为同一个服务设置不同的端口来进行启动。 在本地用不同端口启动同一服务实例的方法有很多。最传统的我们可以粗暴地修改配置文件中的server.port属性来分别启动多个实例,这种方法虽然可以实现,但是非常的不方便。比较好的一种方法是在启动的时候通过命令的方式为server.port属性来设置不同的值,这样我们的配置文件就不用反复的进行修改了。 在本文中,我们将介绍另外一种方法:采用随机端口的方式来设置各个服务实例,这样我们不用去编辑任何命令就可以在本地轻松地启动多个实例了。 使用随...

去年在博客上连载了《Spring Cloud构建微服务架构》的系列博文,虽然这部分内容得到了不少关注者们的支持,但是不得不说这些内容只是适用于Spring Cloud入门阶段对各个组件的初步认识。所以,今年除了将会继续更新《Spring Cloud构建微服务架构》系列的连载之外,准备再开一个新系列:《SpringCloud实战小贴士》,该系列文章内容将会聚焦在下面三个点上: 常见问题的解析 构建使用的技巧 实战设计的思考 开篇:Spring Cloud的版本依赖关系之前在《聊聊Spring Cloud版本的那些事儿》一文中,我们已经介绍了Spring Cloud版本命名的由来以及版本号的规则,并列举了各个版本的依赖内容,以帮助我们选择合适的版本进行微服务实践。 由于Spring Cloud的发展速度非常快,版本的更新非常频繁,同时成体系化的中文文档与教程又比较缺乏,所以很多初学者...

从去年6月开始编写《Spring Cloud构建微服务架构》系列博文开始,受到了不少同行的关注与支持。随后也开通了多个交流群、创建了相关的论坛(http://bbs.springcloud.cn),虽然Spring Cloud在国内变得越来越火热,但是这一块相关的书籍在国内外一直都还是处于空白状态。由于官方文档过于概要和简略,对于一些初学者来说学习门槛较高,所以从去年开始编写这本详细介绍Spring Cloud的书籍。希望能够帮助广大Spring Cloud关注者学习和使用它来帮助我们快速的构建起企业级的微服务架构系统。 Spring Cloud下属子项目非常之多,本书并未能覆盖所有。因此,在这里附上目录说明以及一些目前已经发布在博客的内容供所有Spring Cloud的支持者参详。 《Spring Cloud实战》目录第一章 基础知识 什么是微服务架构 与单体系统的区别 如何实施微...

当我们在Spring Cloud应用中使用Consul来实现服务治理时,由于Consul不会自动将不可用的服务实例注销掉(deregister),这使得在实际使用过程中,可能因为一些操作失误、环境变更等原因让Consul中存在一些无效实例信息,而这些实例在Consul中会长期存在,并处于断开状态。它们虽然不会影响到正常的服务消费过程,但是它们会干扰我们的监控,所以我们可以实现一个清理接口,在确认故障实例可以清理的时候进行调用来将这些无效信息清理掉。 开始以为只要简单的调用注销接口就能轻松完成,但是实际实践的发现并非如此。因此,分享一下整个实现过程以及中间遇到的一些坑。 借鉴Spring Cloud Consul在实现之初,先参考了Spring Cloud Consul在关闭程序时候实现的注销方法,具体如下: public class ConsulLifecycle extends A...