余思博客

写在前面默认情况下，Zipkin Server会将跟踪信息存储在内存中，但是当用户每次重启Zipkin Server时，都会将之前收集的跟踪信息进行删除，并且当有大量跟踪信息时存储在内存中肯定是不行的，因此正确的做法是将数据持久化到外部存储磁盘中，使用MySQL来进行存储，也可以将其输出到ElasticSearch中存储存储，这两种方式本文都会详细介绍。 数据持久化持久化到MySQL中MySQL简介MySQL是一款优秀的开源关系型数据库，因其速度、可靠性和适应性而备受关注。大多数人都认为在不需要事务化处理的情况下，MySQL是管理内容最好的选择。 持久化到MySQL流程请注意zipkin默认是支持HTTP实现的收集，因此需要将现在基于RabbitMQ消息中间件实现的方式注释掉，后期会介绍如何将基于消息中间件的收集持久化到MySQL数据库中。 第一步，在MySQL中创建用于Zipkin存储的Schema。由于笔者使用的zipkin-server版本是2.12.6，因此首先需要点击 这里选择自己对应版本的readme.md文档进行阅读，往下看到Applying the schema部分，找 ...

写在前面虽然通过ELK日志分析平台提供的收集、存储、搜索等功能，我们已经非常轻松的实现对跟踪信息的管理，但是在ELK平台中缺乏对请求链路中各阶段时间延迟的关注，很多时候我们追溯请求链路的一个原因，就是为了找出整个调用链路中出现延迟过高的瓶颈，或者为了实现对分布式系统做延迟监控等与时间消耗相关的需求，也就是说此时的ELK平台是无法满足我们的要求，应当引入Zipkin框架来解决。 ZipkinZipkin是Twitter的一个开源项目，它基于Google Dapper实现。开发者可以使用它来收集各个服务器上请求链路的跟踪数据，并通过它提供的RESTful API接口来辅助查询跟踪数据，以实现对分布式系统的监控，从而及时发现系统中出现的延迟升高问题，并找出系统性能瓶颈的源头。Zipkin除了提供面向开发的API接口外，它还提供了方便的UI组件来帮助我们直观地跟踪信息和分析请求链路明细，如可以查询某段时间内各用户请求的处理时间。 Zipkin基本概念（1）Span：它是Zipkin的基本工作单元，一次链路调用就会创建一个Span。 （2）Trace：它是一组Span的集合，表示一条调用链路。举 ...

写在前面在前面我们已经给trace-one和trace-two项目引入了Spring Cloud Sleuth的基础模块spring-cloud-starter-sleuth，实现了在各个微服务的日志信息中添加跟踪信息的功能。 但是问题来了，这些日志文件都是分散存储在各个服务实例的文件系统上，因此还需要借助于一些工具来帮助集中收集、存储和搜索这些跟踪信息。一般来说可以使用基于日志的分析系统，如ELK，它可以很轻松的帮助我们收集和存储这些跟踪日志，同时在需要的时候也可以根据TraceID来轻松地搜索出对应请求链路相关的明细日志。 ELK由ElasticSearch、Logstash和Kibana三个开源工具组成。其中ElasticSearch是一个开源的分布式搜索引擎，它可以支持分布式、零配置、自动发现、索引自动分片、索引副本机制、RESTful风格接口，多数据源、自动搜索负载等。 Logstash是一个完全开源的工具，它可以对日志进行收集、过滤，并将其进行存储以被后续使用。 Kibana也是一个开源工具，它可以为Logstash和ElasticSearch提供日志分析的Web界面，也可 ...

写在前面通过前面的学习，我们已经可以搭起一个基础的微服务架构系统用于实现业务需求，但是随着业务的发展，系统的规模变得越来越大，各服务间的调用关系也变得错综复杂。一般来说，客户端发起一个请求后，在后端系统中会经过多个不同的微服务调用来协同产生最后的请求结果。在复杂的微服务架构系统中，几乎每一个前端请求都会形成一条复杂的分布式服务调用链路，在每条链路中任何一个依赖服务出现延迟过高或者错误的时候，都有可能导致请求最后的失败。此时对于每一个请求，全链路调用的跟踪就显得尤为重要，通过对请求的调用跟踪可以帮助我们快速发现错误根源以及监控分析每条请求链路上的性能瓶颈等。 对于分布式服务的跟踪问题，Spring Cloud Sleuth提供了一套完整的解决方案，接下来就学习如何使用Spring Cloud Sleuth。 入门演示项目准备为了后续学习Spring Cloud Sleuth，这里需要先做一些准备工作，来构建一些基础的设施和应用。 第一步，构建一个服务注册中心当然可以使用之前的eureka-server项目； 第二步，构建两个微服务应用，名称为trace-one和trace-two。其中t ...

写在前面在前面我们学习了使用消息总线Spring Cloud Bus组件来整合RabbitMQ和Kafka等消息中间件，接下来开始学习另一个组件Spring Cloud Stream，被称为是消息驱动的微服务。它可以基于Spring Boot来创建独立的、可用于生产的Spring应用程序。同时它通过使用Spring Interation来连接消息代理中间件以实现消息事件的驱动。 Spring Cloud Stream为一些中间件产品提供了个性化的自动化配置实现，并且引入了发布-订阅、消费组以及分区这三个核心概念。简单的说,Spring Cloud Stream本质上就是整合了Spring Boot和Spring Interation，实现了一套轻量级的消息驱动的微服务框架。使用Spring Cloud Stream可以有效的简化开发人员对于消息中间件的使用复杂度，让系统开发人员可以将更多的精力专注于核心业务逻辑的处理。目前为止Spring Cloud Stream支持RabbitMQ和Kafka这两个消息中间件，但是相信在不久的将来会有更多的中间件加入其中。 快速入门接下来通过一个简单 ...

写在前面前面学习了Spring Cloud Bus整合RabbitMQ的相关内容，接下来开始学习Spring Cloud Bus整合Kafka，同样也能实现消息总线的功能。 Kafka简介Kafka是一个由LinkedIn开发的分布式消息系统，于2011年年初开源，现在由Apache基金会负责维护与开发。Kafka使用Scala语言编写，被用作LinkedIn的活动流和运营数据处理的管道，现在也被许多企业广泛用作数据流管道和消息系统。 Kafka设计目标Kafka是基于消息发布-订阅模式实现的消息系统，其主要的设计目标如下：（1）消息持久化。以时间复杂度为O(1)的方式提供消息持久化能力，对于TB级别以上的数据也能保证常数时间复杂度的访问性能。（2）高吞吐。在廉价的商用机器上也可以支持单机每秒1万条以上的吞吐量。（3）分布式。支持消息分区以及分布式消费，并保证分区内的消息顺序。（4）跨平台。支持不同语言的客户端，如Java、PHP、Python等。（5）实时性。支持实时数据处理和离线数据处理。（6）伸缩性。支持水平扩展。 Kafka中的一些基本概念同样Kafka中有一些比较重要的基础概 ...

写在前面前面我们只是单纯的介绍了消息代理、AMQP以及RabbitMQ的基础知识和基本使用，接下来我们开始学习Spring Cloud Bus组件的配置，并一个Spring Cloud Bus与Spring Cloud Config结合的例子来实现配置信息的实时更新。 不过在此之前需要回忆一下前面的知识，在学习Spring Cloud Config的时候我们学习了如何实现配置信息的实时更新：通过使用POST方法来提交/refresh接口或者Git仓库的Web Hook来手动触发，进而实现Git仓库中的内容修改导致程序属性的更新。显然这种方式是不合理的，所有操作都是人工进行，随着系统的不断扩展，这势必会导致维护成本的增加，使用消息代理中间件可以很好的解决这个问题，因为它可以将消息路由到一个或者多个目的地。 由于Spring Cloud基于Spring Boot，而在前面我们已经进行了Spring Boot和RabbitMQ的整合，那么接下来就是在Spring Cloud Bus中使用RabbitMQ了。 请注意，这里不需要创建新的应用，而是使用到前面关于Spring Cloud Conf ...

写在前面在微服务的架构系统中，我们通常会使用轻量级的消息代理来构建一个共用的消息主题，让系统中所有微服务实例都连接上来，由于该主题中产生的消息会被所有实例监听和消费，因此我们称之为消息总线。在消息总线上的各个实例都可以方便地广播一些需要让其他连接在该主题上的实例都知道的消息，如配置信息的变更或者其他一些管理操作。 在前面我们学习了分布式配置组件Spring Cloud Config，接下来开始学习另一个和它同等重要的组件：消息总线SpringCloud Bus，不过我们会从基础的消息代理入手，一步步的由浅入深学习Spring Cloud Bus这个消息总线组件。通过使用Spring Cloud Bus消息总线，我们可以非常容易的搭建起消息总线，同时实现了一些消息总线中的常用功能，如配合Spring Cloud Config实现微服务应用配置信息的动态更新等。 消息代理消息代理(Message Broker)是一种消息验证、传输、路由的架构模式。它在应用程序之间起到通信调度并最小化应用之间的依赖的作用，使得应用可以高效地解耦通信过程。消息代理是一个中间件产品，它的核心是一个消息的路由程序 ...

写在前面前面我们对Spring Cloud Config分布式配置中心的服务端进行了较为细致的学习，接下来开始学习对于客户端的配置。 URI指定配置中心在前面我们在config-client项目的bootstrap.properties启动文件中添加了spring.cloud.config.uri=http://localhost:4001/这一参数，用于指定配置中心的地址。那么问题来了，为什么需要通过手动来设置配置中心的地址呢？因为Spring Cloud Config的客户端在启动的时候，默认会从工程的classpath中加载配置信息并启动应用。只有我们配置了spring.cloud.config.uri这一参数的时候，客户端应用才会尝试连接Spring Cloud Config的服务端来获取远程配置信息并初始化Spring环境配置。同时在前面也多次提到，必须将该参数配置在bootstrap.properties启动文件、环境变量或是其他优先级高于应用Jar包内的配置信息中，这样客户端才能正确加载到远程配置。 如果开发者不配置spring.cloud.config.uri这一参数， ...

健康监测当使用占位符来配置URI的时候，Spring Cloud Config会为配置中心服务端创建一个健康监测器，该检测器中默认构建了一个application为app的仓库。而根据之前的配置规则：{application}-config.git，该检测器会不断地检查https://github.com/licheetools/app-config仓库是否可以连通（此处的app就是上面的{application}）。此时我们可以访问配置中心的/health端点来查看它的健康状态，如果无法连通https://github.com/licheetools/app-config仓库，那么配置中心的可用状态将是DOWN。虽然我们依然可以通过URI的方式来访问该配置中心，但是当我们将这个配置中心当做一个服务来使用的时候，那么它的状态将会影响到它的服务可用性判断，因此了解它的健康监测配置对于微服务架构来说显得尤为重要。 其实我们可以直接在Git仓库中创建一个名为app-config的配置库，让健康检测器能够访问到它。当然了，我们也可以配置一个实际存在的仓库来进行连通检测。举个例子，笔者已经在Gi ...