springcloud经典版（如何学习spring cloud）

本文目录

• 如何学习spring cloud
• SpringCloud入门简述
• Spring Cloud基础之Config Server配置中心简单搭建
• 如何选择Spring Boot最稳定的版本，以及相应的Spring Cloud版本
• 如何使用Spring Cloud
• Spring Cloud系列之链路追踪

如何学习spring cloud

Spring Cloud 学习笔记（一）——入门、特征、配置
0 放在前面
0.1 参考文档
***隐藏网址***
***隐藏网址***
***隐藏网址***
0.2 maven配置
《parent》
《groupId》org.springframework.boot《/groupId》
《artifactId》spring-boot-starter-parent《/artifactId》
《version》1.5.2.RELEASE《/version》
《/parent》
《dependencyManagement》
《dependencies》
《dependency》
《groupId》org.springframework.cloud《/groupId》
《artifactId》spring-cloud-dependencies《/artifactId》
《version》Dalston.RELEASE《/version》
《type》pom《/type》
《scope》import《/scope》
《/dependency》
《/dependencies》
《/dependencyManagement》
《dependencies》
《dependency》
《groupId》org.springframework.cloud《/groupId》
《artifactId》spring-cloud-starter-config《/artifactId》
《/dependency》
《dependency》
《groupId》org.springframework.cloud《/groupId》
《artifactId》spring-cloud-starter-eureka《/artifactId》
《/dependency》
《/dependencies》
0.3 简介
Spring Cloud为开发人员提供了快速构建分布式系统中的一些通用模式（例如配置管理，服务发现，断路器，智能路由，微代理，控制总线，一次性令牌，全局锁，领导选举，分布式 会话，群集状态）。 分布式系统的协调引出样板模式（boiler plate patterns），并且使用Spring Cloud开发人员可以快速地实现这些模式来启动服务和应用程序。 它们可以在任何分布式环境中正常工作，包括开发人员自己的笔记本电脑，裸机数据中心和受管平台，如Cloud Foundry。
Version: Brixton.SR7
1 特征
Spring Cloud专注于为经典用例和扩展机制提供良好的开箱即用
分布式/版本配置
服务注册与发现
路由选择
服务调用
负载均衡
熔断机制
全局锁
领导人选举和集群状态
分布式消息
2 原生云应用程序
原生云是应用程序开发的一种风格，鼓励在持续交付和价值驱动领域的最佳实践。
Spring Cloud的很多特性是基于Spring Boot的。更多的是由两个库实现：Spring Cloud Context and Spring Cloud Commons。
2.1 Spring Cloud Context: 应用上下文服务
Spring Boot关于使用Spring构建应用有硬性规定：通用的配置文件在固定的位置，通用管理终端，监控任务。建立在这个基础上，Spring Cloud增加了一些额外的特性。
2.1.1 引导应用程序上下文
Spring Cloud会创建一个“bootstrap”的上下文，这是主应用程序的父上下文。对应的配置文件拥有最高优先级，并且，默认不能被本地配置文件覆盖。对应的文件名bootstrap.yml或bootstrap.properties。
可通过设置spring.cloud.bootstrap.enabled=false来禁止bootstrap进程。
2.1.2 应用上下文层级结构
当用SpringApplication或SpringApplicationBuilder创建应用程序上下文时，bootstrap上下文将作为父上下文被添加进去，子上下文将继承父上下文的属性。
子上下文的配置信息可覆盖父上下文的配置信息。
2.1.3 修改Bootstrap配置文件位置
spring.cloud.bootstrap.name（默认是bootstrap），或者spring.cloud.bootstrap.location（默认是空）
2.1.4 覆盖远程配置文件的值
spring.cloud.config.allowOverride=true
spring.cloud.config.overrideNone=true
spring.cloud.config.overrideSystemProperties=false
2.1.5 定制Bootstrap配置
在/META-INF/spring.factories的key为org.springframework.cloud.bootstrap.BootstrapConfiguration，定义了Bootstrap启动的组件。
在主应用程序启动之前，一开始Bootstrap上下文创建在spring.factories文件中的组件，然后是@Beans类型的bean。
2.1.6 定制Bootstrap属性来源
关键点：spring.factories、PropertySourceLocator
2.1.7 环境改变
应用程序可通过EnvironmentChangedEvent监听应用程序并做出响应。
2.1.8 Refresh Scope
Spring的bean被@RefreshScope将做特殊处理，可用于刷新bean的配置信息。
注意
需要添加依赖“org.springframework.boot.spring-boot-starter-actuator”
目前我只在@Controller测试成功
需要自己发送POST请求/refresh
修改配置文件即可
2.1.9 加密和解密
Spring Cloud可对配置文件的值进行加密。
如果有"Illegal key size"异常，那么需要安装JCE。
2.1.10 服务点
除了Spring Boot提供的服务点，Spring Cloud也提供了一些服务点用于管理，注意都是POST请求
/env：更新Environment、重新绑定@ConfigurationProperties跟日志级别
/refresh重新加载配置文件，刷新标记@RefreshScope的bean
/restart重启应用，默认不可用
生命周期方法：/pause、/resume
2.2 Spring Cloud Commons:通用抽象
服务发现、负载均衡、熔断机制这种模式为Spring Cloud客户端提供了一个通用的抽象层。
2.2.1 RestTemplate作为负载均衡客户端
通过@Bean跟@LoadBalanced指定RestTemplate。注意URI需要使用虚拟域名（如服务名，不能用域名）。
如下：
@Configuration
public class MyConfiguration {
@LoadBalanced
@Bean
RestTemplate restTemplate() {
return new RestTemplate();
}
}
public class MyClass {
@Autowired
private RestTemplate restTemplate;
public String doOtherStuff() {
***隐藏网址***
return results;
}
}
2.2.2 多个RestTemplate对象
注意@Primary注解的使用。
@Configuration
public class MyConfiguration {
@LoadBalanced
@Bean
RestTemplate loadBalanced() {
return new RestTemplate();
}
@Primary
@Bean
RestTemplate restTemplate() {
return new RestTemplate();
}
}
public class MyClass {
@Autowired
private RestTemplate restTemplate;
@Autowired
@LoadBalanced
private RestTemplate loadBalanced;
public String doOtherStuff() {
***隐藏网址***
}
public String doStuff() {
***隐藏网址***
}
}
2.2.3 忽略网络接口
忽略确定名字的服务发现注册，支持正则表达式配置。
3 Spring Cloud Config
Spring Cloud Config提供服务端和客户端在分布式系统中扩展配置。支持不同环境的配置（开发、测试、生产）。使用Git做默认配置后端，可支持配置环境打版本标签。
3.1 快速开始
可通过IDE运行或maven运行。
默认加载property资源的策略是克隆一个git仓库(at spring.cloud.config.server.git.uri’)。
HTTP服务资源的构成：
/{application}/{profile}
/{application}-{profile}.yml
/{label}/{application}-{profile}.yml
/{application}-{profile}.properties
/{label}/{application}-{profile}.properties
application是SpringApplication的spring.config.name,(一般来说’application’是一个常规的Spring Boot应用),profile是一个active的profile(或者逗号分隔的属性列表),label是一个可选的git标签(默认为"master")。
3.1.1 客户端示例
创建以Spring Boot应用即可，添加依赖“org.springframework.cloud:spring-cloud-starter-config”。
配置application.properties，注意URL为配置服务端的地址
***隐藏网址***
3.2 Spring Cloud Config 服务端
针对系统外的配置项(如name-value对或相同功能的YAML内容),该服务器提供了基于资源的HTTP接口。使用@EnableConfigServer注解,该服务器可以很容易的被嵌入到Spring Boot 系统中。使用该注解之后该应用系统就是一个配置服务器。
@SpringBootApplication
@EnableConfigServer
public class ConfigApplicion {
public static void main(String args) throws Exception {
SpringApplication.run(ConfigApplicion.class, args);
}
}
3.2.1 资源库环境
{application} 对应客户端的"spring.application.name"属性
{profile} 对应客户端的 "spring.profiles.active"属性(逗号分隔的列表)
{label} 对应服务端属性,这个属性能标示一组配置文件的版本
如果配置库是基于文件的，服务器将从application.yml和foo.yml中创建一个Environment对象。高优先级的配置优先转成Environment对象中的PropertySource。
3.2.1.1 Git后端
默认的EnvironmentRepository是用Git后端进行实现的，Git后端对于管理升级和物理环境是很方便的,对审计配置变更也很方便。也可以file:前缀从本地配置库中读取数据。
这个配置库的实现通过映射HTTP资源的{label}参数作为git label(提交id,分支名称或tag)。如果git分支或tag的名称包含一个斜杠 ("/"),此时HTTP URL中的label需要使用特殊字符串"(_)"来替代(为了避免与其他URL路径相互混淆)。如果使用了命令行客户端如 curl，请谨慎处理URL中的括号(例如：在shell下请使用引号’’来转义它们)。
Git URI占位符
Spring Cloud Config Server支持git库URL中包含针对{application}和 {profile}的占位符(如果你需要,{label}也可包含占位符, 不过要牢记的是任何情况下label只指git的label)。所以，你可以很容易的支持“一个应用系统一个配置库”策略或“一个profile一个配置库”策略。
模式匹配和多资源库
spring:
cloud:
config:
server:
git:
***隐藏网址***
repos:
***隐藏网址***
special:
pattern: special*/dev*,*special*/dev*
***隐藏网址***
local:
pattern: local*
uri: file:/home/configsvc/config-repo
如果 {application}/{profile}不能匹配任何表达式，那么将使用“spring.cloud.config.server.git.uri”对应的值。在上例子中，对于 "simple" 配置库, 匹配模式是simple/* (也就说,无论profile是什么，它只匹配application名称为“simple”的应用系统)。“local”库匹配所有application名称以“local”开头任何应用系统，不管profiles是什么(来实现覆盖因没有配置对profile的匹配规则，“/*”后缀会被自动的增加到任何的匹配表达式中)。
Git搜索路径中的占位符
spring.cloud.config.server.git.searchPaths
3.2.1.2 版本控制后端文件系统使用
伴随着版本控制系统作为后端(git、svn)，文件都会被check out或clone 到本地文件系统中。默认这些文件会被放置到以config-repo-为前缀的系统临时目录中。在Linux上，譬如应该是/tmp/config-repo-《randomid》目录。有些操作系统routinely clean out放到临时目录中，这会导致不可预知的问题出现。为了避免这个问题，通过设置spring.cloud.config.server.git.basedir或spring.cloud.config.server.svn.basedir参数值为非系统临时目录。
3.2.1.3 文件系统后端
使用本地加载配置文件。
需要配置：spring.cloud.config.server.native.searchLocations跟spring.profiles.active=native。
路径配置格式：classpath:/, classpath:/config,file:./, file:./config。
3.2.1.4 共享配置给所有应用
基于文件的资源库
在基于文件的资源库中(i.e. git, svn and native)，这样的文件名application*命名的资源在所有的客户端都是共享的(如 application.properties, application.yml, application-*.properties,etc.)。
属性覆盖
“spring.cloud.config.server.overrides”添加一个Map类型的name-value对来实现覆盖。
例如
spring:
cloud:
config:
server:
overrides:
foo: bar
会使所有的配置客户端应用程序读取foo=bar到他们自己配置参数中。
3.2.2 健康指示器
通过这个指示器能够检查已经配置的EnvironmentRepository是否正常运行。
通过设置spring.cloud.config.server.health.enabled=false参数来禁用健康指示器。
3.2.3 安全
你可以自由选择任何你觉得合理的方式来保护你的Config Server（从物理网络安全到OAuth3 令牌），同时使用Spring Security和Spring Boot 能使你做更多其他有用的事情。
为了使用默认的Spring Boot HTTP Basic 安全，只需要把Spring Security 增加到classpath中(如org.springframework.boot.spring-boot-starter-security)。默认的用户名是“user”，对应的会生成一个随机密码，这种情况在实际使用中并没有意义，一般建议配置一个密码（通过 security.user.password属性进行配置）并对这个密码进行加密。
3.2.4 加密与解密
如果远程属性包含加密内容(以{cipher}开头),这些值将在通过HTTP传递到客户端之前被解密。
使用略
3.2.5 密钥管理
配置服务可以使用对称(共享)密钥或者非对称密钥(RSA密钥对)。
使用略
3.2.6 创建一个测试密钥库
3.2.7 使用多密钥和循环密钥
3.2.8 加密属性服务
3.3 可替换格式服务
配置文件可加后缀".yml"、".yaml"、".properties"
3.4 文本解释服务
/{name}/{profile}/{label}/{path}
3.5 嵌入配置服务器
一般配置服务运行在单独的应用里面，只要使用注解@EnableConfigServer即可嵌入到其他应用。
3.6 推送通知和总线
添加依赖spring-cloud-config-monitor，激活Spring Cloud 总线，/monitor端点即可用。
当webhook激活，针对应用程序可能已经变化了的，配置服务端将发送一个RefreshRemoteApplicationEvent。
3.7 客户端配置
3.7.1 配置第一次引导
通过spring.cloud.config.uri属性配置Config Server地址
3.7.2 发现第一次引导
如果用的是Netflix，则用eureka.client.serviceUrl.defaultZone进行配置。
3.7.3 配置客户端快速失败
在一些例子里面，可能希望在没有连接配置服务端时直接启动失败。可通过spring.cloud.config.failFast=true进行配置。
3.7.4 配置客户端重试
添加依赖spring-retry、spring-boot-starter-aop，设置spring.cloud.config.failFast=true。默认的是6次重试，初始补偿间隔是1000ms，后续补偿为1.1指数乘数，可通过spring.cloud.config.retry.*配置进行修改。
3.7.5 定位远程配置资源
路径：/{name}/{profile}/{label}
"name" = ${spring.application.name}
"profile" = ${spring.profiles.active} (actually Environment.getActiveProfiles())
"label" = "master"
label对于回滚到之前的版本很有用。
3.7.6 安全
通过spring.cloud.config.password、spring.cloud.config.username进行配置。

SpringCloud入门简述

1、SpringCloud是基于SpringBoot实现的微服务框架，为开发人员提供了很多快速构建分布式系统中常见模式的工具，包括配置管理、服务发现、断路器、智能路由、微代理，控制总线等。

2、SpringCloud是基于SpringBoot基础之上开发的微服务框架，SpringCloud是一套目前非常完整的微服务解决方案框架，其内容包含服务治理、注册中心、配置管理、断路器、智能路由、微代理、控制总线、全局锁、分布式会话等。

3、不像Spring（SpringFramework），大体上能够理解为它是一个管理bean的容器。也不想SpringBoot，可以理解为它是加强版的Spring，集成了SSM和其它一些框架，并且大量支持和推荐注解开发。

Spring Cloud基础之Config Server配置中心简单搭建

1.创建Config Server服务

2.启动时需要默认的SpringCloudserver已经启动
通过url可以找到对应的配置内容

3.配置config client

***隐藏网址***
配置文件需要增加

如何选择Spring Boot最稳定的版本，以及相应的Spring Cloud版本

1、登录 Spring的官网 ，查看当前最稳定的版本。

当然了，想使用Spring Cloud，还需要许多的jar包，如何选择兼容的jar包呢？在这里，我们可以考虑使maven的 dependencyManagement 功能。

dependencyManagement 其实就相当于一个对jar版本进行管理的依赖管理器，如果在 dependencies 的 dependency 里没有找到 version 属性，Maven就会去 dependencyManagement 里寻找相应的版本信息。

如果既使用了 dependencyManagement 功能，又在 dependencies 的 dependency 里指定了 version 属性， dependency 是以 version 属性为准的，所以，不用担心使用 dependencyManagement 功能之后无法自行指定jar包的版本信息。

在这里，我们选择的是alibaba的版本管理配置。

首先，进入 阿里巴巴的GitHub地址 ，进入WiKi页面，点击版本说明。

或者直接点击 版本说明

我们可以看到，2.4.2版本的Spring Boot，对应的alibaba 版本是2020.0.RC1，对应的Spring Cloud版本是2020.0，我们选择2020.0.2，最终配置如下。

我这里是为了学习，所以选择的都是最新版本，在生产环境，还是要根据实际情况来详细评估选择哪些版本，以免给自己挖坑。

如何使用Spring Cloud

作者：何明璐链接：/question/29483490/answer/98237582来源：知乎著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。首先是不建议采用XA两阶段提交方式去处理分布式事务，要知道要能够支持XA分布式事务，必须是要实现XA规范才可以，而Service本身是无状态的，如果这样去做了等于是把Service内部的东西暴露了出去。对于分布式事务最好的方式还是事务补偿或者BASE基于消息的最终一致性。可以设想一个最简单的分布式事务场景，对于跨银行的转账操作，该操作涉及到调用两个异地的Service服务，一个是本地提供的取款服务，一个是目标银行提供的存款服务，该两个服务本身无状态且独立，构成一个完整的事务。对于事务的处理初步分析:事务补偿机制事务补偿即在事务链中的任何一个正向事务操作，都必须存在一个完全符合回滚规则的可逆事务。如果是一个完整的事务链，则必须事务链中的每一个业务服务或操作都有对应的可逆服务。对于Service服务本身无状态，也不容易实现前面讨论过的通过DTC或XA机制实现的跨应用和资源的事务管理，建立跨资源的事务上下文。因此也较难以实现真正的预提交和正式提交的分离。在这种情况下以上面例子来说，首先调用取款服务，完全调用成功并返回，数据已经持久化。然后调用异地的存款服务，如果也调用成功，则本身无任何问题。如果调用失败，则需要调用本地注册的逆向服务（本地存款服务），如果本地存款服务调用失败，则必须考虑重试，如果约定重试次数仍然不成功，则必须log到完整的不一致信息。也可以是将本地存款服务作为消息发送到消息中间件，由消息中间件接管后续操作。在上面方式中可以看到需要手工编写大量的代码来处理以保证事务的完整性，我们可以考虑实现一个通用的事务管理器，实现事务链和事务上下文的管理。对于事务链上的任何一个服务正向和逆向操作均在事务管理和协同器上注册，由事务管理器接管所有的事务补偿和回滚操作。基于消息的最终一致性在这里首先要回答的是我们需要时实时一致性还是最终一致性的问题，如果需要的是最终一致性，那么BASE策略中的基于消息的最终一致性是比较好的解决方案。这种方案真正实现了两个服务的真正解耦，解耦的关键就是异步消息和消息持久化机制。还是以上面的例子来看。对于转账操作，原有的两个服务调用变化为第一步调用本地的取款服务，第二步发送异地取款的异步消息到消息中间件。如果第二步在本地，则保证事务的完整性基本无任何问题，即本身就是本地事务的管理机制。只要两个操作都成功即可以返回客户成功。由于解耦，我们看到客户得到成功返回的时候，如果是上面一种情况则异地卡马上就能查询账户存款增加。而第二种情况则不一定，因为本身是一种异步处理机制。消息中间件得到消息后会去对消息解析，然后调用异地银行提供的存款服务进行存款，如果服务调用失败则进行重试。异地银行存款操作不应该长久地出现异常而无法使用，因此一旦发现异常我们可以迅速的解决，消息中间件中异常服务自然会进行重试以保证事务的最终一致性。这种方式假设问题一定可以解决，在不到万不得已的情况下本地的取款服务一般不进行可逆操作。在本地取款到异地存款两个服务调用之间，会存在一个真空期，这段时间相关现金不在任何一个账户，而只是在一个事务的中间状态，但是客户并不关心这个，只要在约定的时间保证事务最终的一致性即可。关于等幂操作的问题重复调用多次产生的业务结果与调用一次产生的业务结果相同，简单点讲所有提供的业务服务，不管是正向还是逆向的业务服务，都必须要支持重试。因为服务调用失败这种异常必须考虑到，不能因为服务的多次调用而导致业务数据的累计增加或减少。关于是否可以补偿的问题在这里我们谈的是多个跨系统的业务服务组合成一个分布式事务，因此在对事务进行补偿的时候必须要考虑客户需要的是否一定是最终一致性。客户对中间阶段出现的不一致的承受度是如何的。在上面的例子来看，如果采用事务补偿机制，基本可以是做到准实时的补偿，不会有太大的影响。而如果采用基于消息的最终一致性方式，则可能整个周期比较长，需要较长的时间才能给得到最终的一致性。比如周六转款，客户可能下周一才得到通知转账不成功而进行了回退，那么就必须要考虑客户是否能给忍受。其次对于前面讨论，如果真正需要的是实时的一致性，那么即使采用事务补偿机制，也无法达到实时的一致性。即很可能在两个业务服务调用中间，客户前台业务操作对持久化的数据进行了其它额外的操作。在这种模式下，我们不得不考虑需要在数据库表增加业务状态锁的问题，即整个事务没有完整提交并成功前，第一个业务服务调用虽然持久化在数据库，但是仍然是一个中间状态，需要通过业务锁来标记，控制相关的业务操作和行为。但是在这种模式下无疑增加了整个分布式业务系统的复杂度。

Spring Cloud系列之链路追踪

Spring Cloud系列之Eureka
Spring Cloud系列之配置中心Config
Spring Cloud系列之gateway
Spring Cloud系列之Feign
Spring Cloud系列之Hystrix
Spring Cloud系列之链路追踪

在微服务架构下，一次请求至少经过三四次服务调用完成，多则跨越七八个，那么问题接踵而来

基于上面得问题，就应运而生了分布式调用链路追踪技术

本质：记录日志，进行分析、排障

一次请求我们可以想象成一棵树，如下图：

Trace ：一次完整的分布式调用跟踪链路,由一系列Span 组成的一个树状结构

TraceId ：为了实现请求跟踪，当请求发送到分布式系统的入口时，我们为该请求创建一个唯一跟踪表示traceId,同时在分布式系统内部流转时，框架始终保持该唯一标识。

Span（跨度） ： 追踪服务调基本结构，表示跨服务的一次调用； 多span形成树形结构，组合成一次Trace追踪记录。对于一个span节点必须有开始和结束节点，通过记录开始和结束的时间戳，就可以计算出调用该服务的一个耗时。每一个Span通过一个64位ID来进行唯一标识即spanId，并通过另一个64位ID对Span所在的Trace进行唯一标识。（注意：启动一个Trace的初始化Span被叫作 Root Span ，它的 Span ID 和 Trace Id 相同。）

span除了时间戳外，还可以包含一些其他元素数据，比如请求信息 parentId、traceId、spanId。

Annotation ：用来及时记录一个事件的存在。通过引入 Brave 库，我们不用再去设置一系列的特别事件，从而让 Zipkin 能够知道客户端和服务器是谁、请求是从哪里开始的、又到哪里结束。出于学习的目的，还是把这些事件在这里列举一下：

Cs CLIENT_SEND，客户端发起请求

Cr CLIENT_RECIEVE，客户端收到响应

Sr SERVER_RECIEVE，服务端收到请求

Ss SERVER_SEND，服务端发送结果

下面我们就重点来了解下 sleuth + zipkin

追踪服务框架，Sleuth就是通过记录日志的方式来追踪数据的，我们可以通过记录的日志，进行：

我们往往把spring cloud sleuth和zipkin一起使用，把sleuth的数据信息发送给zipkin进行聚合，利用zipkin存储进行数据展示，具体实现流程如下：

在application.yml中添加日志级别

运行项目，发起请求，我们可以看到user-api打印结果：

***隐藏网址***

其中type方式有三种

还有 采样率 的问题

生产环境下，如果采用全部采集，那产生的踪迹数据量就是一个天量，对于网络和server端的压力就非常大了，而且没必要采集所有的数踪迹数据进行分析，我们只需要采集一部分进行分析就可以了，这里我们本地方便查看就设置为1，线上我们可以根据我们自己的需求，综合考量，设置一个合适的采样率

运行项目，访问接口，我们可以看到如下页面：

注意：spans的个数是按照入口和出口进行计算的比如第一条请求，请求入gateway算一个，gateway向user-api发起请求算一个，入user-api算一个，以此类推，第一个请求就有5个span

具体请求链路详情我们可以点击一个进入：

在这里我们简单介绍下，如果我们不持久化数据，数据是保存到内存中的，一旦服务重启，数据就丢失了，而且数据保存到内存中也存在很大的问题，一般我们持久化链路踪迹数据，Zipkin支持将追踪数据持久化到mysql或者es中，一般我们用的比较多的是es。

Spring Cloud系列之Eureka
Spring Cloud系列之配置中心Config
Spring Cloud系列之gateway
Spring Cloud系列之Feign
Spring Cloud系列之链路追踪