余思博客

写在前面在前面我们已经给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 ...

写在前面在前面我们成功的搭建起一个具备基本结构的配置管理服务端和客户端，也学习了一些基本的配置，接下来将进一步深入学习Spring Cloud Config中有关服务端的知识。 基础架构在学习服务端相关配置信息之前，先复习一下之前搭建的入门例子中使用的基础架构，如下图所示： 接下来好好分析一下上述架构，可以看到里面包含4种组件，5个元素，相关的分析如下所示： 远程Git仓库：用于存储配置文件，一般自己学习可以使用GitHub或者Gitee，公司一般会基于GitLab搭建属于自己的Git服务器。这里存放的就是针对应用名为config-server，但是application名为envy的多环境配置文件：envy-{ profile }.yml。 Config Server分布式配置中心：即此处构建的分布式配置中心（项目名称为config-server），里面配置了所要连接的Git仓库的位置、账户、密码等信息。 Config Server本地Git仓库：在Config Server的文件系统中，每次客户端请求获取配置信息时，Config Server从Git仓库中获取最新配置到本地，然 ...

SpringCloud Config是一个全新项目，用来为分布式系统中的基础设施和微服务应用提供集中化的外部配置支持，它分为服务端和客户端这两个部分。（建议使用properties格式的配置文件） 服务端也称为分布式配置中心，它是一个独立的微服务应用，用来连接配置仓库并为客户端提供获取配置信息、加密/解密信息等访问接口。 客户端则是微服务架构中的各个微服务应用或基础设施，它们通过指定的配置中心来管理应用资源与业务相关的配置内容，并在启动的时候从配置中心获取和加载配置信息。 SpringCloud Config实现了对服务端和客户端中环境变量和属性配置的抽象映射，因此它除了适用于Spring构建的应用程序，而且还可以在其他任何语言运行的应用程序中使用。 SpringCloud Config实现的配置中心默认采用Git来存储配置信息，所以使用SpringCloud Config构建的配置服务器，天然就支持对微服务应用配置信息的版本管理，而且可以通过Git客户端工具来方便地管理和访问配置内容。当然它也提供了对其他存储方式的支持，如SVN仓库，本地化文件系统。 快速入门接下来将演示如何构建一个 ...