Spring Cloud 微服务工具集（版本: Hoxton SR6）
Spring Cloud 微服务工具集
1.什么是微服务
2.为什么是微服务?
单体应用
微服务架构应用
架构的演变
3.微服务的解决方案
4.什么是SpringCloud
官方定义
核心架构及其组件
5.环境搭建
版本命名
版本选择
环境搭建
6.服务注册中心
什么服务注册中心
常用的注册中心
1.Eureka
2.Consul
7. 服务间通信方式
什么是微服务
如何解决微服务的服务通信问题？
如何在java代码中发起http方式请求？
基于RestTemplate的服务调用
RestTemplate 服务调用
使用RestTemplate对象实现服务间通信存在问题
Ribbon负载均衡原理
使用Ribbon+RestTemplate实现请求负载均衡
Ribbon组件实现负载均衡的原理
面试问题：
Ribbon组件源码分析
Ribbon负载均衡策略支持哪些？
设置服务间调用负载均衡策略（在用户服务配置文件里写）
Ribbon组件现在的状态
8.OpenFeign组件的使用
存在问题:
说明：
openFeign 服务调用
调用服务并传参
零散类型参数传递
对象类型参数传递
数组参数传递
集合类型的参数接收
openfegin的响应处理
OpenFegin默认超时处理
OpenFeign调用详细日志展示
9.Hystrix组件使用
服务雪崩
服务熔断 =====》Hystrix
服务降级
降级和熔断总结
服务熔断的实现
服务降级的实现
Hystrix Dashboard(仪表盘) NetFlix
Hystrix停止维护
10.Gateway组件使用
什么是服务网关
服务网关组件
zuul 1.x 2.x(netflix 组件)
gateway (spring) ==**=路由转发+请求过滤**==
11.Config组件使用
什么是Config
统一配置中心组件流程图
Config Server 开发（config client --->config server---->远端git仓库）
Config Client 开发
手动配置刷新
12.Bus组件的使用
什么是Bus (AMQP RibbitMQ、Kafka）
实现配置刷新原理
MQ
搭建RabbitMQ服务
实现自动配置刷新
集成webhook(web 钩子)实现自动刷新
13.SpringCloud 微服务工具集总结
Spring Cloud 微服务工具集
版本: Hoxton SR6
1.什么是微服务
官网: https://www.martinfowler.com/articles/microservices.html
In short, the microservice architectural(架构) style is an approach to developing a single application as a suite(系列) of small services, each running in its own process(进程) and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business(业务) capabilities(单元) and independently(独立) deployable(部署) by fully automated deployment machinery. There is a bare(基于) minimum of centralized(分布式) management(管理) of these services, which may be written in different programming languages and use different data storage technologies. -----[摘自官网]
- a suite of small services --一系列微小服务
- running in its own process --运行在自己的进程里
- built around business capabilities --围绕自己的业务开发
- independently deployable --独立部署
- bare minimum of centralized management of these services --基于分布式管理
官方定义:微服务就是由一系列围绕自己业务开发的微小服务构成,他们独立部署运行在自己的进程里,基于分布式的管理
通俗定义:微服务是一种架构，这种架构是将单个的整体应用程序分割成更小的项目关联的独立的服务。一个服务通常实现一组独立的特性或功能，包含自己的业务逻辑和适配器。各个微服务之间的关联通过暴露api来实现。这些独立的微服务不需要部署在同一个虚拟机，同一个系统和同一个应用服务器中。
2.为什么是微服务?
单体应用
# 1.优点
- 单一架构模式在项目初期很小的时候开发方便，测试方便，部署方便，运行良好。
# 2.缺点
- 应用随着时间的推进，加入的功能越来越多，最终会变得巨大，一个项目中很有可能数百万行的代码，
- 互相之间繁琐的jar包。久而久之，开发效率低，代码维护困难
- 还有一个如果想整体应用采用新的技术，新的框架或者语言，那是不可能的。
- 任意模块的漏洞或者错误都会影响这个应用，降低系统的可靠性
微服务架构应用
# 1.优点
- 将服务拆分成多个单一职责的小的服务，进行单独部署，服务之间通过网络进行通信
- 每个服务应该有自己单独的管理团队，高度自治
- 服务各自有自己单独的职责，服务之间松耦合，避免因一个模块的问题导致服务崩溃
# 2.缺点
- 开发人员要处理分布式系统的复杂性
- 多服务运维难度，随着服务的增加，运维的压力也在增大
- 服务治理 和 服务监控 关键
架构的演变
# 1.架构的演变过程
- [单一应用架构] `===>` [垂直应用架构] `===>` [分布式服务架构] `===>` [流动计算架构]||[微服务
架构] `===>` [未知]
dubbo官网:http://dubbo.apache.org/zh-cn/docs/user/preface/background.html
# 1. All in One Application 单一架构
- 起初当网站流量很小时,将所有功能都写在一个应用里面,对整个应用进行部署,以减少部署节点和成本。
对于这个架构简化增删改查的工作量的数据访问框架（ORM）是关键。
# 2. Vertical Application 垂直架构
- 当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，提升效率的方法之一是将应用拆成
互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的Web框架(MVC)是关键。
# 3. Distributed Service 分布式服务架构
- 当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成
稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式
服务框架(RPC)是关键。
# 4. Elastic Computing 流动计算架构即微服务架构
- 当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问
压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心(SOA)是关键
友情提醒: 好的架构并不是设计出来的,一定是进化来的!!!
3.微服务的解决方案
# 1.Dubbo (阿里系)
- 初出茅庐:2011年末，阿里巴巴在GitHub上开源了基于Java的分布式服务治理框架Dubbo，之后它成为了
国内该类开源项目的佼佼者，许多开发者对其表示青睐。同时，先后有不少公司在实践中基于Dubbo进行
分布式系统架构，目前在GitHub上，它的fork、star数均已破万。Dubbo致力于提供高性能和透明化的
RPC远程服务调用方案，以及SOA服务治理方案，使得应用可通过高性能RPC实现服务的输出、输入功能和
Spring框架无缝集成。Dubbo包含远程通讯、集群容错和自动发现三个核心部分。
- 停止维护:从2012年10月23日Dubbo 2.5.3发布后，在Dubbo开源将满一周年之际，阿里基本停止了对
Dubbo的主要升级。只在之后的2013年和2014年更新过2次对Dubbo 2.4的维护版本，然后停止了所有维护
工作。Dubbo对Srping的支持也停留在了Spring 2.5.6版本上。
- 死而复生:多年漫长的等待，随着微服务的火热兴起，在国内外开发者对阿里不再升级维护Dubbo的吐槽声中，
阿里终于开始重新对Dubbo的升级和维护工作。在2017年9月7日，阿里发布了Dubbo的2.5.4版本，距离上
一个版本2.5.3发布已经接近快5年时间了。在随后的几个月中，阿里Dubbo开发团队以差不多每月一版本
的速度开始快速升级迭代，修补了Dubbo老版本多年来存在的诸多bug，并对Spring等组件的支持进行了
全面升级。
- 2018年1月8日，Dubbo创始人之一梁飞在Dubbo交流群里透露了Dubbo 3.0正在动工的消息。Dubbo 3.0
内核与Dubbo 2.0完全不同，但兼容Dubbo 2.0。Dubbo 3.0将以Streaming为内核，不再是Dubbo 时代
的RPC，但是RPC会在Dubbo 3.0中变成远程Streaming对接的一种可选形态。从Dubbo新版本的路线规划上
可以看出，新版本的Dubbo在原有服务治理的功能基础上，将全面拥抱微服务解决方案。
- 结论:当前由于RPC协议、注册中心元数据不匹配等问题，在面临微服务基础框架选型时Dubbo与Spring Cloud
是只能二选一，这也是为什么大家总是拿Dubbo和Spring Cloud做对比的原因之一。Dubbo之后会积极寻求
适配到Spring Cloud生态，比如作为Spring Cloud的二进制通信方案来发挥Dubbo的性能优势，或者Dubbo
通过模块化以及对http的支持适配到Spring Cloud。
# 2.Spring Cloud:
- Spring Cloud NetFlix
基于美国Netflix公司开源的组件进行封装,提供了微服务一栈式的解决方案。
- Spring Cloud alibaba
在Spring cloud netflix基础上封装了阿里巴巴的微服务解决方案。
- Spring Cloud Spring
目前spring官方趋势正在逐渐吸收Netflix组件的精华,并在此基础进行二次封装优化,打造spring专有
的解决方案
4.什么是SpringCloud
官方定义
官方网址: https://cloud.spring.io/spring-cloud-static/Hoxton.SR5/reference/html/
Spring Cloud provides tools for developers to quickly build some of the common patterns in distributed systems (e.g. configuration management, service discovery, circuit breakers, intelligent routing, micro-proxy, control bus). Coordination of distributed systems leads to boiler plate patterns, and using Spring Cloud developers can quickly stand up services and applications that implement those patterns. -------[摘自官网]
# 1.翻译
- springcloud为开发人员提供了在分布式系统中快速构建一些通用模式的工具（例如配置管理、服务发现、
断路器、智能路由、微代理、控制总线）。分布式系统的协调导致了锅炉板模式，使用springcloud开发
人员可以快速地建立实现这些模式的服务和应用程序。
# 2.通俗理解
- springcloud是一个含概多个子项目的开发工具集,集合了众多的开源框架,他利用了Spring Boot开发的
便利性实现了很多功能,如服务注册,服务注册发现,负载均衡等.SpringCloud在整合过程中主要是针对
Netflix(耐非)开源组件的封装.SpringCloud的出现真正的简化了分布式架构的开发。NetFlix 是美国的
一个在线视频网站,微服务业的翘楚,他是公认的大规模生产级微服务的杰出实践者,NetFlix的开源组件已
经在他大规模分布式微服务环境中经过多年的生产实战验证,因此Spring Cloud中很多组件都是基于
NetFlixspring netflix 维护 闭源
核心架构及其组件
# 1.核心组件说明
- eurekaserver、consul、nacos 服务注册中心组件
- rabbion & openfeign 服务负载均衡 和 服务调用组件
- hystrix & hystrix dashboard 服务断路器 和 服务监控组件
- zuul、gateway 服务网关组件
- config 统一配置中心组件
- bus 消息总线组件
......
5.环境搭建
版本命名
官网地址:https://spring.io/projects/spring-cloud
Spring Cloud is an umbrella(伞) project consisting of independent projects with, in principle, different release cadences. To manage the portfolio a BOM (Bill of Materials) is published with a curated set of dependencies on the individual project (see below). The release trains have names, not versions, to avoid confusion with the sub-projects. The names are an alphabetic sequence (so you can sort them chronologically) with names of London Tube stations (“Angel” is the first release, “Brixton” is the second). When point releases of the individual projects accumulate to a critical mass, or if there is a critical bug in one of them that needs to be available to everyone, the release train will push out “service releases” with names ending “.SRX”, where “X” is a number. —[摘自官网]
# 1.翻译
- springcloud是一个由众多独立子项目组成的大型综合项目，原则每个子项目上有不同的发布节奏,都维护
自己发布版本号。为了更好的管理springcloud的版本,通过一个资源清单BOM(Bill of Materials),为避免
与子项目的发布号混淆，所以没有采用版本号的方式，而是通过命名的方式。这些名字是按字母顺序排列的。
如伦敦地铁站的名称（“天使”是第一个版本，“布里斯顿”是第二个版本,"卡姆登"是第三个版本）。当单个
项目的点发布累积到一个临界量，或者其中一个项目中有一个关键缺陷需要每个人都可以使用时，发布序列
将推出名称以“.SRX”结尾的“服务发布”，其中“X”是一个数字。
# 2.伦敦地铁站名称 [了解]
- Angel、Brixton、Camden、Dalston、Edgware、Finchley、Greenwich、Hoxton
版本选择
# 1.版本选择官方建议 https://spring.io/projects/spring-cloud
- Angel 版本基于springboot1.2.x版本构建与1.3版本不兼容
- Brixton 版本基于springboot1.3.x版本构建与1.2版本不兼容
`2017年Brixton and Angel release官方宣布报废
- Camden 版本基于springboot1.4.x版本构建并在1.5版本通过测试
`2018年Camden release官方宣布报废
- Dalston、Edgware 版本基于springboot1.5.x版本构建目前不能再springboot2.0.x版本中使用
`Dalston(达尔斯顿)将于2018年12月官方宣布报废。Edgware将遵循Spring Boot 1.5.x的生命周期结束。
- Finchley 版本基于springboot2.0.x版本进行构建,不能兼容1.x版本
- Greenwich 版本基于springboot2.1.x版本进行构建,不能兼容1.x版本
- Hoxton 版本基于springboot2.2.x版本进行构建
Spring Cloud Dalston, Edgware, Finchley, and Greenwich have all reached end of life status and are no longer supported.
环境搭建
# 0.说明
- springboot 2.2.5.RELEASE
- springcloud Hoxton.SR6
- java8
- maven 3.3.9
- idea 2018.3.5
# 1.创建springboot项目 指定版本为 2.2.5版本
# 2.引入springcloud的版本管理
spring-cloud.version}
# 3.完成上述操作springboot与springcloud环境搭建完成
- 接下来就是使用到具体的springcloud组件,在项目中引入具体的组件即可
6.服务注册中心
什么服务注册中心
所谓服务注册中心就是在整个的微服务架构中单独提出一个服务，这个服务不完成系统的任何的业务功能，仅仅用来完成对整个微服务系统的服务注册和服务发现，以及对服务健康状态的监控和管理功能。
# 1.服务注册中心
- 可以对所有的微服务的信息进行存储，如微服务的名称、IP、端口等
- 可以在进行服务调用时通过服务发现查询可用的微服务列表及网络地址进行服务调用
- 可以对所有的微服务进行心跳检测，如发现某实例长时间无法访问，就会从服务注册表移除该实例。
常用的注册中心
springcloud支持的多种注册中心Eureka、Consul、Zookeeper、以及阿里巴巴推出Nacos。这些注册中心在本质上都是用来管理服务的注册和发现以及服务状态的检查的。
1.Eureka
# 0.简介
- https://github.com/Netflix/eureka/wiki
- Eureka是Netflix开发的服务发现框架，本身是一个基于REST的服务。SpringCloud将它集成在其子项目spring-cloud-netflix中， 以实现SpringCloud的服务注册和发现功能。
Eureka包含两个组件：Eureka Server和Eureka Client。
开发Eureka Server
1.创建项目并引入eureka server依赖
2.编写配置application.yml
server:
port: 8761 #默认端口号
spring:
application:
name: eurekaserver #指定服务名 唯一标识 不能出现下划线 默认服务名不区分大小写 推荐服务名大写
eureka:
client:
service-url:
defaultZone: http://localhost:8761/eureka #指定服务注册中心的地址 暴露服务地址
细节：在项目启动成功之后默认在eureka server管理界面中出现UNKNOWN 一个位置应用 在微服务架构中服务名称代表服务唯一标识，至关重要，服务名称必须唯一，使用时必须通过如下配置指定服务名成 spring.application.name=EUREKASERVER #指定服务名 唯一标识 不能出现下划线 默认服务名不区分大小写 推荐服务名大写
3.开启Eureka Server,入口类加入注解
@SpringBootApplication
@EnableEurekaServer
public class Eurekaserver8761Application {
public static void main(String[] args) {
SpringApplication.run(Eurekaserver8761Application.class, args);
}
}
4.运行 报错问题原因:eureka组件包含 eurekaserver 和 eurekaclient。server是一个服务注册中心,用来接受客户端的注册。client的特性会让当前启动的服务把自己作为eureka的客户端进行服务中心的注册,当项目启动时服务注册中心还没有创建好,所以找我不到服务的客户端组件就直接报错了，当启动成功服务注册中心创建好了，日后client也能进行注册，就不再报错啦！ 5.访问Eureka的服务注册页面
http://localhost:8761/
6.关闭Eureka自己注册自己
server:
port: 8761 #默认端口号
spring:
application:
name: eurekaserver #指定服务名 不能出现下划线 默认服务名不区分大小写 推荐服务名大写
eureka:
client:
service-url:
defaultZone: http://localhost:8761/eureka #指定服务注册中心的地址 暴露服务地址
fetch-registry: false #关闭 eureka client的立即注册
register-with-eureka: false #不再将自己同时作为客户端进行注册
再次启动,当前应用就是一个单纯Eureka Server,控制器也不再报错 开发Eureka Client
1.创建项目并引入eureka client依赖
2.编写配置application.properties
server:
port: 8989
spring:
application:
name: EUREKACLIENT
eureka:
client:
service-url:
defaultZone: http://localhost:8761/eureka #eureka注册中心地址
3.开启eureka客户端加入注解
@SpringBootApplication
@EnableEurekaServer //当前应用是一个服务注册中心
public class EurekaServerApplication {
public static void main(String[] args) {
SpringApplication.run(EurekaServerApplication.class,args);
}
}
4.启动之前的8761的服务注册中心,在启动eureka客户端服务 5.查看eureka server的服务注册情况
eureka自我保护机制
1. 服务频繁启动时 EurekaServer出现错误
EMERGENCY! EUREKA MAY BE INCORRECTLY CLAIMING INSTANCES ARE UP WHEN THEY’RE NOT. RENEWALS ARE LESSER THAN THRESHOLD AND HENCE THE INSTANCES ARE NOT BEING EXPIRED JUST TO BE SAFE.
2. 什么是自我保护机制
官网地址: https://github.com/Netflix/eureka/wiki/Server-Self-Preservation-Mode
默认情况下，如果Eureka Server在一定时间内（默认90秒）没有接收到某个微服务实例的心跳，Eureka Server将会移除该实例。但是当网络分区故障发生时，微服务与Eureka Server之间无法正常通信，而微服务本身是正常运行的，此时不应该移除这个微服务，所以引入了自我保护机制。Eureka Server在运行期间会去统计Eureka 实例正常心跳占比在 15 分钟之内是否低于 85%，如果低于 85%，Eureka Server 会将这些实例保护起来，让这些实例不会过期，自我保护状态一旦开启，除非客户端恢复导致退出自我保护状态，否则实例永不删除。这种设计的哲学原理就是"宁可信其有不可信其无!"。自我保护模式正是一种针对网络异常波动的安全保护措施，使用自我保护模式能使Eureka集群更加的健壮、稳定的运行。
3. 为什么会有自我保护机制？
Eureka服务端为了防止Eureka客户端本身是可以正常访问的，但是由于网路通信故障等原因，造成Eureka服务端失去于客户端的连接，从而形成的不可用。
因为网络通信是可能恢复的，但是Eureka客户端只会在启动时才去服务端注册。如果因为网络的原因而剔除了客户端，将造成客户端无法再注册到服务端。
4. Eureka Server自动进入自我保护机制，此时会出现以下几种情况：
Eureka Server不再从注册列表中移除因为长时间没收到心跳而应该过期的服务。
Eureka Server仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上，保证当前节点依然可用。
当网络稳定时，当前Eureka Server新的注册信息会被同步到其它节点中。
心跳正常，退出自我保护状态，客户端恢复。
5. 如何选择关闭还是开启自我保护机制
Eureka服务端默认情况下是会开启自我保护机制的。但我们在不同环境应该选择是否开启保护机制。
一般情况下，我们会选择在 开发环境下关闭自我保护机制，而在生产环境下启动自我保护机制。
开发环境下，我们我们启动的服务数量较少而且会经常修改重启。如果开启自我保护机制，很容易触发Eureka客户端心跳占比低于85%的情况。使得Eureka不会剔除我们的服务，从而在我们访问的时候，会访问到可能已经失效的服务，导致请求失败，影响我们的开发。
在生产环境下，我们启动的服务多且不会反复启动修改。环境也相对稳定，影响服务正常运行的人为情况较少。适合开启自我保护机制，让Eureka进行管理。
6. 如何关闭自我保护机制
服务端：
eureka:
server:
enable-self-preservation: false
eviction-interval-timer-in-ms: 3000 #超时3s自动清除。它是清除无效节点的时间间隔
客户端：
eureka:
instance:
lease-expiration-duration-in-seconds: 10
#在接收到上一个心跳之后等待下一个心跳的秒数（默认 90 秒），也就是用来接收心跳的超时时间，若不能在指定时间内收到心跳，则移除此实例，并禁止此实例的流量。
lease-renewal-interval-in-seconds: 5
#指定客户端多久向eureka server发送一次心跳 默认是30s
7. eureka 停止更新
在1.x版本项目还是活跃的,但是在2.x版本中停止维护,出现问题后果自负!!!
eureka server集群搭建
创建3个springboot项目
引入eureka server项目
配置文件application.properties
在每个项目入口类加入@EnableEurekaServer 注解
测试：这里采用修改虚拟机参数搭建eureka server集群
选中一个eureka server复制三个
修改复制后的eureka server名称和端口名
指定服务注册中心的地址，8761要向8762和8763注册，8762要向8761和8763注册，8763要向8761和8762注册
server:
port: 8761 #默认端口号
spring:
application:
name: eurekaserver #指定服务名 不能出现下划线 默认服务名不区分大小写 推荐服务名大写
eureka:
client:
service-url:
defaultZone: http://localhost:8762/eureka,http://localhost:8763/eureka #指定服务注册中心的地址 暴露服务地址
fetch-registry: false #关闭 eureka client的立即注册
register-with-eureka: false #不再将自己同时作为客户端进行注册
server:
enable-self-preservation: false
eviction-interval-timer-in-ms: 3000 #超时3s自动清除。它是清除无效节点的时间间隔
启动这三个eureka server 注意：因为我这里用的是yml，日志里报了一个警告，没有显示出8761的副本节点。
解决方法：加个空的config.properties就可以了
启动第二个eureka server（8762，因为虚拟机参数优先于配置文件，所以这里不用在配置文件里修改端口号），修改配置文件，让他向8761，8763注册，第三个同上。
启动一个客户端测试一下
测试结果：三个server都被注册了
注意：如果客户端启动的时候恰好需要注册的这台eureka server宕了，但eureka还有其他的服务注册中心，所以我们在保证server的高可用的时候也要保证client的高可用，所在我们要在配置文件里写上所有的注册中心地址。
server:
port: 8989
spring:
application:
name: EUREKACLIENT
eureka:
client:
service-url:
defaultZone: http://localhost:8761/eureka/,http://localhost:8762/eureka/,http://localhost:8763/eureka/ #eureka注册中心地址
instance:
lease-expiration-duration-in-seconds: 10
lease-renewal-interval-in-seconds: 5
注意：同一个集群，集群的服务名必须一样
小结：不推荐使用eureka服务注册中心。原因有：
最新版本停止更新
每次必须手动通过代码形式开发服务注册中心
2.Consul
https://www.consul.io
consul是一个可以提供服务发现，健康检查，多数据中心，Key/Value存储等功能的分布式服务框架，用于实现分布式系统的服务发现与配置。与其他分布式服务注册与发现的方案，使用起来也较为简单。Consul用Golang实现，因此具有天然可移植性(支持Linux、Windows和Mac OS X)；安装包仅包含一个可执行文件，方便部署。
安装consul
下载consul
https://www.consul.io/downloads
相关阅读
您阅读本篇文章共花了：
发表评论