Spring Cloud常用组件介绍

一、说明

随着近些年来互联网业务的蓬勃发展，以及微服务技术体系的不断完善成熟，越来越多的系统建设开始朝着微服务的方向发展，其中基于Spring Boot配合Spring Cloud服务治理框架的组合，也得到了越来越多开发团队的认可，逐渐成为企业级微服务建设的标准解决方案。

1.1.什么是Spring Cloud

Spring Cloud是一系列框架的有序集合。它基于Spring Boot的开发便利性简化了分布式系统基础设施的开发，如服务发现注册、配置中心、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。

Spring Cloud将各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装，屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。Spring Cloud的主要支持和贡献者中包括了许多国内外的著名互联网科技公司，如Netflix和Alibaba，这大大推动了Spring Cloud的持续进步和发展。

1.2.Spring Cloud的组件选型

Spring Cloud家族拥有众多组件，既有作为单个服务独立部署的，又有可作高可用集群分布式部署的，也有作为插件集成于应用服务的。随着使用场景的丰富和社区开发者的不断贡献，Spring Cloud中实现同一类功能的组件也逐渐衍生出各分支子项目，各子项目设计思路和功能各有侧重。此外，Spring Cloud家族之外也有一些开源组件由于功能的契合，经常与Spring Cloud组件配合使用。这就需要使用者根据自身使用场景灵活选用，而作为企业用户，在进行组件选型时则更多需要考虑组件的成熟度和未来支持情况。

下面就简要介绍Spring Cloud常用组件的功能及使用场景，以便开发人员和设计者进行组件选型和应用。

二、组件介绍

下面就Spring Cloud关键的几类组件分别进行介绍。

2.1.服务注册与发现

服务注册与发现是服务治理的基础，Spring Cloud Netflix子项目中的Eureka是目前最常用的Spring Cloud服务注册组件，此外也有Spring Cloud Alibaba的子项目Nacos，以及Zookeeper等注册中心方案，下面分别对其中被广泛使用的Netflix Eureka和Alibaba Nacos进行介绍。

2.1.1.Netflix Eureka

Eureka是Netflix开源的一个基于 REST 服务的服务注册与发现的组件，是应用最广泛的Spring Cloud注册中心组件。目前1.x版本仍在维护中（并非网传的停止维护），2.x版本未正式发布。

1）分布式模型

分布式系统的CAP理论把分布式系统中的三个特性进行了归纳，一致性（C）、可用性（A）、分区容错性（P），三者不可兼得。

Eureka的设计理念是遵循AP的模式，这点与Zookeeper的CP模式不同。Eureka Server各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka Client在向某个Eureka Server注册时，如果发现连接失败，则会自动切换至其它节点。只要有一台Eureka Server还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。

2）主要组件

Eureka主要包括两个组件：

Eureka Client：一个Java客户端，用于简化与 Eureka Server 的交互（通常就是微服务中的客户端和服务端）

Eureka Server：提供服务注册和发现的能力（通常就是微服务中的注册中心）

3）工作过程

服务启动后向Eureka注册，Eureka Server会将注册信息向其他Eureka Server进行同步，当服务消费者要调用服务提供者，则向服务注册中心获取服务提供者地址，然后会将服务提供者地址缓存在本地，下次再调用时，则直接从本地缓存中取，完成一次调用。

当服务提供者有多个时，Eureka Client 客户端会通过 Ribbon 自动进行负载均衡。

图2-1 Eureka工作过程

4）集群部署

Eureka Server集群相互之间通过Replicate来同步数据，相互之间不区分主节点和从节点，所有的节点都是平等的。如果某台Eureka Server宕机，Eureka Client的请求会自动切换到新的Eureka Server节点。当宕机的服务器重新恢复后，Eureka会再次将其纳入到服务器集群管理之中。当节点开始接受客户端请求时，所有的操作都会进行节点间复制，将请求复制到其它Eureka Server当前所知的所有节点中。

Eureka提供了Region和Zone两个概念来进行分区，这两个概念均来自于亚马逊AWS。

Region：可以理解为地理上的不同区域，比如亚洲地区，中国区或者深圳等等。没有具体大小的限制。根据项目具体的情况，可以自行合理划分 region。

Zone：可以简单理解为 region 内的具体机房，比如说region划分为深圳，然后深圳有两个机房，就可以在此region之下划分出zone1、zone2两个zone。

图2-2 Eureka集群

上图中的us-east-1c、us-east-1d、us-east-1e就代表了不同的Zone。Zone内的Eureka Client优先和同一Zone内的Eureka Server进行心跳同步，同样调用端优先在Zone内的Eureka Server获取服务列表，当Zone内的Eureka Server全部挂掉之后，才会从别的Zone中获取信息。

5）高可用机制

当服务注册中心Eureka Server检测到服务提供者因为宕机、网络原因不可用时，则在服务注册中心将服务置为DOWN状态，并把当前服务提供者状态向订阅者发布，订阅过的服务消费者更新本地缓存。

服务提供者在启动后，周期性（默认30秒）向Eureka Server发送心跳，以证明当前服务是可用状态。Eureka Server在一定的时间（默认90秒）未收到客户端的心跳，则认为服务宕机，注销该实例。

当Eureka Server节点在短时间内丢失过多的客户端时（可能发送了网络故障），那么这个节点将进入自我保护模式，不再注销任何微服务，当网络故障回复后，该节点会自动退出自我保护模式。

2.1.2.Alibaba Nacos

Nacos是阿里巴巴开源的项目，核心定位是“一个更易于帮助构建云原生应用的动态服务发现、配置和服务管理平台”。Nacos提供了两个核心功能：服务注册与发现，动态配置管理，其中动态配置管理介绍详见第2.5.3节。

1）分布式模型

Nacos是一种去中心化的架构，属于CAP理论里的AP架构，支持最终一致性，在分布式服务发现与注册场景下具有很不错的性能。目前Dubbo官方也支持使用Nacos代替Zookeeper。

2）体系架构

Nacos主要提供以下四大功能。

①服务发现与服务健康检查：Nacos通过DNS或HTTP接口发现其他服务，并提供服务的实时健康检查，以防止向不健康的主机或服务实例发送请求。

②动态配置管理：Nacos可作为配置中心使用，详见2.5.3节介绍。

③动态DNS服务：Nacos支持加权路由，可在数据中心的生产环境中实施中间层负载平衡、灵活的路由策略、流量控制和简单的DNS解析服务。

④服务和元数据管理：Nacos提供易于使用的服务仪表板，可协助管理服务元数据，配置，kubernetes DNS，服务运行状况和指标统计等内容。

Nacos体系架构如下。

图2-3 Nacos体系架构

3）高可用

Nacos支持两种模式的部署，一种是和Eureka一样的AP协议的部署，这种模式只支持临时实例，并支持机房容灾。另一种是支持持久化实例的CP模式，这种情况下不支持双机房容灾。

Nacos提供的多机房部署解决方案是采用 Nacos-Sync 组件来做数据中心之间的数据同步，这意味着每个数据中心的 Nacos 集群都会有多个数据中心的全量数据。

图2-4 Nacos多机房部署

4）与Eureka对比

以下是Nacos与Eureka的一些指标对比。

表2-1 Nacos与Eureka对比

对比项目	Nacos	Eureka
CAP模型	支持AP和CP模型	AP模型
客户端更新服务信息方式	DNS-F客户端使用监听模式push/pull拉取更新信息	客户端定时轮询服务端获取其他服务IP信息并对比
伸缩性	Raft选举算法，性能、可用性、容错性均比较好，新加入节点无需与所有节点互相广播同步信息	使用广播同步信息，集群超过1000台机器后Eureka集群压力很大
健康检查模式/方式	支持服务端/客户端/关闭检查模式，检查方式有Tcp、Http、Sql，支持自定义健康检查器	客户端向服务端发送Http心跳
负载均衡	支持	支持
手动上下线服务方式	通过控制台页面或API	调用API
跨中心同步方案	支持	不支持
权重	Nacos默认提供权重设置功能，调整承载流量压力	不支持
厂商	Alibaba	Netflix

2.2.流量控制

请求流量控制是服务治理的主要手段，主要包括请求负载均衡、限流降级、服务熔断等功能。

通过配置合理的负载均衡策略，增加服务吞吐率，降低服务整体响应时间；通过预先设定限流规则，选择性的对某些超过预期的请求进行访问限制；通过降级和熔断策略，在服务出现不可用或响应超时的情况时，暂时停止提供服务，防止整个系统出现雪崩瘫痪。

在应对大流量请求的场景时，限流降级和服务熔断已经成为了标配技术解决方案，为保证系统的平稳运行起到了关键性的作用。

Spring Cloud Netflix提供了Ribbon和Hystrix分别实现客户端负载均衡和限流熔断，可以满足大部分场景的流量控制需求，又提供了Feign方便流量控制组件的集成，Feign+Ribbon+Hystrix是目前最常见的流量控制方案。此外，也有Alibaba开源的Sentinel可以实现类似Hystrix断路器的功能。下面分别对这些组件和解决方案进行介绍。

2.2.1.Netflix Feign+Ribbon+Hystrix

Netflix开源的Feign+Ribbon+Hystrix是目前最常见的流量控制方案，一般配合使用实现请求负载均衡、限流降级、服务熔断等功能。

1）Netflix Feign介绍

Feign是一款Java语言编写的HttpClient绑定器，在Spring Cloud微服务中用于实现微服务之间的声明式调用。Feign 可以定义请求到其他服务的接口，用于微服务间的调用，不用自己再写http请求，在客户端实现，调用此接口就像远程调用其他服务一样，当请求出错时可以调用接口的实现类来返回

Feign是一个声明式的web service客户端，它使得编写web service客户端更为容易。创建接口，为接口添加注解，即可使用Feign。Feign可以使用Feign注解或者JAX-RS注解，还支持热插拔的编码器和解码器。Spring Cloud为Feign添加了Spring MVC的注解支持，并整合了Ribbon和Eureka来为使用Feign时提供负载均衡。

2）Netflix Ribbon介绍

Ribbon是Netflix发布的开源项目，主要功能是提供客户端的软件负载均衡算法，将Netflix的中间层服务连接在一起。Ribbon客户端组件提供一系列完善的配置项如连接超时，重试等。简单的说，就是在配置文件中列出Load Balancer后面所有的机器，Ribbon会自动的帮助你基于某种规则（如简单轮询，随机连接等）去连接这些机器。

Ribbon工作时分为两步：第一步先选择 Eureka Server, 它优先选择在同一个Zone且负载较少的Server；第二步再根据用户指定的策略，在从Server取到的服务注册列表中选择一个地址。其中Ribbon提供了多种策略，例如轮询、随机、根据响应时间加权等。

3）Netflix Hystrix介绍

Hystrix具备了服务降级、服务熔断、线程隔离、请求缓存、请求合并以及服务监控等强大功能，是Spring Cloud最常用的流量控制组件。

Hystrix旨在通过熔断机制对延迟和故障提供更强大的容错能力。它通过以下四个方面的机制来解决这个问题。

①隔离（线程池隔离和信号量隔离）：限制调用分布式服务的资源使用，某一个调用的服务出现问题不会影响其他服务调用。

②优雅的降级机制：超时降级、资源不足时(线程或信号量)降级，降级后可以配合降级接口返回托底数据。

③熔断：当失败率达到阀值自动触发降级(如因网络故障/超时造成的失败率高)，熔断器触发的快速失败会进行快速恢复。

④缓存：提供了请求缓存、请求合并实现。

此外，Hystrix还基于Hystrix Dashboard支持流量实时状态监控，具体内容在2.4.2节介绍。

4）Feign+Ribbon+Hystrix之间的关系

图2-5 流量控制机制

在Spring Cloud微服务体系下，微服务之间的互相调用可以通过Feign进行声明式调用，在这个服务调用过程中Feign会通过Ribbon从服务注册中心获取目标微服务的服务器地址列表，之后在网络请求的过程中Ribbon就会将请求以负载均衡的方式打到微服务的不同实例上，从而实现Spring Cloud微服务架构中最为关键的功能即服务发现及客户端负载均衡调用。

另一方面微服务在互相调用的过程中，为了防止某个微服务的故障消耗掉整个系统所有微服务的连接资源，所以在实施微服务调用的过程中我们会要求在调用方实施针对被调用微服务的限流熔断逻辑。而要实现这个逻辑场景在Spring Cloud微服务框架下我们是通过Hystrix这个框架来实现的。

调用方会针对被调用微服务设置调用超时时间，一旦超时就会进入熔断逻辑，而这个故障指标信息也会返回给Hystrix组件，Hystrix组件会根据熔断情况判断被调微服务的故障情况从而打开熔断器，之后所有针对该微服务的请求就会直接进入熔断逻辑，直到被调微服务故障恢复，Hystrix断路器关闭为止。

2.2.2.Alibaba Sentinel

Sentinel是阿里中间件团队研发的面向分布式服务架构的轻量级高可用流量控制组件。Sentinel 主要以流量为切入点，从流量控制、熔断降级、系统负载保护、实时监控等多个维度来帮助用户提升服务的稳定性。

Sentinel 作为一个功能完备的高可用流量管控组件，其核心sentinel-core没有任何多余依赖，打包后只有不到200 KB，非常轻量级。开发者可以放心地引入sentinel-core而不需担心依赖问题。Sentinel和Hystrix一样，支持与Feign集成，方便客户端调用，同时，Sentinel提供了多种扩展点，用户可以很方便地根据需求去进行扩展，并且无缝地切合至Sentinel中。

1）流量控制

Sentinel可以针对不同的调用关系，以不同的运行指标（如QPS、并发调用数、系统负载等）为基准，对资源调用进行流量控制，将随机的请求调整成合适的形状。

Sentinel支持多样化的流量整形策略，在QPS过高的时候可以自动将流量调整成合适的形状。常用的策略有：

①直接拒绝模式：即超出的请求直接拒绝。

②慢启动预热模式：当流量激增的时候，控制流量通过的速率，让通过的流量缓慢增加，在一定时间内逐渐增加到阈值上限，给冷系统一个预热的时间，避免冷系统被压垮。

③匀速器模式：利用Leaky Bucket算法实现的匀速模式，严格控制了请求通过的时间间隔，同时堆积的请求将会排队，超过超时时长的请求直接被拒绝。

2）负载保护

Sentinel对系统的维度提供保护，负载保护算法借鉴了TCP BBR的思想。当系统负载较高的时候，如果仍持续让请求进入，可能会导致系统崩溃，无法响应。在集群环境下，网络负载均衡会把本应这台机器承载的流量转发到其它的机器上去。如果这个时候其它的机器也处在一个边缘状态的时候，这个增加的流量就会导致这台机器也崩溃，最后导致整个集群不可用。针对这个情况，Sentinel提供了对应的保护机制，让系统的入口流量和系统的负载达到一个平衡，保证系统在能力范围之内处理最多的请求。

3）实时监控和控制面板

Sentinel提供HTTP API用于获取实时的监控信息，如调用链路统计信息、簇点信息、规则信息等。如果用户正在使用Spring Boot/Spring Cloud并使用了Sentinel Spring Cloud Starter，还可以方便地通过其暴露的 Actuator Endpoint 来获取运行时的一些信息。

4）与Netflix Hystrix的对比

Sentinel作为一款与Hystrix作用类似的流量控制组件，两者主要有以下异同点。

表2-2 Sentinel与Hystrix的异同

2.3.网关

随着微服务的兴起，API网关（API Gateway）也成为微服务的标配，API网关是位于在服务集群边界上的入口，主要解决请求路由、访问控制、权限认证等问题。

图2-6 API网关

微服务网关一般包含以下特征和功能。

l 高可用：微服务网关应该是高可用、无状态的。

l 请求路由：包括路由策略动态配置、灰度发布等功能。

l 流量控制：包括请求负载均衡、限流降级、服务熔断等功能。

l 权限认证：包括请求权限认证、参数解密、黑白名单等功能。

l 请求链路记录：包括请求耗时监控、链路日志支持等功能。

下面就对Spring Cloud最常用的两款网关组件进行介绍。

2.3.1.Spring Cloud Gateway

Spring Cloud Gateway是Spring官方基于Spring 5.0、Spring Boot2.0和Project Reactor等技术开发的网关组件，Spring Cloud Gateway旨在为微服务架构提供简单、有效和统一的API路由管理方式。Spring Cloud Gateway作为Spring Cloud生态系统中的网关，目标是替代Netflix Zuul，在Spring Cloud2.x微服务架构体系中发挥非常大的作用。

1）主要概念

Spring Cloud Gateway的几个重要概念如下：

①路由：路由是网关最基础的部分，路由信息由ID、目的URL、一组断言和一组Filter组成。如果断言路由为真，则说明请求的URL和配置匹配。

②断言：Spring Cloud Gateway中的断言函数输入类型是Spring5.0框架中的ServerWebExchange。断言函数允许开发者去定义匹配来自于Http Request中的任何信息，比如请求头和参数等。

③过滤器：Spring cloud gateway中的Filter是分为两种类型的Filter，分别是Gateway Filter和Global Filter，过滤器Filter将会对请求和响应进行修改处理。

2）工作流程

Spring Cloud Gateway接到请求后，由Gateway Handler Mapping中找到与请求相匹配的路由，将其发送到Gateway Web Handler，Handler再通过指定的过滤器链将请求发送到我们实际的服务执行业务逻辑，最后返回执行结果。

Spring Cloud Gateway的工作流程示例如下。

图2-7 Spring Cloud Gateway处理流程

3）主要功能及实现方式

网关作为流量入口，在微服务系统中有着十分重要的作用，常用功能包括以下几个方面。

①权限认证

Spring Cloud Gateway可基于Filter实现JWT等认证策略，通过解析请求参数，实现请求权限认证和Token校验分发。

下面是Spring Cloud Gateway进行权限认证的示例流程。

图2-8 Spring Cloud Gateway权限认证

②动态路由

网关中有两个重要的概念，那就是路由配置和路由规则，路由配置是指配置某请求路径路由到指定的目的地址。而路由规则是指匹配到路由配置之后，再根据路由规则进行转发处理。

Spring Cloud Gateway作为所有请求流量的入口，在实际生产环境中为了保证高可靠和高可用，尽量避免重启。可通过实现RouteDefinitionRepository接口对网关进行扩展，实现Spring Cloud Gateway动态路由配置。

③流量控制

Spring Cloud Gateway默认提供了限流过滤器RequestRateLimiterGatewayFilterFactory，和限流的实现类RedisRateLimiter使用令牌桶限流，用户可根据自身需求实现AbstractGatewayFilterFactory，以实现个性化限流操作。

Spring Cloud Gateway可集成Ribbon实现负载均衡策略。

Spring Cloud Gateway可以通过集成Hystrix实现熔断降级，在Filters下加入熔断降级配置，设置降级后返回的路由，实现请求服务的熔断。

2.3.2.Netflix Zuul

Zuul是Netflix开源的一个API Gateway 服务器, 本质上是一个Web Servlet应用。由于Zuul2.x版本的发布延迟，导致Spring选择自行开发Spring Cloud Gateway作为Spring Cloud2.x的默认网关，但是Zuul在许多Spring Cloud系统中还是有广泛的应用。

1）主要概念

Zuul的核心是一系列的Filters, 其作用可以类比Servlet框架的Filter，或者AOP。

Zuul把Request Route到用户处理逻辑的过程中，这些Filter参与一些过滤处理，比如Authentication，Load Shedding等。

2）工作流程

Zuul中请求的生命周期如下图所示。

图2-9 Zuul权限认证

3）与Spring Cloud Gateway的对比

由于Zuul2.x尚未得到大规模应用，所以下面只列出Zuul1.x与Spring Cloud Gateway的主要指标对比。

表2-3 Zuul和Spring Cloud Gateway对比

	Spring Cloud Gateway	Netflix Zuul 1.x
性能	采用的WebFlux模块是基于Reactive Web 框架，可以用来构建异步的、非堵塞的、事件驱动的服务，在伸缩性方面表现非常好。	Zuul 1.x，尚基于阻塞I/O模型，性能不及Spring Cloud Gateway
开源组织	Spring Cloud Gateway是Spring Cloud的一个子项目	Zuul1.x由Netflix开发并开源，未来无集成至Spring Cloud的计划
版本	基于Spring Boot 2.*	基于Spring Boot 1.*

2.4.服务监控

完善的微服务监控是保证服务稳定性的必要手段，Spring Cloud也提供了一些优秀的组件协助进行服务实例和服务调用链路的监控。

下面对Spring Cloud常用的服务监控组件进行介绍。

2.4.1.Spring Boot Admin

Spring Boot Admin用于管理和监控SpringBoot应用程序。 应用程序作为Spring Boot Admin Client向为Spring Boot Admin Server注册（通过HTTP）或使用SpringCloud注册中心（例如Eureka，Consul）发现。 UI是的Vue.js应用程序，展示Spring Boot Admin Client的Actuator端点上的一些监控。服务端采用Spring WebFlux + Netty的方式。

Spring Boot Admin为注册的应用程序提供了以下功能。

l 显示健康状况

l 显示详细信息，例如

l JVM和内存指标

l micrometer.io指标

l 数据源指标

l 缓存指标

l 显示构建信息编号

l 关注并下载日志文件

l 查看jvm system-和environment-properties

l 查看Spring Boot配置属性

l 支持Spring Cloud的postable / env-和/ refresh-endpoint

l 轻松的日志级管理

l 与JMX-beans交互

l 查看线程转储

l 查看http-traces

l 查看auditevents

l 查看http-endpoints

l 查看计划任务

l 查看和删除活动会话（使用spring-session）

l 查看Flyway / Liquibase数据库迁移

l 下载heapdump

l 状态变更通知（通过电子邮件，Slack，Hipchat，…）

l 状态更改的事件日志（非持久性）

以下为Spring Boot Admin的示例截图。

图2-10 Spring Boot Admin

图2-11 Spring Boot Admin

图2-12 Spring Boot Admin

图2-13 Spring Boot Admin

2.4.2.Netflix Hystrix Dashboard + Turbine

Hystrix Dashboard是一款针对Hystrix进行实时监控的工具，通过Hystrix Dashboard我们可以在直观地看到各Hystrix Command的请求响应时间, 请求成功率等数据。

但是只使用Hystrix Dashboard只能看到单个应用内的服务信息, 需要借助Turbine工具能让我们汇总系统内多个服务的数据并显示到Hystrix Dashboard上.

HystrixDashboard界面监控参数示例如下。

图2-14 Netflix Hystrix Dashboard界面

图2-15 Netflix Hystrix Dashboard界面

2.4.3.Spring Cloud Sleuth+Zipkin

Spring Cloud提供了spring-cloud-sleuth-zipkin来方便集成Zipkin实现微服务链路跟踪。

1）Sleuth原理

Spring Cloud Sleuth实现了一种分布式的服务链路跟踪解决方案，通过使用Sleuth可以让我们快速定位某个服务的问题。简单来说，Sleuth相当于调用链监控工具的客户端，集成在各个微服务上，负责产生调用链监控数据。

Spring Cloud Sleuth是对Zipkin的一个封装，对于Span、Trace等信息的生成、接入HTTP Request，以及向Zipkin Server发送采集信息等全部自动完成。

Spring Cloud Sleuth可以追踪以下类型的组件：async，hystrix，messaging，websocket，rxjava，scheduling，web（SpringWebMvc，Spring WebFlux, Servlet），webclient（Spring RestTemplate），feign，zuul。Sleuth可以在底层拦截Trance并创建Span，

2）主要概念

①Span（跨度）：Span是基本的工作单元。Span包括一个64位的唯一ID，一个64位trace码，描述信息，时间戳事件，key-value 注解(tags)，span处理者的ID（通常为IP）。

最开始的初始Span称为根span，此span中span id和 trace id值相同。

②Trance（跟踪）：包含一系列的span，它们组成了一个树型结构

③Annotation（标注）：用于及时记录存在的事件。常用的Annotation如下：

l CS（Client Sent 客户端发送）：客户端发送一个请求，表示span的开始

l SR（Server Received 服务端接收）：服务端接收请求并开始处理它。(SR - CS)等于网络的延迟

l SS（Server Sent 服务端发送）：服务端处理请求完成，开始返回结束给服务端。(SR - SS)表示服务端处理请求的时间

l CR（Client Received 客户端接收）：客户端完成接受返回结果，此时span结束。(CR - CS)表示客户端接收服务端数据的时间

3）Zipkin介绍

针对服务化应用全链路追踪的问题，Google发表了Dapper论文，介绍了他们如何进行服务追踪分析。其基本思路是在服务调用的请求和响应中加入ID，标明上下游请求的关系。利用这些信息，可以可视化地分析服务调用链路和服务间的依赖关系。

Zipkin就是对应Dpper的一个实现，由Twitter开源。

图2-16 Zipkin架构

Instrumented client和Instrumented server是分布式系统中的服务，通过装备库采集跟踪信息，装备库再调用Transport，把跟踪信息发送给Zipkin。

Transport是Zipkin对外提供的接口，目前有HTTP、Kafka、Scribe三种。

Zipkin支持对链路数据持久化存储。

图2-17 链路跟踪示例

图2-18 链路跟踪示例

2.5.配置中心

系统微服务化后，原本存在于单体应用的配置项分散拆分到了众多子服务当中，如何合理维护繁多的配置项，并高效完成配置项在多运行实例的更新，成了亟待解决的运维问题。

Spring Cloud提供了Spring Cloud Config作为配置中心组件，实现微服务场景下的配置管理。此外，还有功能更强大，更贴合企业应用场景的Apollo和Nacos作为配置中心选型。

下面对这几种配置中心组件进行对比介绍。

2.5.1.Spring Cloud Config

Spring Cloud Config为分布式系统中的外部配置提供服务器和客户端支持。方便部署与运维。

Spring Cloud Config服务端也称分布式配置中心，是一个独立的微服务应用，用来连接配置服务器并为客户端提供获取配置信息，加密/解密信息等访问接口。客户端则是通过指定配置中心来管理应用资源，以及与业务相关的配置内容，并在启动的时候从配置中心获取和加载配置信息。默认采用GIT维护配置信息，也可使用数据库、SVN、本地文件等作为持久化存储。

Spring Cloud Config有以下几点优势。

①基于应用、环境、版本三个纬度管理

②配置存储支持Git、SVN等多种方式

③与Spring 无缝集成，迁移成本低

Spring Cloud Config也有以下几点缺陷。

①动态配置能力弱，调整配置需要重新部署，添加代码比较多

②治理能力和安全审计能力弱

③不算严格企业级，仅适用于小型项目

2.5.2.Apollo

Apollo（阿波罗）是携程框架部门研发的开源配置管理中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性。

Apollo支持4个维度管理Key-Value格式的配置。

l application (应用)

l environment (环境)

l cluster (集群)

l namespace (命名空间)

Apollo与Spring Cloud Config的对比如下。

表2-4 Spring Cloud Config与Apollo对比

功能点	Apollo	Spring Cloud Config
配置界面	统一界面管理	无
配置生效时间	实时	重启生效/refresh/git webhook+MQ
版本管理	界面操作	无
灰度发布	支持	无
授权/审计/审核	界面操作，支持修改和发布权限分离	需要git操作，权限无法分离
实例配置监控	看到客户端的配置	无
配置获取性能	快，DB+缓存支持	git clone repo,本地文件读取
客户端支持	Java,.Net,Spring Annotation	Spring应用+anotation支持

2.5.3.Alibaba Nacos

在第2.1.2.章已经提到，Nacos不仅可以作为Spring Cloud的注册中心组件，其中还包含了配置中心的功能，下面进行简要介绍。

动态配置管理是 Nacos 的三大功能之一，通过动态配置服务，我们可以在所有环境中以集中和动态的方式管理所有应用程序或服务的配置信息。

动态配置中心可以实现配置更新时无需重新部署应用程序和服务即可使相应的配置信息生效，这极大了增加了系统的运维能力。

Nacos 服务端保存了配置信息，客户端连接到服务端之后，根据 dataID，group可以获取到具体的配置信息，当服务端的配置发生变更时，客户端会收到通知。当客户端拿到变更后的最新配置信息后，就可以做自己的处理了，这非常有用，所有需要使用配置的场景都可以通过 Nacos 来进行管理。

Nacos 并不是通过推的方式将服务端最新的配置信息发送给客户端的，而是客户端维护了一个长轮询的任务，定时去拉取发生变更的配置信息，然后将最新的数据推送给 Listener 的持有者。

Nacos与Apollo的对比如下。

总的来说，Apollo和Nacos相对于Spring Cloud Config的生态支持更广，在配置管理流程上做的更好。Apollo相对于Nacos在配置管理做的更加全面，不过使用起来也要麻烦一些。Nacos使用起来相对比较简洁，在对性能要求比较高的大规模场景更适合。