一、微服务网关(Spring Cloud Gateway)
根据REST API接口，外部客户端可以调用各个微服务但出于种种原因，这并不是一个好的选择。让客户端直接与各个微服务通讯，会存在以下几个问题。
- 客户端会多次请求不同的微服务，增加了客户端的复杂性。
- 存在跨域请求，在一定场景下处理会变得相对比较复杂。
- 实现认证复杂，每个微服务都需要独立认证。
- 难以重构，项目迭代可能导致微服务重新划分。如果客户端直接与微服务通讯，那么重构将会很难实施。
- 如果某些微服务使用了防火墙、浏览器不友好的协议，直接访问会有一定困难。
以上问题就可以通过微服务网关来解决。
网关有很多重要的意义，具体体现在下面几个方面。
- 网关可以做一些身份认证、权限管理、防止非法请求操作服务等，对服务起一定保护作用。
- 网关将所有微服务统一管理，对外统一暴露，外界系统不需要知道微服务架构个服务相互调用的复杂性，同时也避免了内部服务一些敏感信息泄露问题。
- 易于监控。可在微服务网关收集监控数据并将其推送到外部系统进行分析。
- 客户端只跟服务网关打交道，减少了客户端与各个微服务之间的交互次数。
- 多渠道支持，可以根据不同客户端（WEB端、移动端、桌面端...）提供不同的API服务网关。
- 网关可以用来做流量监控。在高并发下，对服务限流、降级。
- 网关把服务从内部分离出来，方便测试。
微服务网关能够实现，路由、负载均衡等多种功能。类似Nginx，反向代理的功能。在微服务架构中，后端服务往往不直接开放给调用端，而是通过一个API网关根据请求的URL，路由到相应的服务。当添加API网关后，在第三方调用端和服务提供方之间就创建了一面墙，在API网关中进行权限控制，同时API网关将请求以负载均衡的方式发送给后端服务。
SpringCloud Gateway简介：
SpringCloud Gateway 是 Spring Cloud 的一个全新项目，该项目是基于 Spring 5.0，Spring Boot 2.0 和 Project Reactor 等技术开发的网关，它旨在为微服务架构提供一种简单有效的统一的 API 路由管理方式。
SpringCloud官方，对SpringCloud Gateway 特征介绍如下：
- 基于 Spring Framework 5，Project Reactor 和 Spring Boot 2.0
- 集成 Spring Cloud DiscoveryClient
- Predicates 和 Filters 作用于特定路由，易于编写的 Predicates 和 Filters
- 具备一些网关的高级功能：动态路由、限流、路径重写
- 集成Spring Cloud DiscoveryClient
- 集成熔断器CircuitBreaker
从以上的特征来说，和Zuul的特征差别不大。SpringCloud Gateway和Zuul主要的区别，还是在底层的通信框架上。
简单说明一下上文中的三个术语：
（1）Filter（过滤器）：
和Zuul的过滤器在概念上类似，可以使用它拦截和修改请求，并且对下游的响应，进行二次处理。过滤器为org.springframework.cloud.gateway.filter.GatewayFilter类的实例。
（2）Route（路由）：
网关配置的基本组成模块，和Zuul的路由配置模块类似。一个Route模块由一个 ID，一个目标 URI，一组断言和一组过滤器定义。如果断言为真，则路由匹配，目标URI会被访问。
（3）Predicate（断言）：
这是一个 Java 8 的 Predicate，可以使用它来匹配来自 HTTP 请求的任何内容，例如 headers 或参数。断言的输入类型是一个 ServerWebExchange。
二、微服务配置管理(Spring Cloud Config)
在SpringBoot，默认会提供一个application.properties或者application.yml文件作为配置文件，我们可以把一些全局性的配置或者需要动态维护的配置写入改文件，比如数据库连接，功能开关，限流阈值，服务地址等。为了解决不同环境下服务连接配置等信息的差异，Spring Boot还提供了基于spring.profiles.active={profile}的机制来实现不同的环境的切换。
但是随着单体架构向微服务架构的演进，各个应用自己独立维护本地配置文件的方式也开始显露出不足，主要有以下几个方面。
- 配置的动态更新：在实际应用会有动态更新位置的需求，比如修改服务连接地址、限流配置等。在传统模式下，需要手动修改配置文件并且重启应用才能生效，这种方式效率太低，重启也会导致服务暂时不可用。
- 配置多节点维护：在微服务架构中某些核心服务为了保证高性能会部署上百个节点，如果在每个节点中都维护一个配置文件，一旦配置文件中的某个属性需要修改，可想而知，工作量是巨大的。
- 不同部署环境下配置的管理：前面提到通过profile机制来管理不同环境下的配置，这种方式对于日常维护来说也比较繁琐
统一配置管理就是弥补上述不足的方法，简单说，最近本的方法是把各个应用系统中的某些配置放在一个第三方中间件上进行统一维护。然后，对于统一配置中心上的数据的变更需要推送到相应的服务节点实现动态跟新，所以微服务架构中，配置中心也是一个核心组件。如下图所示：
SpringCloudConfig简介:
Spring Cloud Config 是一个解决分布式系统的配置管理方案，它包含了 server 和 client 两个部分。server 用来获取远程的配置信息（默认为 Git 仓库），并且以接口的形式提供出去；client 根据 server 提供的接口读取配置文件，以便于初始化自己的应用。如果配置中心出现了问题，将导致灾难性的后果，因此在生产环境下配置中心都会做集群，来保证高可用。 此处配置高可用实际就是把多个配置中心（指定同一个 Git 远程仓库）注册到注册中心。
三、微服务链路追踪(Spring Cloud Sleuth)
链路追踪简介：
微服务架构是一个分布式架构，它按业务划分服务单元，一个分布式系统往往有很多个服务单元。由于服务单元数量众多，业务的复杂性，如果出现了错误和异常，很难去定位。主要体现在，一个请求可能需要调用很多个服务，而内部服务的调用复杂性，决定了问题难以定位。所以微服务架构中，必须实现分布式链路追踪，去跟进一个请求到底有哪些服务参与，参与的顺序又是怎样的，从而达到每个请求的步骤清晰可见，出了问题，很快定位。
Spring Cloud Sleuth：
Spring Cloud Sleuth采用的是Google的开源项目Dapper的专业术语。
- Span：基本工作单元，发送一个远程调度任务 就会产生一个Span，Span有一个64位ID唯一标识的，Trace是用另一个64位ID唯一标识的，Span还有其他数据信息，比如摘要、时间戳事件、Span的ID、以及进度ID。
- Trace：一系列Span组成的一个树状结构。请求一个微服务系统的API接口，这个API接口，需要调用多个微服务，调用每个微服务都会产生一个新的Span，所有由这个请求产生的Span组成了这个Trace。
- Annotation：用来及时记录一个事件的，一些核心注解用来定义一个请求的开始和结束 。这些注解包括以下：
- cs - Client Sent -客户端发送一个请求，这个注解描述了这个Span的开始
- sr - Server Received -服务端获得请求并准备开始处理它，如果将其sr减去cs时间戳便可得到网络传输的时间。
- ss - Server Sent （服务端发送响应）–该注解表明请求处理的完成(当请求返回客户端)，如果ss的时间戳减去sr时间戳，就可以得到服务器请求的时间。
- cr - Client Received （客户端接收响应）-此时Span的结束，如果cr的时间戳减去cs时间戳便可以得到整个请求所消耗的时间。
链路追踪术语：
