weixin_41213402的博客

前言通过之前的学习，我们已经能够利用ELK平台提供的收集、存储、搜索等强大功能，对跟踪信息的管理和使用已经变得非常便利。但是，在ELK平台中的数据分析维度缺少对请求链路中各阶段时间延迟的关注，很多时候我们追溯请求链路的一个原因是为了找出整个调用链路中出现延迟过高的瓶颈源，亦或是为了实现对分布式系统做延迟监控等与时间消耗相关的需求，这时候类似ELK这样的日志分析系统就显得有些乏力了。对于这样的问题，我们就可以引入Zipkin来得以轻松解决。Zipkin简介Zipkin是Twitter的一个开源项目，它基

前言前文我们已经使用Spring Cloud Sleuth实现了为各微服务的日志信息中添加跟踪信息的功能，但是如果日志文件都离散的存储在各个服务实例的文件系统之上，仅仅通过查看日志文件来分析我们的请求链路依然是一件相当麻烦的差事，所以我们还需要一些工具来帮助我们集中的收集、存储和搜索这些跟踪信息。引入基于日志的分析系统是一个不错的选择，比如：ELK平台，它可以轻松的帮助我们来收集和存储这些跟踪日志，同时在需要的时候我们也可以根据Trace ID来轻松地搜索出对应请求链路相关的明细日志。ELK平台主要有由

前言通过前一篇的学习，我们已经通过Spring Cloud Sleuth往微服务应用中添加了实现分布式跟踪具备的基本要素。分布式系统中的服务跟踪在理论上并不复杂，它主要包括下面两个关键点：为了实现请求跟踪，当请求发送到分布式系统的入口端点时，只需要服务跟踪框架为该请求创建一个唯一的跟踪标识，同时在分布式系统内部流转的时候，框架始终保持传递该唯一标识，直到返回给请求方为止，这个唯一标识就是前文中提到的Trace ID。通过Trace ID的记录，我们就能将所有请求过程日志关联起来。为了统计各处理单元

前言之前文章我们已经了解到搭建微服务架构的常用组件，使用它们搭建起一个基础的微服务架构系统来实现我们的业务需求了。但是，随着业务的发展，我们的系统规模也会变得越来越大，各微服务间的调用关系也变得越来越错综复杂。这时，一个Rerquest访问系统，链路会经过后端不同的服务，这样每个请求都会有复杂的请求链，那链路跟踪日志就很有必要引入，它能帮助我们快速的发现错误根源以及监控分析每条请求链路上的性能瓶颈等好处。Spring Cloud Sleuth快速入门在介绍各种概念与原理之前，我们先通过实现一个简单的

前言之前我们介绍了会生效的消息重试功能，对于一些因环境原因、网络抖动等不稳定因素引发的问题可以起到比较好的作用。但是对于诸如代码本身存在的逻辑错误等，无论重试多少次都不可能成功的问题，是无法修复的。对于这样的情况，前文中说了可以利用日志记录消息内容，配合告警来做补救，但是很显然，这样做非常原始，并且太过笨拙，处理复杂度过高。针对该类问题的一种处理方法：自定义错误处理逻辑。自定义错误处理逻辑示例准备一个会消费失败的例子，可以直接沿用前文的工程，也可以新建一个，然后创建如下代码的逻辑：@Enabl

前言之前我们已经了解到怎么Spring cloud stream的基本使用，下面我们了解一下，当消息消费失败之后该如何处理的几种方式。不过不论哪种方式，都需要与具体业务结合，解决不同业务场景可能出现的问题。自动重试应用场景重试可以解决什么问题呢？由于重试的基础逻辑并不会改变，所以通常重试只能解决因环境不稳定等外在因素导致的失败情况，比如：当我们接收到某个消息之后，需要调用一个外部的Web Service做一些事情，这个时候如果与外部系统的网络出现了抖动，导致调用失败而抛出异常。这个时候，通过重试消息

前言我们通过消费组的配置解决了多实例部署情况下消息重复消费这一入门时的常见问题。本文将继续说说在另外一个被经常问到的问题：如果微服务生产的消息自己也想要消费一份，应该如何实现呢？常见错误在放出标准答案前，先放出一个常见的错误姿势和告警信息首先，根据入门示例，为了生产和消费消息，需要定义两个通道：一个输入、一个输出。比如下面这样：public interface TestTopic { String OUTPUT = "example-topic"; String INPUT =

前言通过之前的学习，我们已经能够在多实例环境下，保证同一消息只被一个消费者实例进行接收和处理。但是，对于一些特殊场景，除了要保证单一实例消费之外，还希望那些具备相同特征的消息都能够被同一个实例进行消费。这时候我们就需要对消息进行分区处理。使用消息分区在Spring Cloud Stream中实现消息分区非常简单，我们可以根据消费组示例做一些配置修改就能实现，具体如下：在消费者应用SinkReceiver中，我们对配置文件做一些修改，具体如下：spring.cloud.stream.bindin

前言通过之前的文章，我们已经对Spring cloud stream有了大概的理解，比如：输入、输出通道的绑定，通道消息事件的监听等。这篇文章，我们将详细介绍一下Spring Cloud Stream中是如何通过定义一些基础概念来对各种不同的消息中间件做抽象的。结构模型通过上图，我们可以了解到以下信息：Spring Cloud Stream构建的应用程序与消息中间件之间是通过绑定器Binder相关联的，绑定器对于应用程序而言起到了隔离作用，它使得不同消息中间件的实现细节对应用程序来说是透明的。C

前言Spring Cloud Stream是什么？Spring Cloud Stream是一个用来为微服务应用构建消息驱动能力的框架。引入了发布-订阅、消费组以及消息分区这三个核心概念，可以有效地简化开发人员对消息中间件的使用复杂度，让系统开发人员可以有更多的精力关注于核心业务逻辑的处理。由于Spring Cloud Stream基于Spring Boot实现，所以它秉承了Spring Boot的优点，实现了自动化配置的功能帮忙我们可以快速的上手使用，但是目前为止Spring Cloud Stream只