#Spring Cloud

Spring Cloud
应用场景我们在使用一些开源调度系统（比如：elastic-job等）的时候，对于任务的执行时间通常都是有规律性的，可能是每隔半小时执行一次，或者每天凌晨一点执行一次。然而实际业务中还存在另外一种定时任务，它可能需要一些触发条件才开始定时，比如：编写博文时候，设置2小时之后发送。对于这些开始时间不确定的定时任务，我们也可以通过Spring Cloud Stream来很好的处理。 为了实现开始时间不确定的定时任务触发，我们将引入延迟消息的使用。RabbitMQ中提供了关于延迟消息的插件，所以本文就来具体介绍以下如何利用Spring Cloud Stream以及RabbitMQ轻松的处理上述问题。 动手试试插件安装关于RabbitMQ延迟消息的插件介绍可以查看官方网站：https://www.rabbitmq.com/blog/2015/04/16/scheduling-messages-...

Spring Cloud
应用场景有的时候，我们对于同一通道中的消息处理，会通过判断头信息或者消息内容来做一些差异化处理，比如：可能在消息头信息中带入消息版本号，然后通过if判断来执行不同的处理逻辑，其代码结构可能是这样的： @StreamListener(value = TestTopic.INPUT)public void receiveV1(String payload, @Header("version") String version) { if("1.0".equals(version)) { // Version 1.0 } if("2.0".equals(version)) { // Version 2.0 }} 那么当消息处理逻辑复杂的时候，这段逻辑就会变得特别复杂。针对这个问题，...

Spring Cloud
应用场景之前我们已经通过《Spring Cloud Stream消费失败后的处理策略（一）：自动重试》一文介绍了Spring Cloud Stream默认的消息重试功能。本文将介绍RabbitMQ的binder提供的另外一种重试功能：重新入队。 动手试试准备一个会消费失败的例子，可以直接沿用前文的工程，也可以新建一个，然后创建如下代码的逻辑： @EnableBinding(TestApplication.TestTopic.class)@SpringBootApplicationpublic class TestApplication { public static void main(String[] args) { SpringApplication.run(TestApplication.class, args); } ...

Spring Cloud
应用场景前两天我们已经介绍了两种Spring Cloud Stream对消息失败的处理策略： 自动重试：对于一些因环境原因（如：网络抖动等不稳定因素）引发的问题可以起到比较好的作用，提高消息处理的成功率。 自定义错误处理逻辑：如果业务上，消息处理失败之后有明确的降级逻辑可以弥补的，可以采用这种方式，但是2.0.x版本有Bug，2.1.x版本修复。 那么如果代码本身存在逻辑错误，无论重试多少次都不可能成功，也没有具体的降级业务逻辑，之前在深入思考中讨论过，可以通过日志，或者降级逻辑记录的方式把错误消息保存下来，然后事后分析、修复Bug再重新处理。但是很显然，这样做非常原始，并且太过笨拙，处理复杂度过高。所以，本文将介绍利用中间件特性来便捷地处理该问题的方案：使用RabbitMQ的DLQ队列。 动手试试准备一个会消费失败的例子，可以直接沿用前文的工程。也可以新建一个，然后创建如下代...

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

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

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

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

Spring Cloud
介绍在今年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
由于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...

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

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

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