#Spring Cloud

应用场景上一篇《Spring Cloud Stream消费失败后的处理策略(一):自动重试》介绍了默认就会生效的消息重试功能。对于一些因环境原因、网络抖动等不稳定因素引发的问题可以起到比较好的作用。但是对于诸如代码本身存在的逻辑错误等,无论重试多少次都不可能成功的问题,是无法修复的。对于这样的情况,前文中说了可以利用日志记录消息内容,配合告警来做补救,但是很显然,这样做非常原始,并且太过笨拙,处理复杂度过高。所以,我们需要需求更好的办法,本文将介绍针对该类问题的一种处理方法:自定义错误处理逻辑。 动手试试准备一个会消费失败的例子,可以直接沿用前文的工程,也可以新建一个,然后创建如下代码的逻辑: @EnableBinding(TestApplication.TestTopic.class)@SpringBootApplicationpublic class TestApplic...

之前写了几篇关于Spring Cloud Stream使用中的常见问题,比如: 如何处理消息重复消费 如何消费自己生产的消息 下面几天就集中来详细聊聊,当消息消费失败之后该如何处理的几种方式。不过不论哪种方式,都需要与具体业务结合,解决不同业务场景可能出现的问题。 今天第一节,介绍一下Spring Cloud Stream中默认就已经配置了的一个异常解决方案:重试! 应用场景依然要明确一点,任何解决方案都要结合具体的业务实现来确定,不要有了锤子看什么问题都是钉子。那么重试可以解决什么问题呢?由于重试的基础逻辑并不会改变,所以通常重试只能解决因环境不稳定等外在因素导致的失败情况,比如:当我们接收到某个消息之后,需要调用一个外部的Web Service做一些事情,这个时候如果与外部系统的网络出现了抖动,导致调用失败而抛出异常。这个时候,通过重试消息消费的具体逻辑,可能在下一次调用的时...

在上一篇《Spring Cloud Stream如何处理消息重复消费》中,我们通过消费组的配置解决了多实例部署情况下消息重复消费这一入门时的常见问题。本文将继续说说在另外一个被经常问到的问题:如果微服务生产的消息自己也想要消费一份,应该如何实现呢? 常见错误在放出标准答案前,先放出一个常见的错误姿势和告警信息(以便您可以通过搜索引擎找到这里^_^)。以下错误基于Spring Boot 2.0.5、Spring Cloud Finchley SR1。 首先,根据入门示例,为了生产和消费消息,需要定义两个通道:一个输入、一个输出。比如下面这样: public interface TestTopic { String OUTPUT = "example-topic"; String INPUT = "example-topic"; @Output(OUTPUT)...

最近收到好几个类似的问题:使用Spring Cloud Stream操作RabbitMQ或Kafka的时候,出现消息重复消费的问题。通过沟通与排查下来主要还是用户对消费组的认识不够。其实,在之前的博文以及《Spring Cloud微服务实战》一书中都有提到关于消费组的概念以及作用。 那么什么是消费组呢?为什么要用消费组?它解决什么问题呢?摘录一段之前博文的内容,来解答这些疑问: 通常在生产环境,我们的每个服务都不会以单节点的方式运行在生产环境,当同一个服务启动多个实例的时候,这些实例都会绑定到同一个消息通道的目标主题(Topic)上。默认情况下,当生产者发出一条消息到绑定通道上,这条消息会产生多个副本被每个消费者实例接收和处理(出现上述重复消费问题)。但是有些业务场景之下,我们希望生产者产生的消息只被其中一个实例消费,这个时候我们需要为这些消费者设置消费组来实现这样的功能。 详细...

由于Spring Cloud对Etcd的支持一直没能从孵化器中出来,所以目前来说大多用户还在使用Eureka和Consul,之前又因为Eureka 2.0不在开源的消息,外加一些博眼球的标题党媒体使得Eureka的用户有所减少,所以,相信在选择Spring Cloud的用户群体中,应该有不少用户会选择Consul来做服务注册与发现。 本文就来说一下,当我们使用Spring Cloud最新的Finchley版 + Consul 1.2.x时候最严重的一个坑:多实例注册的问题。 问题解读问题:该问题可能在开发阶段不一定会发现,但是在线上部署多实例的时候,将会发现Consul中只有一个实例。 原因:造成该问题的主要原因是Spring Cloud Consul在注册的时候实例名(InstanceId)采用了:“服务名-端口号”(即:{spring.application.name}-{s...

最近一致在更新Spring Cloud Config的相关内容,主要也是为这篇埋个伏笔,相信不少调研过Spring Cloud Config的用户都会吐槽它的管理能力太弱。因此,就有了下面为讲推荐的这个开源项目,希望对已经入坑Spring Cloud Config的童鞋们有所帮助! 简介在Spring Cloud的微服务架构方案中虽然提供了Spring Cloud Config来担任配置中心的角色,但是该项目的功能在配置的管理层面还是非常欠缺的。初期我们可以依赖选取的配置存储系统(比如:Gitlab、Github)给我们提供的配置管理界面来操作所有的配置信息,但是这样的管理还是非常粗粒度的,因此这个项目的目的就是解决这个问题,通过此项目,我们将提供一套基于Spring Cloud Config配置中心的可视化管理系统。 在该项目中,我们对于服务治理、配置存储、可视化操作都做了抽象...

介绍在今年5月中,Netflix终于开源了它的支持异步调用模式的Zuul网关2.0版本,真可谓千呼万唤始出来。从Netflix的官方博文[附录1]中,我们获得的信息也比较令人振奋: The Cloud Gateway team at Netflix runs and operates more than 80 clusters of Zuul 2, sending traffic to about 100 (and growing) backend service clusters which amounts to more than 1 million requests per second. Netflix部署了超过80+的Zuul2云网关集群,流量经过Zuul2集群被路由到后端超过100+的微服务,且每秒钟经过Zuul2集群的请求超过100万。 Zuul2看起来很强大,支持...

由于Spring Cloud Config默认采用了Git存储,相信很多团队在使用Spring Cloud的配置中心时也会采用这样的策略。即便大家都使用了Git存储,可能还有各种不同的配置方式,本文就来介绍一下两种常用的配置策略。 第一种:多个项目公用一个Git仓库,用不同的目录区分项目 主要的配置项如下: spring.cloud.config.server.git.uri=https://github.com/dyc87112/config-repo.gitspring.cloud.config.server.git.search-paths=/{application} 这种模式下不同的项目会对应到https://github.com/dyc87112/config-repo.git仓库下的不同目录,如果项目中spring.application.nam...

最近连续发烧四天,偶尔刷两下朋友圈都能看到好几条来自不同号的关于《Eureka 2.0开源工作宣告停止,继续使用风险自负》的推文。主要内容如下: 近日,知名服务注册与服务发现工具 Eureka 的 GitHub Wiki 上显示其 2.0 版本的开源工作已经停止。这意味着如果开发者继续使用作为 2.x 分支上现有工作 repo 一部分发布的代码库和工件,则将自负风险,对此,专家建议开发者尽快将相关业务迁移到 Consul/ZooKeeper/Etcd 等工具上。 目前从本人平时收到的咨询问题上看,国内使用Eureka的用户群体还是比较多的,这则消息也引起了一些不满的情绪。那么大家是否值得要做如上文中“专家”所说的迁移这样有风险的操作呢? 我觉得在做迁移决定之前,您应该先需要明确一个问题:您到底是不是Eureka 2.x的用户?相信大多数在使用Eureka的用户都是由于Spring...

通过之前Spring Cloud系列教程中的《Spring Cloud构建微服务架构:服务容错保护(Hystrix服务降级)》一文,我们已经知道如何通过Hystrix来保护自己的服务不被外部依赖方拖垮的情况。但是实际使用过程中经常碰到开发反应“莫名”触发了降级逻辑的情况。为了更精准的定位触发原因,或是在降级逻辑中需要根据不同的异常做不同的处理时,在降级方法中,我们希望可以获取到主逻辑中抛出的异常信息。接下来就来介绍一下Hystrix两种不同实现方式中如何在降级逻辑中获取异常信息的方法。 注解方式先介绍一下用注解方式定义的Hystrix命令是如何在降级逻辑中获取异常的,实现非常简单,先看下面的例子: @HystrixCommand(fallbackMethod = "fallback")User getUserById(String id) { throw new Ru...

在之前的《Spring Cloud构建微服务架构:分布式配置中心》一文中,我们介绍的Spring Cloud Server配置中心采用了Git的方式进行配置信息存储。这一设计巧妙的利用Git自身机制以及其他具有丰富功能的Git服务端产品,让Spring Cloud Server在配置存储和管理的上避开了很多与管理相关的复杂实现,使其具备了配置中心存储配置和读取配置的基本能力;而更上层的管理机制,由于不具备普遍适用性,所以Spring Cloud Server并没有自己去实现这部分内容,而是通过Git服务端产品来提供一部分实现,如果还需要更复杂的功能也能自己实现与定义。即便如此,对于Spring Cloud Server默认使用Git来存储配置的方案一直以来还是饱受争议。所以,本文将介绍一下Spring Cloud Config从Edgware版本开始新增的一种配置方式:采用数据库存储...

Swagger Butler是一个基于Swagger与Zuul构建的API文档汇集工具。通过构建一个简单的Spring Boot应用,增加一些配置就能将现有整合了Swagger的Web应用的API文档都汇总到一起,方便查看与测试。 项目地址 Github:https://github.com/dyc87112/swagger-butler Gitee:https://gitee.com/didispace/swagger-butler 快速入门该工具的时候非常简单,先通过下面几步简单入门: 第一步:构建一个基础的Spring Boot应用 如您还不知道如何创建Spring Boot应用,可以先阅读本篇入门文章 第二步:在pom.xml中引入依赖 <parent> <groupId>org.springframework.boot</groupI...

Swagger Butler是一个基于Swagger与Zuul构建的API文档汇集工具。通过构建一个简单的Spring Boot应用,增加一些配置就能将现有整合了Swagger的Web应用的API文档都汇总到一起,方便查看与测试。 项目地址 Github:https://github.com/dyc87112/swagger-butler Gitee:https://gitee.com/didispace/swagger-butler 使用手册快速入门该工具的时候非常简单,先通过下面几步简单入门: 第一步:构建一个基础的Spring Boot应用 如您还不知道如何创建Spring Boot应用,可以先阅读本篇入门文章 第二步:在pom.xml中引入依赖 <parent> <groupId>org.springframework.boot</gr...

有很多读者问过这样的一个问题:虽然使用Swagger可以为Spring MVC编写的接口生成了API文档,但是在微服务化之后,这些API文档都离散在各个微服务中,是否有办法将这些接口都整合到一个文档中?之前给大家的回复都只是简单的说了个思路,昨天正好又有人问起,索性就举个例子写成博文供大家参考吧。 如果您还不了解Spring Cloud Zuul和Swagger,建议优先阅读下面两篇,有一个初步的了解: Spring Cloud构建微服务架构:服务网关(基础) Spring Boot中使用Swagger2构建强大的RESTful API文档 准备工作上面说了问题的场景是在微服务化之后,所以我们需要先构建两个简单的基于Spring Cloud的微服务,命名为swagger-service-a和swagger-service-b。 下面只详细描述一个服务的构建内容,另外一个只是名...

如果您跟我一样,目前正在使用Spring Cloud Config做为配置中心的话,本篇将来要描述的问题,强烈推荐了解和关注!因为这个问题目前存在于所有的版本中,还没有完全修复。 问题现象为了说明下面的内容,我们可以先尝试重现一下问题:在一个测试环境中,将Spring Cloud Config的配置中心迁移到另外一个节点上,即配置中心的IP地址发生了变化。在完成迁移之后,我们会发现该环境下各个微服务应用的健康状态会变得时好时坏,并且在日志中会出现类似下面的报错: 2018-05-13 17:01:28,569 WARN [http-nio-9920-exec-1] org.springframework.cloud.config.client.ConfigServerHealthIndicator - Health check failedjava.lang.IllegalSt...