#Spring Cloud

Spring Boot
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...

Spring Cloud
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...

Spring Cloud
有很多读者问过这样的一个问题：虽然使用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
如果您跟我一样，目前正在使用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...

Spring Cloud
之前写过一篇关于配置中心对配置内容加密解密的介绍：《Spring Cloud构建微服务架构：分布式配置中心（加密解密）》。在这篇文章中，存在一个问题：当被加密内容包含一些诸如=、+这些特殊字符的时候，使用上篇文章中提到的类似这样的命令curl localhost:7001/encrypt -d去加密和解密的时候，会发现特殊字符丢失的情况。 比如下面这样的情况： $ curl localhost:7001/encrypt -d eF34+5edo=a34c76c4ddab706fbcae0848639a8e0ed9d612b0035030542c98997e084a7427$ curl localhost:7001/decrypt -d a34c76c4ddab706fbcae0848639a8e0ed9d612b0035030542c98997e084a7427eF34 5edo 可...

Spring Cloud
在微服务架构中，我们通常都会采用DevOps的组织方式来降低因团队间沟通造成的巨大成本，以加速微服务应用的交付能力。这就使得原本由运维团队控制的线上信息将交由微服务所属组织的成员自行维护，其中将会包括大量的敏感信息，比如：数据库的账户与密码等。很显然，如果我们直接将敏感信息以明文的方式存储于微服务应用的配置文件中是非常危险的。针对这个问题，Spring Cloud Config提供了对属性进行加密解密的功能，以保护配置文件中的信息安全。比如下面的例子： spring.datasource.username=didispring.datasource.password={cipher}dba6505baa81d78bd08799d8d4429de499bd4c2053c05f029e7cfbf143695f5b 在Spring Cloud Config中通过在属性值...

Spring Cloud
前言上篇文章《Spring Cloud中Hystrix 线程隔离导致ThreadLocal数据丢失》我们对ThreadLocal数据丢失进行了详细的分析，并通过代码的方式复现了这个问题。 在上篇文章的末尾我也说了思路给大家提供了，如果需要能够在Hystrix 为线程隔离模式也能正确传递数据的话，需要我们自己去修改。 我这边以Zuul中自定义负载均衡策略来进行讲解，在Zuul中需要实现灰度发布的功能，需要在Filter中将请求的用户信息传递到自定的负载策略中，Zuul中整合了Hystrix，从Zuul Filter的请求到Ribbon的策略类中，线程已经发生了变化，变成了Hystrix提供的线程池来执行（配置隔离模式为线程）。这个时用ThreadLocal就会出问题了，数据传输会错乱。也就是我们前面分析的问题。 关于修改我说下自己分析问题的一些思路，ransmittable-threa...

Spring Cloud
在Spring Cloud中我们用Hystrix来实现断路器，Zuul中默认是用信号量（Hystrix默认是线程）来进行隔离的，我们可以通过配置使用线程方式隔离。 在使用线程隔离的时候，有个问题是必须要解决的，那就是在某些业务场景下通过ThreadLocal来在线程里传递数据，用信号量是没问题的，从请求进来，但后续的流程都是通一个线程。 当隔离模式为线程时，Hystrix会将请求放入Hystrix的线程池中去执行，这个时候某个请求就有A线程变成B线程了，ThreadLocal必然消失了。 下面我们通过一个简单的列子来模拟下这个流程： public class CustomThreadLocal { static ThreadLocal<String> threadLocal = new ThreadLocal<>(); public st...

Spring Cloud
在Spring Cloud封装的Feign中并不直接支持传文件，但可以通过引入Feign的扩展包来实现，本来就来具体说说如何实现。 服务提供方（接收文件）服务提供方的实现比较简单，就按Spring MVC的正常实现方式即可，比如： @EnableFeignClients@EnableDiscoveryClient@SpringBootApplicationpublic class Application { @RestController public class UploadController { @PostMapping(value = "/uploadFile", consumes = MediaType.MULTIPART_FORM_DATA_VALUE) public String handleFileUploa...

Spring Cloud
通过Trace ID和Span ID已经实现了对分布式系统中的请求跟踪，而这些记录的跟踪信息最终会被分析系统收集起来，并用来实现对分布式系统的监控和分析功能，比如：预警延迟过长的请求链路、查询请求链路的调用明细等。此时，我们在对接分析系统时就会碰到一个问题：分析系统在收集跟踪信息的时候，需要收集多少量的跟踪信息才合适呢？ 理论上来说，我们收集的跟踪信息越多就可以更好的反映出系统的实际运行情况，并给出更精准的预警和分析，但是在高并发的分布式系统运行时，大量的请求调用会产生海量的跟踪日志信息，如果我们收集过多的跟踪信息将会对我们整个分布式系统的性能造成一定的影响，同时保存大量的日志信息也需要不少的存储开销。所以，在Sleuth中采用了抽象收集的方式来为跟踪信息打上收集标记，也就是我们之前在日志信息中看到的第四个boolean类型的值，它代表了该信息是否要被后续的跟踪信息收集器获取和存储。...

Spring Cloud
在本节内容之前，我们已经对如何引入Sleuth跟踪信息和搭建Zipkin服务端分析跟踪延迟的过程做了详细的介绍，相信大家对于Sleuth和Zipkin已经有了一定的感性认识。接下来，我们介绍一下关于Zipkin收集跟踪信息的过程细节，以帮助我们更好地理解Sleuth生产跟踪信息以及输出跟踪信息的整体过程和工作原理。 数据模型 我们先来看看Zipkin中关于跟踪信息的一些基础概念。由于Zipkin的实现借鉴了Google的Dapper，所以它们有着类似的核心术语，主要有下面几个内容： Span：它代表了一个基础的工作单元。我们以HTTP请求为例，一次完整的请求过程在客户端和服务端都会产生多个不同的事件状态（比如下面所说的四个核心Annotation所标识的不同阶段），对于同一个请求来说，它们属于一个工作单元，所以同一HTTP请求过程中的四个Annotation同属于一个Span。每一...

Spring Cloud
通过上一篇《分布式服务跟踪（整合logstash）》，我们虽然已经能够利用ELK平台提供的收集、存储、搜索等强大功能，对跟踪信息的管理和使用已经变得非常便利。但是，在ELK平台中的数据分析维度缺少对请求链路中各阶段时间延迟的关注，很多时候我们追溯请求链路的一个原因是为了找出整个调用链路中出现延迟过高的瓶颈源，亦或是为了实现对分布式系统做延迟监控等与时间消耗相关的需求，这时候类似ELK这样的日志分析系统就显得有些乏力了。对于这样的问题，我们就可以引入Zipkin来得以轻松解决。 Zipkin简介Zipkin是Twitter的一个开源项目，它基于Google Dapper实现。我们可以使用它来收集各个服务器上请求链路的跟踪数据，并通过它提供的REST API接口来辅助我们查询跟踪数据以实现对分布式系统的监控程序，从而及时地发现系统中出现的延迟升高问题并找出系统性能瓶颈的根源。除了面向...

Spring Cloud
通过之前的入门示例，我们已经为trace-1和trace-2引入了Spring Cloud Sleuth的基础模块spring-cloud-starter-sleuth，实现了为各微服务的日志信息中添加跟踪信息的功能。但是，由于日志文件都离散的存储在各个服务实例的文件系统之上，仅仅通过查看日志文件来分析我们的请求链路依然是一件相当麻烦的差事，所以我们还需要一些工具来帮助我们集中的收集、存储和搜索这些跟踪信息。引入基于日志的分析系统是一个不错的选择，比如：ELK平台，它可以轻松的帮助我们来收集和存储这些跟踪日志，同时在需要的时候我们也可以根据Trace ID来轻松地搜索出对应请求链路相关的明细日志。 ELK平台主要有由ElasticSearch、Logstash和Kiabana三个开源免费工具组成： Elasticsearch是个开源分布式搜索引擎，它的特点有：分布式，零配置，自动发...

Spring Cloud
通过上一篇《分布式服务跟踪（入门）》的例子，我们已经通过Spring Cloud Sleuth往微服务应用中添加了实现分布式跟踪具备的基本要素。下面通过本文来详细说说实现分布式服务跟踪的一些要点。 分布式系统中的服务跟踪在理论上并不复杂，它主要包括下面两个关键点： 为了实现请求跟踪，当请求发送到分布式系统的入口端点时，只需要服务跟踪框架为该请求创建一个唯一的跟踪标识，同时在分布式系统内部流转的时候，框架始终保持传递该唯一标识，直到返回给请求方为止，这个唯一标识就是前文中提到的Trace ID。通过Trace ID的记录，我们就能将所有请求过程日志关联起来。 为了统计各处理单元的时间延迟，当请求达到各个服务组件时，或是处理逻辑到达某个状态时，也通过一个唯一标识来标记它的开始、具体过程以及结束，该标识就是我们前文中提到的Span ID，对于每个Span来说，它必须有开始和结束两个节...

Spring Cloud
通过之前的N篇博文介绍，实际上我们已经能够通过使用它们搭建起一个基础的微服务架构系统来实现我们的业务需求了。但是，随着业务的发展，我们的系统规模也会变得越来越大，各微服务间的调用关系也变得越来越错综复杂。通常一个由客户端发起的请求在后端系统中会经过多个不同的微服务调用来协同产生最后的请求结果，在复杂的微服务架构系统中，几乎每一个前端请求都会形成一条复杂的分布式服务调用链路，在每条链路中任何一个依赖服务出现延迟过高或错误的时候都有可能引起请求最后的失败。这时候对于每个请求全链路调用的跟踪就变得越来越重要，通过实现对请求调用的跟踪可以帮助我们快速的发现错误根源以及监控分析每条请求链路上的性能瓶颈等好处。 针对上面所述的分布式服务跟踪问题，Spring Cloud Sleuth提供了一套完整的解决方案。在本章中，我们将详细介绍如何使用Spring Cloud Sleuth来为我们的微服务架...