springBoot学习思维导图模板_ProcessOn思维导图、流程图

基本信息

作者

翟永超

微服务构建：Spring Boot

创建

访问 http://start.spring.io/ ，以Maven 或 Gradle构建

编写测试用例

范例

@RunWith

引入Junit4

@SpringApplicationConfiguration

指定spring boot 的启动类

@WebAppConfiguration

开启Web应用的配置，用于模拟ServletContext

MockMvc对象

模拟调用Controller接口发起请求

perform函数执行一次请求调用，accept用于执行接收的数据类型，andExpect用于判断接口返回的期望值

配置

默认配置文件为 application.properties文件，同时支持YAML文件

YAML文件无法通过@PropertySource注解来加载配置

YAML将属性加载到内存中保存是有序的

自定义参数

在配置文件中声明后，可以在应用中通过@Value进行加载

范例

参数引用

各参数之间可以通过PlaceHolder的方式来进行引用

范例

使用随机数

在属性配置文件中，可以通过使用${random}配置来产生随机的int值，long值，string字符串

说明

命令行参数

启动spring boot应用，需要使用命令：java -jar

在Linux 系统启动时，需要以nohup开头， &结尾，否则会意外结束进程

在命令行方式启动spring boot应用时，连续的两个减号 -- 就是对application.properties中的属性值进行赋值的标识

可以在启动应用时对配置属性重新赋值

多环境配置

多环境配置的文件名，需要满足：application-{profile}.properties的格式

具体加载哪个配置文件，由application.properties文件中的spring.profiles.active属性来配置

启动顺序

说明

监控和管理

集成actuator

客户端负载均衡： Spring Cloud Ribbon

基于HTTP和TCP的客户端负载均衡工具，基于Netflix Ribbon实现

微服务中负载均衡调用的实现

服务提供者只需要启动多个服务实例并注册到一个注册中心或是多个相关联的服务注册中心

服务消费者直接通过调用被@LoadBalanced注册修饰过的RestTemplate来实现面向服务的接口调用

RestTemlate

GET请求

getForEntity

返回ResponseEntity,该对象是spring 对HTTP请求响应的封装

getForObject

可以理解为对getForEntity进一步封装

通过HttpMessageConverterExtractor对HTTP的请求响应体body内容进行转换，实现请求直接返回包装好的对象

POST请求

postForEntity（与GET请求中的类似）

postForObject（与GET请求中的类似）

postForLocation

实现以POST请求提交资源，并返回新资源的URI

PUT请求

DELETE请求

源码分析

LoadBalanceClient

RestTemplate 通过@LoadBalance标记，使用LoadBalanceClient来配置

choose（String serviceId）

根据传入的服务名serviceId，从负载均衡器中挑选一个对应服务的实例

execute(String serviceId,LoadBalancerRequest request)

使用从负载均衡器中挑选出的服务实例来执行请求内容

reconstructURI(ServiceInstance instance,URI original)

通过ServiceInstance 中的host和port，拼接出具体host:port形式的请求地址

在分布式系统中，使用逻辑上的服务名称作为host来构建URI进行请求

LoadBalancerAutoConfigration

实现客户端负载均衡器的自动化配置类

Ribbon实现负载均衡自动化配置

@ConditionOnClass(RestTemplate.class)

RestTemplate 类必须在于当前工程的环境中

@ConditionalOnBean(LoadBalancerClient.class)

在spring的Bean工程中必须有LoadBalancerClient的实现类

主要操作

创建一个LoadBalancerInterceptor的Bean，用于实现对客户端发起请求时进行拦截，以实现客户端负载均衡

创建一个RestTemplateCustomizer的Bean，用于给RestTemplate增加LoadbBalancerInterceptor拦截器

维护一个被@LoadBalanced注解修饰的RestTemplate对象列表

并在这里进行初始化，通过调用RestTemplateCustomizer的实例来给需要客户端负载均衡的RestTemplate增加LoadBalancerInterceptor拦截器

LoadBalancerInterceptor拦截器如何将一个普通RestTemplate变成客户端负载均衡的

当一个被LoadBalanced注解修饰的RestTemplate对象向外发起HTTP请求时，会被LoadBalanceInterceptor类的intercept函数拦截

RestTemplate中使用服务名作为host，调用execute函数根据服务名来选择实例并发起实际请求

RibbonLoadBalanceClient

负载均衡器实现类

getServer（ILoadBalancer loadBalancer）

获取具体服务器实例时，没有使用LoadBalancerClient接口中的choose函数

ILoadBalancer

addservers

向负载均衡器中维护的实例列表增加服务实例

chooseServer

通过某种策略，从负载均衡器中挑选一个具体的服务实例

markServerDown

用来通知和标识负载均衡器中某个具体实例已经停止服务，不然负载均衡器在下一次获取服务实例清单前都会认为服务实例均是正常的

getReachableServers

获取当前正常服务的实例列表

getAllServers

获取所有已知的服务实例列表，包括正常和停止的

ILoadBalancer的实现

BaseLoadBalancer

基础负载

DynamicServerListLoadBalancer

ZoneawareLoadBalancer

SpringClientFactory

用来创建客户端负载均衡器的工厂类

会为每一个不同名的Ribbon客户端生成不同的Spring上下文

RibbonLoadBalancerContext

LoadBalancerContext的子类

存储一些被不在均衡器使用的上下文内容和API操作

Ribbon通过RibbonStatsRecorder对象对服务的请求进行了跟踪记录

负载均衡器

Spring Cloud中定义了LoadBalancerClient作为负载均衡器的通用接口

Ribbon实现了RibbonLoadBalancerClient,但在具体实现客户端负载均衡时，是通过Ribbon的ILoadBalaner接口实现的

AbstractLoadBalancer

ILoadBalancer类的抽象实现

ServerGroup

服务实例的分组枚举

ALL：所有服务实例

STATUS_UP：正常服务的实例

STATUS_NOT_UP：停止服务的实例

getLoadBalancerStats（）

获取LoadBalancerStats对象

LoadBalancerStats

用来储存负载均衡器中各个服务实例当前的属性和统计信息

这些信息可以反应负载均衡的运行情况

也是制定负载均衡策略的重要依据

BaseLoadBalancer

Ribbon负载均衡器的基础实现类

定义了两个存储服务实例Server对象的列表，一个是所有的实例，一个是正常服务的

定义了LoadBalancerStats对象

定义了检查服务实例是否正常服务的IPing对象

默认为null，需要在构造时注入具体实现

定义了检查服务实例操作的执行策略对象IPingStrategy，并有内部类实现

采用线性遍历ping服务实例的方式实现检查

定义了负载均衡的处理规则IRule对象

负载均衡器实际将服务实例选择任务委托给了IRule实例中的choose函数来实现

默认初始化了RoundRobinRule为IRule的实现对象

RoundRobinRule实现了最基本且常用的线性负载均衡规则

启动ping任务，默认构造函数中，会直接启动给一个用于定时检查Server是否健康的任务，默认执行间隔为10秒

DynamicServerListLoadBalancer

继承于BaseLoadBalancer，是对基础负载均衡器的扩展

实现了服务实例清单在运行期的动态更新能力

对服务实例清单的过滤功能

ServerList

服务列表操作对象

ServicerListUpdater

触发向Eureka Server 去获取服务实例清单以及如何在获取到服务实例清单后更新本地的服务实例清单

PollingServerListUpdater

默认策略，通过定时任务的方式进行服务列表的更新

EurekaNotificationBalancer

需要利用Eureka的事件监听器来驱动服务列表的更新操作

ServerListFilter

通过传入的服务实例清单，根据一些规则返回过滤后的服务实例清单

ZoneAwareLoadBalancer

依旧是以线性轮询的方式来选择调用的服务实例

该算法实现简单并没有区域（Zone）的概念，所以会把所有实例视为一个Zone下的节点来看待

同时，避免了多区域部署的性能问题

setServerListForZones

该函数用于根据区域Zone分组的实例列表，创建ZoneStats并放入Map zoneStatMap集合中，每个区域Zone对应一个ZoneStats,用于存储每个Zone的一些状态和统计信息

创建一个ConcurrentHashMap类型的balancers对象

用来存储每个Zone区域对应的负载均衡器

具体负载均衡器的创建则通过getLoadBalancer函数完成

同时创建负载均衡器时候会创建它的规则

如果当前实现没有IRule的实例，就创建一个AvaliabilityFilteringRule规则

如果有具体实例，就克隆一个

创建完负载均衡器后，调用setServersList函数为其设置对应Zone区域的实例清单

检查Zone区域中实例清单，如果Zone区域下已经没有实例了，就把balancers中对应Zone区域的实例列表清空

防止过时的Zone区域统计信息干扰具体实例的选择算法

挑选实例

只有当负载均衡器中维护的实例所属的Zone区域个数大于1的时候才会执行选择策略，否则还将使用父类实现

Photo 1

负载均衡策略

IRule接口的各个实现

AbstractLoadBalancerRule

负载均衡策略的抽象类，定义了负载均衡器ILoadBalancer对象

在具体实现选择服务策略时，获取一些负载均衡器中维护的信息作为分配依据

RandomRule

从服务实例清单中随机选择一个服务实例

RoundRobinRule

按照线性轮询的方式依次选择每个服务实例

和RandomRule类似，除循环条件不同，增加了一个count计数变量，在每次循环后累加，如果一直选择不到server超过10次，就会结束，并打印警告信息

RetryRule

具备重试机制的实例选择

在其内部定义了一个IRule对象，默认使用RoundRobinRule实例

在choose方法中则实现了对内部定义的策略进行反复尝试的策略

WeightedResponseTimeRule

对RoundRobinRule的扩展，增加了根据实例运行情况计算权重

并根据权重挑选实例，以达到更优分配的效果

实现的3个核心内容

定时任务

在策略初始化的时候，会启动一个定时任务，为每个服务实例计算权重，默认30秒一次

权重计算

存储权重的对象：List accumulatedWeights

该List中每个权重值所处的位置对应了负载均衡器维护的服务实例清单中所有实例在清单中的位置

实现步骤

根据LoadBalancerStats中记录的每个实例的统计信息，累加所有实例的平均响应时间，得到总平均响应时间totalResponseTime

为实例清单逐个计算权重

Photo 1

实例选择

Photo 1

ClientConfigEnabledRoundRobinRule

高级策略均基于此类扩展

BestAvailableRule

遍历所有服务实例，过滤掉故障的，找到并发请求数最小的

依据统计对象loadBalancerStats，为空时候，策略无法执行，采用父类的线性轮询策略

PredicateBasedRule

基于Predicate实现的策略

Predicate是Google Guava Collection工具对集合进行过滤的条件接口

Photo 1

AvailabilityFilteringRule

继承自PredicateBasedRule，先过滤清单，再轮询选择

过滤条件使用AvailabilityPredicate

判断过滤条件

是否故障，即断路器是否生效已断开

实例并发请求数大于阈值，默认2的32次方减1

选择一个实例，接着用过滤条件判断该实例是否满足要求，若不满足继续循环，重复10次还找不到符合条件的，就采用父类的实现方案

ZoneAvoidanceRule

继承自PredicateBaseRule的具体实现类

Photo 1

配置详解

自动化配置

Photo 1

参数配置

Photo 1

与Eureka的结合

Photo 1

重试机制

Spring Cloud Eureka实现的服务治理机制强调了CAP原理中的AP，可用性和可靠性

与Zoookeeper这类强调CP（一致性，可靠性）的最大区别是为了实现服务的可用性，牺牲了一定的一致性

Eureka的自动保护机制，即使有部分故障节点，也可以保障大多数的服务正常消费

Spring Cloud整合了Spring Retry来增强RestTemplate的重试能力

开启重试配置

Photo 1

声明式服务调用： Spring Cloud Feign

分布式配置中心：Spring Cloud Config

用来为分布式系统中的基础设施和微服务应用提供集中化的外部配置支持

服务端

也称为分布式配置中心，用来连接配置仓库并未客户端提供获取配置信息、加密、解密信息等访问接口

客户端

客户端是微服务架构中的各个微服务应用或基础设施，它们通过制定的配置中心来管理应用资源与业务相关的配置内容

Spring Cloud Config 实现了对服务端和客户端中环境变量和属性配置的抽象映射

默认使用git来存储信息

服务端详解

基础架构

远程Git仓库

用来存储配置文件的地方

Config Server

构建的分布式配置中心，在工程中指定了所要连接的Git仓库位置以及账户、密码等连接信息

本地Git仓库

在Config Server的文件系统中，每次客户端请求获取配置信息时，Config Server从Git仓库中获取最新配置到本地，然后在本地Git仓库中读取并返回

当远程仓库无法获取时，直接将本地内容返回

具体的微服务应用

指定了Config Server地址，从而实现从外部化获取应用自己要用的配置信息
这些应用在启动的时候，会向Config Server请求获取配置信息来进行加载

客户端获取配置信息的执行流程

1、应用启动时，根据bootstrap.properties中配置的应用名{application}、环境名{profile}、分支名{label}，向Config Server请求获取配置信息

2、Config Server 根据维护的Git仓库信息和客户端传递过来的配置定位信息去查找配置信息

3、通过 git clone 命令将找到的配置信息下载到Config Server的文件系统中

4、Config Server创建Spring的ApplicationContext实例，并从Git本地仓库中加载配置文件，最后将这些配置内容读取出来返回给客户端应用

5、客户端应用在获得外部配置文件后加载到客户端的ApplicationContext实例，该配置内容的优先级高于客户端Jar包内部的配置内容，所以在Jar包中重复的内容不会再被加载

通过git clone将配置信息存于本地，起到了缓存的作用

Git配置仓库

配置仓库默认实现采用Git

设置Git请求地址

spring.cloud.config.server.git.uri

默认http请求uri

file:// 设置一个文件地址，以本地仓库的方式运行

file://${user.home}/config-repo

${user.home} 代表当前用户的所属目录

对本地开发调试时使用非常方便

账号

spring.cloud.config.server.git.username

spring.cloud.config.server.git.password

占位符配置URI

这些占位符除了用于标识配置文件的规则外，还可以用于对Git仓库地址的URI配置

{application}

代表了应用名，Config Server会根据客户端的spring.application.name信息来填充

{profile}

环境，dev/test等

{label}

Git的分支和标签名包含"/",那么{label}参数在HTTP的URL中应该使用"(_)"来替代

通过在URI中使用占位符可以实现通用的仓库配置

代码库

使用服务名作为Git仓库名称

配置库

使用服务名加上-config后缀作为Git仓库名称

使用{application}-config配置，来同时匹配多个不同服务的配置仓库

配置多个仓库

通过带有通配符的表达式来匹配，当有多个匹配规则的时候，还可以用逗号来分割多个{application}/{profile}配置规则

范例

当未匹配到合适的仓库时，就将在该默认仓库下获取配置信息

当配置多个仓库时，Config Server在启动时会直接克隆第一个仓库的配置库，其他的配置库只有在请求时才会克隆到本地

子目录存储

spring.cloud.server.git.searchPaths

指定仓库的子目录下实现配置的存储

支持使用{application}、{profile}和{label}占位符

访问权限

HTTP的认证方式，username和password配置账户

SSH的方式，通过生成Key并在Git仓库中进行配置匹配实现访问

SVN仓库

引入SVN依赖：svnkit groupId： org.tmatesoft.svnkit

svn配置url： svn://localhost:443/didispace/config-repo

高可用配置

传统模式

所有的Config Server都指向同一个Git仓库，客户端指定Config Server只需要配置Config Server上层的负载均衡设备地址

服务模式

Config Server 作为一个普通的微服务应用，纳入 Eureka的服务治理体系中

加密解密

在微服务架构中，通常采用DevOps的组织方式来降低因团队间沟通早场的巨大成本

DevOps（英文Development和Operations的组合）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运营工作必须紧密合作。

可以把DevOps看作开发（软件工程）、技术运营和质量保障（QA）三者的交集。

子主题

使用前提

在配置中心的运行环境中安装不限长度的JCE版本（Unlimited Strength Java Cryptography Extension）

下载压缩包，把里面的jar包复制到$JAVA_HOME/jre/lib/security目录下，覆盖原来的默认内容

相关端点

配置密钥

通过encrypt.key属性在配置文件中直接指定密钥信息（对称性密钥）

encrypt.key=didispace

非对称加密

生成公钥/私钥

使用%JAVA_HOME%\bin\keytool.exe

子主题

一次生成密钥库

默认生成的密钥只有90天有效期，通过 -validity参数来实现

通过命令生成方式，最终会在命令当前执行目录下生成一个config-server.keystore文件，在配置中心加入相关的配置信息

配置文件直接配置，如果密钥文件放在src/main/resource目录下，可以这样配置：encrypt.key-store.location=config-server.keystore

通过环境变量配置，可以获得更好的安全性，将敏感的口令信息存储在配置中心的环境变量中

安全保护

引入 spring-boot-starter-security依赖，无需配置

默认情况下，会获取一个名为user的用户，在配置中心启动的时候，日志中会打印出该用户的随机密码

Using generated security password: 16f3cae7-4cab-4b8d-acd4-b71cb49f172f

指定用户名和密码

服务端

security.user.name=user

sercurity.user.password=123

在服务端配置了安全保护，那么客户端也要加入安全信息来通过校验

spring.cloud.config.username=user
spring.cloud.config.password=123

属性覆盖

通过 spring.cloud.config.server.overrids 属性来设置键值对的参数，这些参数以Map的方式加载到客户端的配置中

通过该属性配置的参数，不会被Spring Cloud的客户端修改

Spring Cloud客户端从 Config Server中获取配置信息时，都会获取这些配置信息。可以配置一些共同属性或默认值

客户端可以改变更高优先级的配置，来选择是否使用Config Server提供的默认值

健康监测

在Server Config 中有spring-boot-actuator模块，/actuator/health有对应的健康检测器：ConfigServerHealthIndicator

该检测器中，默认构建一个application为app的仓库，按照配置规则,例如：{application}-config.git，该检测器会不断检查 http://git.oschina.net/didispace/app-config 仓库是否可以连通

单独配置check仓库

spring.cloud.config.server.health.repositories.check.name=check

应用名

spring.cloud.config.server.health.repositories.check.label=master

分支名

spring.cloud.config.server.health.repositories.check.profiles=default

环境名

关闭健康检测器

spring.cloud.config.server.health.enabled=false

本地仓库

在使用了Git或SVN仓库后，文件会在Config Server的本地文件系统中存储一份，默认存储于以 config-repo为前缀的临时目录中，如： /tmp/config-repo-<随机数>

配置：spring.cloud.config.server.<svn/git>.basedir

本地文件系统

不使用远程仓库，而是使用本地文件系统的存储方式来保存配置信息

配置

spring.profiles.active=native

默认从应用的src/main/resource目录下搜索配置文件

spring.cloud.config.server.native.searchLocations 指定具体的配置文件的位置

客户端详解

URI指定配置中心

Spring Cloud Config 的客户端在启动的时候，默认从工程的classpath中加载配置信息并启动应用

只有在bootstrap.properties、环境变量或其他优先级高于应用Jar包内的配置信息中配置了spring.cloud.config.uri,才能正确加载到远程配置

如果不指定spring.cloud.config.uri，会默认使用 http://localhost:8888

服务化配置中心

失败快速响应与重试

实现客户端优先判断 Config Server获取是否正常，并快速响应失败内容

在bootstrap.properties中配置spring.cloud.config.failFast=true

实现重试

pom配置

<dependency>
<groupId>org.springframework.retry</groupId>
<artifactId>spring-retry</artifactId>
</dependency>

<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-aop</artifactId>
</dependency>

配置

获取远程配置

动态刷新配置

增加

消息驱动的微服务： Spring Cloud Stream

分布式服务跟踪：Spring Cloud Sleuth

消息总线：Spring Cloud Bus

API网关服务：Spring Cloud Zuul

基于Netflix Zuul实现的API网关组件

通过和Spring Cloud Eureka进行整合，将自身注册为Eureka服务治理下的应用，同时从Eureka中获得了所有其它微服务的实例信息

对于路由规则的维护，Zuul默认会将通过以服务名作为ContextPath的方式来创新路由映射

API网关的作用

权限校验,签名校验机制

解决微服务架构中，对于微服务接口访问时各前置校验的冗余问题

定义类似于面向对象设计模式中的Facade模式，就像系统的门面一样，所有的外部客户端访问都需要经过它来进行调度和过滤

路由详解

传统路由配置

单例配置

zuul.routes..path和zuul.routes..url参数对应的方式

例子

zuul.routes.user-service.path=/user-service/**

zuul.routes.user-service.url=http://localhost:8080/

多实例配置

zuul.routes..path与zuul.routes..serviceId参数对的方式进行配置

例子

zuul.routes.user-service.path=/user-service/**

zuul.routes.user-service.serviceId=user-service

ribbon.eureka.enabled=false

user-service.ribbon.listOfServers=http://localhost:8080/,http://localhost:8081

服务路由配置

zuul.routes.user-service=/user-service/**

服务路由的默认规则

Zuul引入Eureka之后，会为Eureka中每个服务创建一个默认路由规则

这些默认规则的path会使用serviceId配置的服务名作为请求前缀

设置不生成默认路由规则的服务

zuul.ignored-services

自定义路由映射规则

为一组互相配合的微服务定义一个版本标识来管理

类似于这样的命名：userservice-v1，orderservice-v1

通常的做法是为这些不同版本的微服务生成以版本号前缀的URL路径

分支主题

PatternServiceRouteMapper对象可以让开发者通过正则表达式来自定义服务和路由映射的生成关系

如果没有匹配上的服务则还是会使用默认的路由映射规则，即采用完整服务名作为前缀的路径表达式

路径匹配

Zuul中，路由匹配的路径表达式采用了Ant分隔定义

？匹配任意单个字符

* 匹配任意数量的字符

** 匹配任意数量的字符，支持多级目录

路由规则匹配请求路径的时候通过线性遍历的方式，在请求路径获取到第一个匹配的路由规则之后就返回并结束匹配过程

路由规则是通过LinkedHashMap保存的，也就是说，路由规则的保存是有序的

由于properties的配置内容无法保证有序

为了保证路由的优先顺序，需要使用YAML文件来配置

忽略表达式

zuul.ignored-patterns

设置不希望被API网关进行路由的URL表达式

zuul.ignored-patterns=/**/hello/**

路由前缀

zuul.prefix=/api

设置网关上的路由规则都增加/api的前缀

关闭代理前缀

移除代理前缀的动作

zuul.stripPrefix=false

对指定路由关闭移除代理前缀的动作

zuul.routes..strip-prefix=true

本地跳转

支持forward形式的服务端跳转

只需要通过使用path与url的配置方式

通过url中使用forward来指定需要跳转的服务器资源路径

范例

zuul.routes.api-b.path=/api-b/**

zuul.routes.api-b.url=forward:/local

当API网关接收到请求/api-b/hello ,它符合api-b的路由规则

所以该请求会被API网关转发到网关的/local/hello请求上进行本地处理

Cookie与头信息

默认情况下，Spring Cloud Zuul在请求路由时，会过滤掉HTTP请求头信息中的一些敏感信息，防止传递到下游的外部服务器

默认的敏感头信息通过zuul.sensitiveHeaders参数定义，包括Cookie、Set-Cookie、Authorization

Web项目时常用的Cookie在Zuul网关中默认不会传递

解决Cookie传递的问题

通过设置全局参数为空来覆盖默认值（不推荐）

zuul.sensitiveHeaders

指定路由的参数来配置（推荐）

对指定路由开启自定义敏感头

zuul.routes..customSensitiveHeaders=true

将指定路由的敏感头设置为空

zuul.routes..sensitiveHeaders=

重定向问题

通过网关

zuul.addHostHeader=true

重定向返回：return new ModelAndView("redirect:http://localhost:5555/hellos/hello?accessToken=token");

Hystrix 和 Ribbon支持

Zuul自身包含了对Hystrix和Ribbon的依赖，所以Zuul天生就拥有线程隔离和断路器的自我保护功能，以及对服务调用的客户端负载均衡功能

通过path和url的映射关系来配置路由规则的时候，路由转发请求不会采用HystrixCommand来包装

推荐使用path和serviceId的组合来进行配置，这样保证了API网关的健壮和稳定，也能用到Ribbon的客户端负载均衡功能

参数配置

hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds

设置API网关中路由转发请求HystrixCommand执行超时时间，单位:毫秒

路由转发请求的命令执行时间超过该配置值后，Hystrix会将该执行命令标记为TIMEOUT并抛出异常

Zuul会对该异常进行处理并返回JSON信息给外部调用方

ribbon.ConnectTimeout

设置路由转发请求时，创建请求连接的超时时间

当ribbon.ConnectTimeout的配置值小于hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds配置值得时候，若出现路由请求连接超时，就会自动重试

依然失败的话，就向外部抛出JSON信息

ribbon.ReadTimeout

设置路由转发请求的超时时间，它的超时是对请求连接建立之后的处理时间

过滤器详解

过滤器

每个进入Zuul的HTTP请求都会经过一系列的过滤器处理链得到请求响应并返回给客户端

路由功能在真正运行时，路由映射通过pre类型的过滤器完成，它将请求路径和配置的路由规则进行匹配；而请求穿发则由route类型的过滤器来完成

四个基本特征

过滤类型

执行顺序

执行条件

具体操作

ZuulFilter接口

filterType（）

返回一个字符串来代表过滤器类型，这个类型就是HTTP请求过程中定义的各个阶段

pre

可以在请求被路由之前调用

routing

在路由请求时被调用

post

在routing和error过滤器之后被调用

error

处理请求时发生错误时被调用

filterOrder（）

通过 int 值来定义过滤器的执行顺序，数值越小优先级越高

shouldFilter（）

返回一个boolean值判断过滤器是否执行

run（）

过滤器的具体逻辑

请求生命周期

不同类型过滤器在HTTP请求中执行的位置

核心过滤器

在Zuul中，HTTP请求生命周期的各个阶段默认实现一批核心过滤器，它们在API网关服务启动的时候被自动加载和启用

pre过滤器

ServletDetectionFilter

执行顺序为 -3，是最先被执行的过滤器

主要检测当前请求是通过Spring的DispathcherServlet处理运行，还是通过ZuulServlet；来运行的

一般情况下，发送到API网关的外部请求都会被Spring的DispathcerServlet处理，除了/zuul/*路径访问的请求会绕过被ZuulServlet

ZuulServlet主要来应对处理大文件上传的情况，对应的访问路径/zuul/*,可以通过zuul.servletPath参数来进行修改

Servlet30WrapperFilter

执行顺序：-2

主要为了把HttpServletRequest包装成Servlet30RequestWrapper对象

FormBodyWrapperFilter

执行顺序: -1

对两类请求生效

Content-Type=application/x-www-form-urlencoded

Content-Type=multipart/form-data,并且由Spring的DispatcherServlet处理的请求

主要目的是将符合要求的请求体包装成FormBodyRequestWrapper对象

DebugFilter

执行顺序：1

根据配zuul.debug.request 和请求中的 debug 参数来决定是否执行过滤器

具体操作内容是将请求上下文中的 debugRouting 和 debugRequest 参数设置为true，用于通过请求的方式激活哪些根据这两个值定义的debug信息

请求参数中debug参数，可以通过zuul.debug.parameter来自定义

PreDecorationFilter

执行顺序：5

判断请求上下文中是否存在forward.to 和 serviceId 参数

如果有一个存在的话，说明当前请求已经被处理过了，因为这两个信息就是根据当前请求的路由信息加载进来的

具体操作内容是为当前请求做一些预处理

路由规则的匹配

在请求上下文中设置该请求的基本信息及路由匹配结果等一些设置信息

这些信息是后续过滤器进行处理的重要依据

可以通过 RequestContext.getCurrentContext( )来访问这些信息

对HTTP头请求进行处理

如 X-Forwarded-Host,X-Forwarded-Port,这些头域的记录是通过zuul.addProxyHeaders参数进行控制，默认为true

Zuul在请求跳转时默认会为请求增加X-Forwarded-*头域

route过滤器

RibbonRoutingFilter

执行顺序：10

只对请求上下文中存在serviceId参数的请求进行处理，即只对通过serviceId配置路由规则的请求生效

通过使用Ribbon和Hystrix来向服务实例发起请求，并将服务实例的请求结果返回

SimpleHostRoutingFilter

执行顺序：100

对请求上下文中存在routeHost参数的请求进行处理，即只对通过url配置路由规则的请求生效

该过滤器的执行逻辑就是直接向routeHost参数的物理地址发起请求，httpclient包实现的，没有线程隔离和断路器的保护

SendForwardFilter

执行顺序：500

只对请求上下文中存在forward.to参数的请求进行处理，即处理路由规则中的forward本地跳转配置

post过滤器

SendErrorFilter

执行顺序：0

在请求上下文中包含error.status_code参数（由之前执行的过滤器设置的错误编码）并且还没有被该过滤器处理过的时候执行

利用请求上下文中的错误信息组成一个forward到API网关/error错误端点的请求来产生错误响应

SendResponseFilter

执行顺序：1000

该过滤器会检查请求上下文中是否包含请求响应相关的头信息、响应数据流或是响应体，只有在包含它们其中一个的时候执行处理逻辑

异常处理

try-catch 处理

整个发起请求的逻辑都采用了try-catch块处理

在catch异常的处理逻辑中并没有做任何输出操作，而是向请求上下文中添加一些error相关的参数

error.status_code

错误编码

error.exception

Exception 异常对象

error.message

错误信息

ErrorFilter处理

让错误信息能够顺利地流转到后续的SendErrorFilter过滤器来组织和输出

统一的处理

由于在请求生命周期的pre，route，post三个阶段中有异常抛出的时候都会进入error阶段处理，可以用到error类型的过滤器

Throwable throwable = ctx.getThrowable();

范例

不足和优化

自定义过滤器中处理异常的基本解决方法

1、每个阶段的过滤器中增加try-catch块，实现过滤器内部的异常处理

开发人员基本要求

2、利用error类型过滤器的生命周期特性，集中处理pre、route、post阶段抛出的异常信息

对第一种处理方式的补充，防止意外情况的发生

各阶段过滤器的调度实现

com.netflix.zuul.http.ZuulServlet

service（）

子主题

存在的问题

那两种处理方法都在异常处理时向请求上下文添加了一系列的error.*参数，而这些参数真正起作用的地方是在post阶段的SendErrorFilter

而对于post阶段抛出的异常的情况下，由error过滤器处理之后并不会再调用post阶段的请求，自然这些error.*参数也不会被SendErrorFilter消费输出

解决办法

创建一个继承自SendErrorFilter的过滤器，复用它的run方法，然后重写它的类型、顺序以及执行条件，实现对原有逻辑的复用

怎么判断引起异常的过滤器来自什么阶段

RequestContext对象中并没有存储异常来源的内容，所以需要扩展原来的过滤器处理逻辑

当有异常抛出的时候，记录下抛出异常的过滤器，就可以在shouldFilter方法中获取并以此判断异常是否来自post阶段的过滤器

Zuul过滤器的核心处理器：com.netfilx.zuul.FilterProcessor

getInstance()：该方法用来获取当前处理器的实例
setProcessor(FilterProcessor processor)：该方法用来设置处理器实例，可以使用此方法来设置自定义的处理器
processZuulFilter(ZuulFilter filter)：该方法定义了用来执行filter的具体逻辑，包括对请求上下文的设置，判断是否应该执行，执行时一些异常处理等
getFiltersByType(String filterType)：该方法用来根据传入的filterType获取API网关中对应类型的过滤器，并根据这些过滤器的filterOrder从小到大排序，组织成一个列表返回
runFilters(String sType)：该方法会根据传入的filterType来调用getFiltersByType(String filterType)获取排序后的过滤器列表，然后轮询这些过滤器，并调用processZuulFilter(ZuulFilter filter)来依次执行它们
preRoute()：调用runFilters("pre")来执行所有pre类型的过滤器
route()：调用runFilters("route")来执行所有route类型的过滤器
postRoute()：调用runFilters("post")来执行所有post类型的过滤器
error()：调用runFilters("error")来执行所有error类型的过滤器

通过扩展processZuulFilter(ZuulFilter filter)方法，当过滤器执行抛出异常的时候，我们捕获它，并往请求上下中记录一些信息

public class DidiFilterProcessor extends FilterProcessor {

@Override

public Object processZuulFilter(ZuulFilter filter) throws ZuulException {

try {

return super.processZuulFilter(filter);

} catch (ZuulException e) {

RequestContext ctx = RequestContext.getCurrentContext();

ctx.set("failed.filter", filter);

throw e;

}

}

}

完善之前ErrorExtFilter中的shouldFilter()方法，通过从请求上下文中获取该信息作出正确的判断

@Component
public class ErrorExtFilter extends SendErrorFilter {

@Override
public String filterType() {
return "error";
}

@Override
public int filterOrder() {
return 30; // 大于ErrorFilter的值
}

@Override
public boolean shouldFilter() {
// 判断：仅处理来自post过滤器引起的异常
RequestContext ctx = RequestContext.getCurrentContext();
ZuulFilter failedFilter = (ZuulFilter) ctx.get("failed.filter");
if(failedFilter != null && failedFilter.filterType().equals("post")) {
return true;
}
return false;
}

}

最后，我们需要在应用主类中，通过调用FilterProcessor.setProcessor(new DidiFilterProcessor());方法来启用自定义的核心处理器以完成我们的优化目标。

自定义异常信息

往往默认的错误信息并不符合系统设计的响应格式，需要对返回的异常信息进行定制

参考SendErrorFilter的实现，然后直接组织请求响应结果而不是forward到/error,为了替代SendErrorFilter，还需要禁用SendErrorFilter过滤器

对/error端点的实现

org.springframework.boot.autoconfigure.web.BasicErrorController

通过调用getErrorAttributes方法会将具体组织逻辑委托给org.springframework.boot.autoconfigure.web.ErrorAttributes接口提供的getErrorAttributes来实现

在Spring Boot的自动化配置机制中，默认会采用org.springframework.boot.autoconfigure.web.DefaultErrorAttributes作为接口的实现

在定义Error处理的自动化配置中采用了@ConditionOnMissingBean修饰

说明DefaultErrorAttributes对象实例仅在没有ErrorAttributes接口的实例时才会被创建来使用

自定义一个ErrorAttributes接口实现类，并创建它的实例能替代这个默认的实现，从而达到自定义错误信息的效果

自定义范例

在应用主类加入配置，替换默认的实现

禁用过滤器

禁用过滤器可以通过重写shouldFilter逻辑，返回false，这样过滤器对于任何请求都不会被执行

通过一个参数来禁用指定的过滤器

zuul.<SimpleClassname>.<filterType>.disable=true

过滤器的类名，例如：AccessFilter

过滤器类型，如：AccessFilter的过滤器类型是pre

范例

zuul.AccessFilter.pre.disable=true

也可以禁用Spring Cloud Zuul中默认定义的核心过滤器

动态加载

动态路由和动态过滤器的能力

动态路由

服务容错保护：Spring Cloud Hystrix

在微服务架构中，存在着许多的服务单元，若一个单元出现故障，很容易因为依赖关系而引发故障蔓延，最终导致整个系统的瘫痪，为了解决这样的问题，产生了断路器等一系列的服务保护机制

当某个服务单元发生故障，通过断路器的故障监控，向调用方返回一个错误响应，而不是长时间等待

Spring Cloud Hystrix 实现了断路器，线程隔离等一系列服务保护功能，也是基于Netflix的开源框架Hystrix实现的

该框架的目标在于通过控制那些访问远程系统，服务和第三方库的节点，从而对延迟和故障提供更强大的容错能力

Hystrix具备服务降级，服务熔断，线程和信号隔离，请求缓存，请求合并以及服务监控等功能

原理分析

创建HystrixCommand或HystrixObservableCommand对象

表示对依赖服务的操作请求，同时传递所有需要的参数

通过"命令模式"来实现对服务调用操作的封装

将来自客户端的请求封装成一个对象，从而可以使用不同的请求对客户端进行参数化

实现了"行为请求者"和"行为实现者"的解耦，以便使两者可以适应变化

Invoker和Receiver的关系类似于"请求－响应"，比较适合实现记录日志，撤销操作，队列请求等

使用命令模式作为回调－CallBack(先将一个函数登记上，然后在以后调用此函数)

需要在不同的时间指定请求，将请求排队

命令对象和原先的请求发出者可以有不同的生命周期

命令接收者可以在本地，也可以在网络上

命令对象可以在序列化后传输到另外一台机器上

系统需要支持命令的撤销

命令对象可以吧状态存储起来，等客户端需要撤销命令所产生的效果时，调用undo（）方法

命令对象还提供了redo（）方法，重新实施命令

通过日志进行数据恢复

如果要将系统中所有的数据更新到日志中，以便在系统崩溃时，可以根据日志读回所有的数据更新命令，重新调用Execute（）方法一条一条执行

HysrixCommand

用于依赖的服务返回单个操作结果的时候

HystrixObservableCommand

用于服务返回多个操作结果的时候

代码分析

Receiver

接收者，知道如何处理具体的业务逻辑

Command

抽象命令，定义了一个命令对象应具备的一系列命令操作

execute

undo

redo

当命令操作被调用的时候，就会触发接收者去做具体命令对应的业务逻辑

ConcreteCommand

具体的命令实现，在这里它绑定了命令操作和接收者之间的关系

execute（）命令的实现委托给了Receiver的action（）函数

Invoker

调用者，持有一个命令对象，并且可以在需要的时候通过命令对象完成具体的业务逻辑

命令执行

HystrixCommand

execute（）

同步执行，从依赖的服务返回一个单一的结果对象，或是在发送错误的时候抛出异常

queue（）

异步执行，直接返回一个Future对象，其中包含了服务执行结束时要返回的单一结果对象

HystrixObservableCommand

toObservable（）

同样返回Observable对象，也代表了操作的多个结果，但返回的是一个Cold Observable

observe()

返回Observable对象，代表了操作的多个结果，是一个HotObservable

Hystrix的底层实现中大量使用了Rxjava

RxJava

Observable（事件源或被观察者）

一个Observable可以发出多个事件，直到结束或是发生异常

Observable对象每发出一个事件，就会调用对应观察者Subscriber对象的onNext（）方法

每一个Observable的执行，最后一定会通过调用Subscriber.onCompleted（）或者Subscriber.onError（）来结束该事件的操作流

Subscriber( 订阅者或观察者)

Observable用来向订阅者Subscriber对象发布事件，Subscriber对象则在接收到事件后对其进行处理，而在这里所指的事件就是对依赖服务的调用

Hot Observable

无论事件源是否有订阅者，都会在创建后对事件进行发布

Cold Observable

没有订阅者的时候并不会发布事件，而是进行等待，直到有"订阅者"之后才发布事件

HystrixCommand中也是使用RxJava实现的

execute（）

通过queue（）返回的异步对象Future的get（）方法来实现同步执行

queue（）

通过toObservable( )来获取一个 Cold Observable

并通过toBlocking（）将该Observable转换成BlockingObservable，可以把数据以阻塞的方式发射出来

Future要求Observable只发射一个数据

通过toFuture方法则是把BlockingObservable转换为一个Future，该方法只是创建一个Future返回，并不会阻塞，消费者可以自己决定如何处理异步操作

结果是否被缓存

若当前命令的请求缓存功能是被启用的，并且该命令缓存命令中，那么缓存的结果会立即以Observable对象的形式返回

断路器是否打开

在命令结果没有缓存命中的时候，Hystrix在执行命令前检查断路器状态

断路器是打开的，那么Hystrix不会执行命令，而是转接到fallback处理逻辑

如果断路器是关闭的，那么Hystrix检查是否有可用资源来执行命令

线程池/请求队列/信号量是否占满

如果线程池/请求队列/信号量（不使用线程池的时候）已经被占满了，那么Hystrix也不会执行命令，而是转接到fallback处理逻辑

线程池

Hystrix所判断的线程池并非容器的线程池，而是每个依赖服务的专有线程池

舱壁模式（Bulkhead Pattern）

隔离每个依赖的服务，保证不会因为某个依赖服务的问题影响到其他依赖服务

请求依赖服务的具体方式

HystrixCommand.run()

返回一个单一的结果，或者抛出异常

HystrixObservableCommand.construct()

返回一个Observable对象来发射多个结果，或通过onError发送错误通知

这两个方法执行超过命令设置的超时阈值，当前处理线程会抛出一个TimeoutException，直接转到fallback处理逻辑

如果该命令不在其自身线程中执行，则会通过单独的计时线程来抛出

如果命令没有抛出异常并返回了结果，那么Hystrix在记录一些日志并采集监控报告之后将该结果返回

计算断路器的健康度

Hystrix会将成功，失败，拒绝，超时等信息报告给断路器，断路器会维护一组计数器来统计这些数据

通过这些数据断路器会判断是否要打开，来对某个依赖服务的请求进行"熔断/短路"，直到恢复期结束

恢复期结束后，如果统计数据还未达到健康指标，就再次"熔断/短路"

fallback处理

命令执行失败时，会进入fallback尝试回退处理，也称之为"服务降级"

服务降级逻辑中，实现一个通用的响应结果，并且该结果的处理逻辑应当从缓存或是根据一些静态逻辑来获取，而不是依赖网络请求

也可以是包含网络请求的，该请求也应包装在Hystrix命令注解中，从而形成降级策略

但最终的降级策略一定是一个不依赖网络请求，并能够稳定返回结果的处理逻辑

HystrixCommand

通过实现HystrixCommand.getFallback()来实现服务降级逻辑

返回一个Observable对象，该对象会发射getFallback（）的处理结果

HystrixObservableCommand

通过实现resumeWithFallback()来实现服务降级逻辑

将Observable对象直接返回

如果没有为命令实习那降级逻辑或者降级逻辑中抛出了异常

Hystrix依然会返回一个Observable对象，但不会发射任何结果数据，而是通过onError方法通知命令立即中断请求，并将引起命令是失败的异常发送给调用者

返回成功的响应

命令执行成功后，会将处理结果返回或是以Observable形式返回

Observable可以转换成需要的方式

Photo 1

断路器原理

断路器定义

HystrixCircuitBreaker

allowRequet（）

每个Hystrix命令的请求都通过它来判断

isOpen（）

当前断路器是否打开

markSuccess（）

用来闭合断路器

ConcurrentHashMap circuitBreakersByCommand

key 通过HystrixCommandKey定义

维护了Hystrix命令和HystrixcircuitBreaker的关系

NoOpCircuitBreaker

一个什么都不做的断路器，状态始终闭合，允许所有请求

HystrixCircuitBreakerImpl

实现类

断路器的4个核心对象

HystrixCommandProperties properties

断路器对应HystrixCommand实例的属性对象

HystrixCommandMetrics metrics

用来让HystrixCommand记录各类度量指标的对象

AtomicBoolean circuitOpen

断路器是否打开的标志，默认false

AtomicLong circuitOpenedOrLastTestedTime

断路器打开火上一次测试的时间戳

isOpen（）实现

打开标识为true，直接返回ture

否则，从度量指标对象metrics中获取HealthCounts统计对象做进一步判断

HealthCounts

记录了一个滚动时间窗内的请求信息快照，默认时间窗为10秒

如果请求总数（QPS）在预设的阈值范围内，默认20，就返回false，未打开

如果错误百分比在阈值范围内就返回false，默认50

如果上面两个条件都不满足，就将断路器设置为打开状态，如果是从关闭到打开状态，并记录当前时间

allowRequest（）实现

判断请求是否被允许

先根据配置对象properties中的断路器判断强制打开或关闭属性是否被设置

默认情况下，不会进入强制打开或关闭分支，而是通过！isOpen（）II allSingleTest（）来判断是否允许请求访问

allowSingleTest()

获取断路器从闭合到打开时候所记录的时间戳

这里会判断断开时的时间戳 + 配置中的断路器休眠时间是否小于当前时间，是的话，就将当前时间更新到记录断路器打开的时间对象，并允许此次请求

断路器打开后的休眠时间，默认5秒，circuitBreakerSleepWindowInMilliseconds

半开状态

在一个断路器打开之后的休眠时间，在该休眠时间到达之后，将再次允许请求尝试访问

此时断路器处于"半开"状态，若此时请求继续失败，断路器又进入打开状态，并继续等待下一个休眠窗口过去之后再次尝试

若请求成功，则将断路器重新置于关闭状态

markSuccess()

在"半开"状态使用

若Hystrix命令调用成功，通过调用此函数将打开的断路器关闭，并重置度量指标对象

依赖隔离

舱壁模式

Docker

通过"舱壁模式"实现进程的隔离，使得容器与容器之间不会互相影响

Hystrix则使用该模式实现线程池的隔离

为每一个依赖服务创建一个独立的线程池

这样就算某个依赖服务出现延迟过高的情况，也不会拖慢其他的依赖服务

优点

应用自身得到完全保护，不会受不可控的依赖服务影响

可以有效降低接入心服务的风险

当依赖的服务从失效恢复正常后，线程池会被清理，马上回复健康服务，容器级的清理要慢很多

当依赖对的服务出现配置错误的时候，线程池会快速反应此问题（通过失败次数，延迟，超时，拒绝等指标的增加情况），同时可以在不影响应用功能的情况下，通过实时的动态属性刷新来处理

每个专有线程池都提供了内置的并发实现，可以利用它为同步的依赖服务构建异步访问

使用信号量来控制单个依赖服务的并发度

信号量的开销远比线程池的开销小，但不能设置超时和实现异步访问

命令执行

execution.isolation.strategy设置SEMAPHORE，Hystrix会使用信号量代替线程池来依赖服务的并发

降级逻辑

当Hystrix尝试降级逻辑时，它会在调用线程中使用信号量

使用详解

创建请求命令

通过继承方式实现

Photo 1

通过注解方式实现

Photo 1

HystrixObservableCommand

Photo 1

HystrixCommand注解控制

使用observe（）执行

observableExecutionMode = ObservableExecutionMode.EAGER

使用toObservable（）执行

observableExecutionMode = ObservableExecutionMode.LAZY

定义服务降级

代码实现

HystrixCommand是通过重载getFallback（）方法实现

HystrixObservableCommand通过重载resumeWithFallback（）方法实现

注解实现

@HystrixCommand 中通过fallbackMethod参数指定具体的服务降级实现

例子

可以不去降级的情况

执行写操作的命令

执行批处理或离线计算的命令

不论Hystrix命令是否实现了服务降级，命令状态和断路器状态都会更新，而且可以由此了解到命令执行的失败情况

异常处理

异常传播

在HystrixCommand实现的run（）方法中抛出异常时，除了HystrixBadRequestException之外，其他异常都会被认为是命令执行失败并触发服务降级处理逻辑

当需要在命令执行中抛出不触发服务降级的异常时，来使用它

@HystrixCommand注解的ignoreExceptions属性可以指定忽略的异常类型

异常获取

在继承方式实现Hystrix命令中，可以用getFallback（）方法通过Throwable getExecutionException（）方法来获取具体的异常

注解中，只需要在fallback实现方法的参数中，增加Throwable e 对象的定义就可以了

命令名称，分组以及线程池划分

以继承方式实现的Hystrix命令使用类名为默认的命令名称

可以在构造函数中通过Setter静态类来设置

Photo 1

命令组

通过设置命令组，Hystrix会根据组来组织和统计命令的告警，仪表盘等信息

默认情况下，Hystrix会让相同组名的命令使用同一个线程池

线程池

Hystrix还提供了HystrixThreadPoolKey来对线程池进行设置，可以实现更细粒度的线程池的划分

注解中和编程中的实现

Photo 1

请求缓存

开启请求缓存功能

可以通过重载getCacheKey（）方法来开启请求缓存

Photo 1

通过在getCacheKey方法中返回的请求缓存key值，就能让该请求命令具备缓存功能

当不同的外部请求处理逻辑调用了同一个依赖服务时，Hystrix 会根据getCacheKey方法返回的值来区分是否是重复请求

如果cacheKey相同，那么该依赖服务只会在第一个请求到达时被真实调用，另一个请求则直接从缓存中返回结果

好处

减少请求数，降低依赖服务的并发度

在同一用户请求的上下文中，相同依赖服务的返回数据始终保持一致

请求缓存在run（）和construct（）执行之前生效，可以减少不必要的线程开销

清理失效缓存功能

在写操作时进行清理，防止读操作请求命令获取到了失效的数据

可以通过HystrixequestCache.clear()来清理缓存

Photo 1

Photo 2

HystrixReuqestCache.getInstance（GETTER_KEY,HystrixConcuerrencyStrategyDefault.getInstance()）

从默认的Hystrix并发策略中根据GETTER_KEY获取HystrixRequestCache的实例

工作原理

getCacheKey（）方法的默认实现是返回null，所以只有重载这个方法才能实现请求缓存

同时请求命令的缓存开启属性也需要设置为true才能开启

从命令异步执行的核心方法toObservable（）

尝试获取请求缓存

通过isRequestCachingEnabled（）方法判断当前命令是否启用了请求缓存

如果开启了缓存，就通过getCacheKey（）获取一个非null的缓存Key值

通过这个Key值调用HystrixRequestCache中的get（String cacheKey）来获取缓存的HystrixCachedObservable对象

将请求结果加入缓存

判断当前命令是否开启了请求缓存功能，如果开启了就调用getCacheKey（）获取缓存key

将命令执行结果hystrixObservable对象包装成请求缓存结果HystrixCacheObservable的实例对象，放入当前命令的缓存对象中

使用注解实现请求缓存

Photo 1

设置请求缓存

通过注解为请求命令开启缓存功能

Hystrix会将返回的结果置入请求缓存中，它的缓存Key值会使用所有的参数

定义缓存Key

当使用注解定义请求缓存时，若要为请求命令指定具体的缓存Key生成规则

可以使用@CacheResult和@CacheRemove注解的cacheKeyMethod方法来指定具体的生成函数

也可以通过使用@CacheKey注解在方法中指定用于组装缓存Key的元素

比cacheKeyMethod的优先级低，使用了cacheKeyMethod那么@CacheKey注解就不生效了

还允许访问参数对象的内部属性作为缓存Key，如： @CacheKey（"id"）User user

Photo 1

缓存清理

通过@CacheRemove注解来实现失效缓存的清理

注解中commandKey属性必须要指定，用来指明需要使用请求缓存的请求命令，只有通过该属性的配置，才能找到正确的请求命令缓存位置

请求合并

因为依赖服务的线程池资源有限，将出现排队等待和响应延迟的情况

Hystrix提供了HystrixCollapser来实现请求的合并

HystrixCollapser实现了在HystrixCommand之前放置一个合并处理器，将处于一个很短的时间窗（默认10毫秒）内对同一依赖服务的多个请求进行合并并以批量方式发送请求的功能

三个类型

BathReturnType

合并后批量请求的返回类型

ResponseType

单个请求返回的类型

RequestArgumentType

请求参数类型

三个抽象方法

getRequestArgument()

定义获取请求参数的方法

createCommand（Collection> requests）

合并请求产生批量命令的具体实现方法

mapResponseToRequests（BatchReturnType batchResponse,Collection> requests）

批量命令结果返回后的处理，这里需要实现将批量结果拆分并传递给合并前的各个原子请求命令的逻辑

代码使用

Photo 1

为请求合并的实现准备一个批量请求命令实现

Photo 1

通过继承HystrixCollapser实现请求合并器

Photo 1

通过注解实现请求合并器

范例

通过collapserProperties属性为合并请求器设置了相关属性

设置了合并时间窗为100毫秒

batchMethod属性制订了批量请求的实现方法

请求合并的额外开销（衡量延迟时间窗的时间损耗）

请求命令本身的延迟

如果依赖服务的请求命令本身是一个高延迟的命令，可以使用请求合并器

延迟时间窗的并发量

如果一个时间窗内具有很高的并发量

属性详解（优先级从低到高）

全局默认值

全局配置属性

通过配置文件中定义全局属性值

可以通过其他组件实现动态刷新配置

实例默认值

通过代码为实例定义的默认值

实例配置属性

通过配置文件来指定的实例进行属性配置

通过其他组件可以实现对具体实例配置动态调整

其他配置

Photo 1

服务治理：Spring Cloud Eureka

服务治理

服务注册

在服务治理框架中，通常构建一个注册中心，每个服务单元向注册中心登记自己提供的服务

将主机及端口号，版本号，通讯协议等一些附加信息告知注册中心

注册中心按照服务名分类组织服务清单

服务发现

调用方需要向服务注册中心咨询服务，并获取所有服务的实例清单，以实现对具体实例的访问

在服务治理框架下，服务间调用通过向服务名发起请求调用实现

Netflix Eureka

Eureka服务端，服务注册中心，支持高可用配置

Eureka客户端，主要处理服务的注册与发现

实例

搭建注册中心

注册中心

Photo 1

Photo 2

注册服务提供者

Photo 1

Photo 2

高可用注册中心

两个注册中心互相注册

服务治理机制

服务提供者

服务注册

服务提供者在启动的时候会发送REST请求将自己注册到Eureka Server，同时带上自身服务的一些元数据

Eureka Server接收到REST请求之后，将元数据存储在一个双层结构Map中，第一层的key是服务名，第二层的key是具体服务的实例名

eureka.client.register-with-eureka=true 启动注册操作

服务同步

服务注册中心互相注册为服务，当服务通过者发送注册请求到一个服务注册中心时，它会将该请求转发给集群中相连的其他注册中心，从而实现注册中心之间的服务同步

服务续约

与注册中心维持的心跳

Photo 1

服务消费者

获取服务

服务消费者在启动时，会发送一个REST请求给服务注册中心，来获取注册的服务清单

Eureka Server会维护一份只读的服务清单给客户端，缓存清单30秒更新一次

eureka.client.fetch-registry=true,获取服务配置，默认为true

修改缓存清单更新时间，eureka.client.registry-fetch-interval-seconds=30,默认是30

服务调用

服务清单中有提供服务的实例名和该实例的元数据信息

客户端可以根据自己的需要决定调用，在Ribbon中默认采用轮询，从而实现客户端的负载均衡

Region 和 Zone

一个Region中可以包含多个zone

每个服务客户端需要被注册到一个Zone中，所以每个客户端对应一个Region和一个Zone

在服务调用时，优先访问同处一个Zone中的服务提供方，若访问不到，就访问其他的Zone

服务下线

当服务实例进行正常的关闭操作时，会触发一个服务下线的REST请求给Eureka Srever

注册中心收到请求后，会将服务状态置为下线（DOWN），并把该下线事件传播出去

服务注册中心

失效剔除

Eureka server 在启动后，会创建一个定时任务

默认每隔一段时间将当前清单中超时没有续约的服务剔除

自我保护

Photo 1

当注册中心统计心跳失败的比例在15分钟之内是否低于85％

单机调试容易满足，线上通常是网络不稳定

注册中心会将当前实例注册信息保护起来，让这些实例不会过期，尽可能保护这些注册信息

但，如果在这段时间内实例出现问题，那么客户端容易拿到已经不存在的实例

出现调用失败的情况

所以客户端必须要有容错机制，比如请求重试，断路器等

关闭自我保护配置，eureka.server.enable-self-preservation=false

代码分析

DiscoveryClient

该类用于帮助与Eureka Server互相协作

负责任务

向 Eureka Server注册服务实例

向Eureka Server服务租约

当服务关闭期间，向Eureka Server取消租约

查询Eureka Server中的服务实例列表

需要配置一个Eureka Server的URL列表

通过 eureka.client.serviceUrl.defaultZone配置

Region，Zone

Region

一个微服务应用只可以属于一个Region，默认是default

可以通过Eureka.client.region属性来定义

客户端的加载顺序第一个是Region，第二个是zone

Zone

没有特别为Region配置Zone的时候，默认采用defaultZone

配置eureka.client.serviceUrl.defaultZone的由来

指定zone，可以通过eureka.client.availability-zones的属性来设置

zone可以配置多个，以逗号分隔

Region和Zone是一对多的关系

serviceUrls

在获取Region和Zone的信息，才开始真正加载Eureka Server的具体地址

根据传入的参数按一定算法确定加载位于哪一个zone配置的serviceUrls

微服务应用中使用Ribbon来实现服务调用时，可以通过Zone属性的定义，配合实际部署的物理结构，有效设计出对区域性故障的容错集群

服务注册，获取，续约

都是通过定时任务来实现的

服务注册中心处理

配置详解

服务注册相关的配置信息，包括服务注册中心的地址，服务获取的间隔时间，可用区域等

都是以eureka.client为前缀

Photo 1

服务实例相关的配置信息，包括服务实例的名称，IP地址，端口号，健康检查路径等

都是以eureka.instance为前缀

元数据

com.netflix.appinfo.InstanceInfo类中对元数据的定义

标准化元数据

eureka.instance.=

就是EurekaInstanceConfigBean对象中的成员变量名

自定义元数据

eureka.instance.metadataMap.=

常用元数据

实例名配置

区分同一服务中不同实例的唯一标识，默认使用主机名

Photo 1

端点配置

Photo 1

健康检测

Photo 1

其他配置

Photo 1

跨平台支持

使用HTTP的REST接口实现

有多语言对其的支持

通信协议

Eureka 使用Jersey和XStream配合JSON作为server和client之间的通讯协议，可替换

Photo 1

基础知识

微服务架构

将一个原本独立的系统拆分成多个小型服务，这些小型服务都在各自独立的进程中运行，服务之间通过基于HTTP的RESTful API进行通信协作

服务组件化

按业务组织团队

做"产品"的态度

智能端点和哑管道

去中心化治理

去中心化管理数据

分布式事物实现难度非常大，强调在服务之间进行"无事务"调用

数据最终一致性

通过补偿机制处理错误数据，达到最终一致性

基础设施自动化

自动化测试

自动化部署

容错设计

防止故障的蔓延

快速检测出故障源，尽可能自动恢复服务

演进式设计

各类分布式框架

分支主题

spring cloud简介

介绍

一个基于Spring boot实现的微服务架构开发工具

为微服务架构汇总涉及的配置管理，服务治理，断路器，智能路由，微代理，控制总线，全局锁，决策竞选，分布式会话和集群状态管理等操作提供了一种简单的开发方式

组成子项目

Spring Cloud Config

配置管理工具

Spring Cloud Netflix

核心组件，对多个Netflix OSS开源套件进行整合

Eureka

服务治理组件，包含服务注册中心，服务注册和发现机制的实现

Hystrix

容错管理组件，实现断路器模式，帮助服务依赖中出现的延迟和为故障提供强大的容错能力

Ribbon

客户端负载均衡的服务调用组件

Feign

基于Ribbon和Hystrix的声明式服务调用组件

Zuul

网关组件

Archaius

外部化配置组件

组件列举