Spring Cloud微服务

1 微服务架构

微服务架构的优点:

• 微服务很⼩，便于特定业务功能的聚焦
• 微服务很⼩，每个微服务都可以被⼀个⼩团队单独实施（开发、测试、部署上 线、运维），团队合作⼀定程度解耦，便于实施敏捷开发
• 微服务很⼩，便于重⽤和模块之间的组装
• 微服务很独⽴，那么不同的微服务可以使⽤不同的语⾔开发，松耦合
• 微服务架构下，我们更容易引⼊新技术
• 微服务架构下，我们可以更好的实现DevOps开发运维⼀体化；

缺点

• 微服务架构下，分布式复杂难以管理，当服务数量增加，管理将越加复杂
• 微服务架构下，分布式链路跟踪难等；

微服务架构中的⼀些概念

• 服务注册与服务发现
  服务注册：服务提供者将自己的相关信息注册到注册中心
  服务发现：服务消费者能从注册中心获取较为实时的服务列表，并根据配置策略去获取服务访问

• 负载均衡
  将请求压力分配给多台服务器，以提高服务的性能、可靠性

• 熔断
  断路保护，下游服务因为请求压力过大或其他因素导致的响应变慢或失败，上游系统为了保护系统整体可用性，可以暂时切断对下游服务的调用。牺牲局部，保全全局

• 链路追踪
  微服务中一个项目往往拆分成多个服务，那么一个请求可能涉及多个服务，那么链路追踪就是对这种请求进行日志监控、性能检测
  

• api网关
  不同微服务往往会有不同的访问地址，客户端一次业务可能需要调用多个服务的接口才能完成，那么会出现：

1. 服务url的地址的维护
2. 跨域
3. 身份认证

使用api网关

2 SpringCloud综述

是什么

生态，一系列框架的整合，使用SpringBoot简化了分布式项目的基础建设，如服务发现注册、配置中心、负载均衡、断路器、消息总线、数据监控等。屏蔽了复杂的配置和实现原理。一套简单易懂，易部署，易维护的分布式系统开发工具包。

解决问题

Spring Cloud 规范及实现意图要解决的问题其实就是微服务架构实施过程中存在的 ⼀些问题
⽐如微服务架构中的服务注册发现问题、⽹络问题（⽐如熔断场景）、 统⼀认证安全授权问题、负载均衡问题、链路追踪等问题。

SpringCloud架构

核心组件

3 Spring Cloud 核⼼组件 1.0

3.1 Eureka服务注册中⼼

3.1.1 服务注册中⼼

本质上是为了解耦服务提供者和服务消费者
为了⽀持弹性扩缩容特性，⼀个微服务的提供者的数量和分布往往是动 态变化的，也是⽆法预先确定的。因此，原本在单体应⽤阶段常⽤的静态LB机制就 不再适⽤了

主流服务中⼼对⽐

3.1.2 Eureka

3.1.2.1 Eureka客户端详解

3.1.2.2 Eureka服务端详解

3.2 Ribbon负载均衡

3.2.1 负载均衡

负载均衡⼀般分为服务器端负载均衡和客户端负载均衡

所谓服务器端负载均衡，⽐如Nginx、F5这些，请求到达服务器之后由这些负载均衡 器根据⼀定的算法将请求路由到⽬标服务器处理。

所谓客户端负载均衡，⽐如我们要说的Ribbon，服务消费者客户端会有⼀个服务器 地址列表，调⽤⽅在请求前通过⼀定的负载均衡算法选择⼀个服务器进⾏访问，负 载均衡算法的执⾏是在请求客户端进⾏。

Ribbon是Netflix发布的负载均衡器。Eureka⼀般配合Ribbon进⾏使⽤，Ribbon利 ⽤从Eureka中读取到服务信息，在调⽤服务提供者提供的服务时，会根据⼀定的算 法进⾏负载。

3.2.2 Ribbon负载均衡策略

3.3 Hystrix熔断器

3.3.1 微服务中的雪崩效应

在微服务架构中，⼀个应⽤可能会有多个微服务组成，微服务之间的数据交互通过 远程过程调⽤完成。

这就带来⼀个问题，假设微服务A调⽤微服务B和微服务C，微 服务B和微服务C⼜调⽤其它的微服务，这就是所谓的“扇出”。如果扇出的链路上某 个微服务的调⽤响应时间过⻓或者不可⽤，对微服务A的调⽤就会占⽤越来越多的系 统资源，进⽽引起系统崩溃，所谓的“雪崩效应”。

如图中所示，最下游简历微服务响应时间过⻓，⼤量请求阻塞，⼤量线程不会释 放，会导致服务器资源耗尽，最终导致上游服务甚⾄整个系统瘫痪。

3.3.2 雪崩效应解决⽅案

从可⽤性可靠性着想，为防⽌系统的整体缓慢甚⾄崩溃，采⽤的技术⼿段；

3.3.3 Hystrix

3.4 Feign远程调⽤组件

Feign是Netflix开发的⼀个轻量级RESTful的HTTP服务客户端（⽤它来发起请求， 远程调⽤的）
本质：封装了Http调⽤流程，更符合⾯向接⼝化的编程习惯，类似于Dubbo的服务调⽤
（效果）Feign = RestTemplate+Ribbon+Hystrix

3.4.1 Feign对请求压缩和响应压缩的⽀持

3.4.2 Feign的⽇志级别配置

3.5 GateWay⽹关组件

Spring Cloud GateWay是Spring Cloud的⼀个全新项⽬，⽬标是取代Netflix Zuul， 它基于Spring5.0+SpringBoot2.0+WebFlux（基于⾼性能的Reactor模式响应式通信 框架Netty，异步⾮阻塞模型）等技术开发，性能⾼于Zuul，官⽅测试，GateWay是 Zuul的1.6倍，旨在为微服务架构提供⼀种简单有效的统⼀的API路由管理⽅式。

Spring Cloud GateWay不仅提供统⼀的路由⽅式（反向代理）并且基于 Filter(定义 过滤器对请求过滤，完成⼀些功能) 链的⽅式提供了⽹关基本的功能，例如：鉴权、 流量控制、熔断、路径重写、⽇志监控等。

3.5.1 GateWay核⼼概念

3.5.2 GateWay过滤器

注意：GlobalFilter全局过滤器是程序员使⽤⽐较多的过滤器

3.5.3 GateWay⾼可⽤

3.6 Spring Cloud Config 分布式配置中⼼

对配置⽂件进⾏集中式管理

3.6.1 Config配置⼿动刷新

不⽤重启微服务，只需要⼿动的做⼀些其他的操作（访问⼀个地址/refresh）刷新， 之后再访问即可

3.6.2 Config配置⾃动更新

实现⼀次通知处处⽣效，我们可以结合消息总线（Bus）实现分布式配置的⾃动更新 （Spring Cloud Config+Spring Cloud Bus）

3.6.2.1 消息总线Bus

即我们经常会使⽤MQ消息代理构建⼀个共⽤的Topic，通过这个 Topic连接各个微服务实例，MQ⼴播的消息会被所有在注册中⼼的微服务实例监听 和消费。换⾔之就是通过⼀个主题连接各个微服务，打通脉络。

Spring Cloud Bus（基于MQ的，⽀持RabbitMq/Kafka） 是Spring Cloud中的消息 总线⽅案，Spring Cloud Config + Spring Cloud Bus 结合可以实现配置信息的⾃动 更新。

3.7 Spring Cloud Stream消息驱动组件

本质：屏蔽掉了底层不同MQ消息中间件之间的差异，统⼀了MQ的编程模型，降低 了学习、开发、维护MQ的成本

4 微服务监控之分布式链路追踪技术 Sleuth + Zipkin

4.1 分布式链路追踪技术适⽤场景

4.2 分布式链路追踪技术核⼼思想

5 微服务统⼀认证⽅案 Spring Cloud OAuth2 + JWT

5.1 微服务架构下统⼀认证思路

5.2 OAuth2开放授权协议/标准

OAuth（开放授权）是⼀个开放协议/标准，允许⽤户授权第三⽅应⽤访问他们存储 在另外的服务提供者上的信息，⽽不需要将⽤户名和密码提供给第三⽅应⽤或分享 他们数据的所有内容

第三⽅授权登录的场景：⽐如，我们经常登录⼀些⽹站或者应⽤的时候，可以选择 使⽤第三⽅授权登录的⽅式，⽐如：微信授权登录、QQ授权登录、微博授权登录 等，这是典型的 OAuth2 使⽤场景

5.3 Spring Cloud OAuth2介绍

Spring Cloud OAuth2 是 Spring Cloud 体系对OAuth2协议的实现，可以⽤来做多 个微服务的统⼀认证（验证身份合法性）授权（验证权限）。通过向OAuth2服务 （统⼀认证授权服务）发送某个类型的grant_type进⾏集中认证和授权，从⽽获得 access_token（访问令牌），⽽这个token是受其他微服务信任的。

注意：使⽤OAuth2解决问题的本质是，引⼊了⼀个认证授权层，认证授权层连接了 资源的拥有者，在授权层⾥⾯，资源的拥有者可以给第三⽅应⽤授权去访问我们的 某些受保护资源。

当我们第⼀次登陆之后，认证服务器颁发token并将其存储在认证服 务器中，后期我们访问资源服务器时会携带token，资源服务器会请求认证 服务器验证token有效性，如果资源服务器有很多，那么认证服务器压⼒会
很⼤…

另外，资源服务器向认证服务器check_token，获取的也是⽤户信息 UserInfo，能否把⽤户信息存储到令牌中，让客户端⼀直持有这个令牌，令牌的验证也在资源服务器进⾏，这样避免和认证服务器频繁的交互…

我们可以考虑使⽤ JWT 进⾏改造，使⽤JWT机制之后资源服务器不需要访问
认证服务器…

5.4 JWT改造统⼀认证授权中⼼的令牌存储机制

5.4.1 JWT令牌介绍

JSON Web Token（JWT）是⼀个开放的⾏业标准（RFC 7519），它定义了⼀种简介 的、⾃包含的协议格式，⽤于 在通信双⽅传递json对象，传递的信息经过数字签名 可以被验证和信任。JWT可以使⽤HMAC算法或使⽤RSA的公 钥/私钥对来签名，防 ⽌被篡改。

5.4.2 JWT令牌结构

• Header
  头部包括令牌的类型（即JWT）及使⽤的哈希算法（如HMAC SHA256或 RSA），例如
• Payload
  第⼆部分是负载，内容也是⼀个json对象，它是存放有效信息的地⽅，它可以存 放jwt提供的现成字段，⽐ 如：iss（签发者）,exp（过期时间戳）, sub（⾯向的 ⽤户）等，也可⾃定义字段。 此部分不建议存放敏感信息，因为此部分可以解 码还原原始内容。 最后将第⼆部分负载使⽤Base64Url编码，得到⼀个字符串 就是JWT令牌的第⼆部分。 ⼀个例⼦：
• Signature
  第三部分是签名，此部分⽤于防⽌jwt内容被篡改。 这个部分使⽤base64url将 前两部分进⾏编码，编码后使⽤点（.）连接组成字符串，最后使⽤header中声 明 签名算法进⾏签名。
  

6 Spring Cloud 核⼼组件 2.0（SCA）

6.1 SCA Nacos 服务注册和配置中⼼

Nacos （Dynamic Naming and Configuration Service）是阿⾥巴巴开源的⼀个针 对微服务架构中服务发现、配置管理和服务管理平台。

Nacos就是注册中⼼+配置中⼼的组合（Nacos=Eureka+Config+Bus）




负载均衡

Nacos客户端引⼊的时候，会关联引⼊Ribbon的依赖包，我们使⽤OpenFiegn的时 候也会引⼊Ribbon的依赖，Ribbon包括Hystrix都按原来⽅式进⾏配置即可

Nacos 数据模型（领域模型）
Namespace命名空间、Group分组、集群这些都是为了进⾏归类管理，把服务和配 置⽂件进⾏归类，归类之后就可以实现⼀定的效果，⽐如隔离
⽐如，对于服务来说，不同命名空间中的服务不能够互相访问调⽤

6.1.1 Nacos 配置中⼼

⼀个微服务希望从配置中⼼Nacos server中获取多个dataId的配置信息，可 以的，扩展多个dataId

6.2 SCA Sentinel 分布式系统的流量防卫兵

Sentinel是⼀个⾯向云原⽣微服务的流量控制、熔断降级组件。

替代Hystrix，针对问题：服务雪崩、服务降级、服务熔断、服务限流

6.2.1 Sentinel 部署

6.2.2 Sentinel 流量规则模块

系统并发能⼒有限，⽐如系统A的QPS⽀持1个，如果太多请求过来，那么A就应该进 ⾏流量控制了，⽐如其他请求直接拒绝
资源名：默认请求路径
针对来源：Sentinel可以针对调⽤者进⾏限流，填写微服务名称，默认default（不 区分来源）

阈值类型/单机阈值
QPS：（每秒钟请求数量）当调⽤该资源的QPS达到阈值时进⾏限流
线程数：当调⽤该资源的线程数达到阈值的时候进⾏限流（线程处理请求的时候， 如果说业务逻辑执⾏时间很⻓，流量洪峰来临时，会耗费很多线程资源，这些线程 资源会堆积，最终可能造成服务不可⽤，进⼀步上游服务不可⽤，最终可能服务雪 崩）

是否集群：是否集群限流

流控模式：
直接：资源调⽤达到限流条件时，直接限流
关联：关联的资源调⽤达到阈值时候限流⾃⼰ 链路：只记录指定链路上的流量

流控效果：
快速失败：直接失败，抛出异常
Warm Up：根据冷加载因⼦（默认3）的值，从阈值/冷加载因⼦，经过预热时⻓， 才达到设置的QPS阈值
排队等待：匀速排队，让请求匀速通过，阈值类型必须设置为QPS，否则⽆效 流控模式之关联限流

关联的资源调⽤达到阈值时候限流⾃⼰，⽐如⽤户注册接⼝，需要调⽤身份证校验 接⼝（往往身份证校验接⼝），如果身份证校验接⼝请求达到阈值，使⽤关联，可 以对⽤户注册接⼝进⾏限流

流控模式之链路限流

6.2.3 Sentinel 降级规则模块

流控是对外部来的⼤流量进⾏控制，熔断降级的视⻆是对内部问题进⾏处理

Sentinel 降级会在调⽤链路中某个资源出现不稳定状态时（例如调⽤超时或异常⽐ 例升⾼），对这个资源的调⽤进⾏限制，让请求快速失败，避免影响到其它的资源 ⽽导致级联错误。当资源被降级后，在接下来的降级时间窗⼝之内，对该资源的调 ⽤都⾃动熔断.

6.2.4 Sentinel ⾃定义兜底逻辑

@SentinelResource注解类似于Hystrix中的@HystrixCommand注解

@SentinelResource注解中有两个属性需要我们进⾏区分，blockHandler属性⽤来 指定不满⾜Sentinel规则的降级兜底⽅法，fallback属性⽤于指定Java运⾏时异常兜 底⽅法

6.2.5 基于 Nacos 实现 Sentinel 规则持久化

6.3 SCA小节