SpringCloud研究学习总结一（理论知识）

用最简单的语言阐述最深刻的知识，纯属个人总结，有所借鉴。

微服务

不同业务拆分成微服务部署在不同机器，数据库独立，互相调用，常用微服务框架Dubbo、Cloud

优点：

·服务独立，开发效率高

·各模块可以使用不同语言开发

·前后端分离

·配置独立，数据库独立

缺点：

·保证数据一致性，部署成本高

·运维成本高

 

微服务通信

·远程过程调用：Feign

优点：系统简单

缺点：不支持通知、请求/异步响应、发布/订阅等

·消息中间件：RabbitMQ、ActiveMQ

优点：支持通知、请求/异步响应、发布/订阅等

缺点：系统复杂

 

微服务技术栈

·服务开发：SpringBoot、SpringMVC、Dubbo

·服务注册与发现：eureka、zookeeper

·服务调用：REST、RPC

·服务熔断：Hystrix

·服务负载均衡：Ribbon、Nginx

·接口调用：Fegin

·消息队列：RabbitMQ、ActiveMQ、Kafka

·服务配置中心：SpringCloudConfig

·服务路由(API网关)：Zuul

·事件消息总线：SpringCloud Bus

 

SpringCloud

轻量级框架的集合，基于SpringBoot的开发便利性简化分布式系统开发，提高开发效率

·优点：包含微服务架构方方面面；约定优于配置，基于注解；整合轻量级组件；各组件解耦，比较灵活。

·缺点：大型微服务项目的结构较复杂；部署成本高；维护成本高。

 

SpringBoot和SpringCloud的理解

SpringBoot解决传统框架配置繁杂，专注于微服务个体的快速开发工具。

SpringCloud解决各微服务间的协调与配置，专注于微服务治理。

 

Dubbo和SpringCloud对比

Dubbo专注于服务治理，使用RPC调用，效率较高。

Spring Cloud覆盖整个微服务架构领域，使用REST调用，效率较低。

 

REST和RPC对比

Spring Cloud--REST API系统交互方便，跨语言，松耦合

Dubbo--RPC服务依赖性强，易冲突，不能跨语言，但是RPC调用效率较高。

 

zookeeper和Eureka对比

C(Consistency):一致性、P(Partition-tolerance):分区容错性、A(Availability):高可用

著名CAP理论指出：一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性P在是分布式系统中必须要保证的，因此我们只能在A和C之间进行权衡。

1. zk注重一致性(CP)；Eureka注重可用性(AP)
2. zk有leader和follower；Eureka各个节点平等
3. zk选举期间注册服务瘫痪；Eureka有自我保护机制，不从注册列表移除因长时间没收到心跳而过期的服务，依然能接受新服务的注册和查询，但不会同步到其他节点，不会服务瘫痪。
4. zk采用半数存活原则；Eureka自我保护机制

 

Eureka自我保护机制

网络故障等因素导致erueka Server节点短期内丢失过多实例连接，就会启动自我保护，期间不再删除注册数据，依然可以服务注册和查询，故障恢复后关闭自我保护。

Eureka续约：周期性向Eureka Server发送心跳续约注册信息，避免被剔除。续约方式和注册方式一致，先更新自己，再同步到其他节点。

Eureka剔除：Eureka Server长时间没有收到某节点心跳，将剔除该节点，当然自我保护机制除外。

Eureka同步/ Eureka Server高可用：Eureka将自身作为服务向其他服务注册中心注册自己，形成互相注册的注册中心，实现服务清单互相同步，达到高可用。

 

SpringCloudConfig

分布式配置中心组件，方便服务配置文件统一管理，实时更新。同时支持配置服务放在本地内存和远程git仓库。分为configserver、config client两个组件。

 

SpringCloud核心组件

1. Eureka：注册中心
2. Fegin：根据注解和选择的机器，拼接请求 url 地址，发起请求
3. Ribbon：实现负载均衡
4. Hystrix：隔离不同服务调用，避免雪崩
5. Zuul：网关管理，由Zuul网关转发请求给对应服务

 

服务注册与发现

服务发布：指定对应服务名(包括ip地址和端口)将服务注册到注册中心

注册中心：eureka、zookeeper

服务发现：通过传递服务名到注册中心获取相应可用实例

注册中心加@EnableEurekaServer,服务用@EnableDiscoveryClient

调用方式：ribbon、feign

 

负载均衡

负载均衡旨在增大吞吐量，减小响应时间并避免任何单一资源的过载。使用多个组件进 行负载均衡能极大提高系统高可用性。

常见策略：客户请求先经过nginx等组件，再到服务网关zuul集群，再到具体的服务。服务统一注册在高可用的服务注册中心集群，所有配置文件由SpringCloudConfig管理，config配置文件放在git仓库。

 

服务雪崩，服务熔断，服务降级

服务雪崩：高并发时，某一微服务由于网络或其他原因导致服务阻塞，复杂的分布式系统下引发连锁反应导致整个微服务系统崩溃。

服务熔断：应对雪崩效应的一种微服务链路保护机制。某一微服务响应时间过长或

者不可用，导致占用过多系统资源，hystrix断路器会将此微服务熔断。

服务降级：服务熔断后，其他请求继续访问就返回fallback的默认值。虽然出现局部错

误，但是避免影响整合微服务系统。

 

Hystrix

防雪崩组件，具备服务熔断，服务降级，依赖隔离，监控的功能。

 

Hystrix如何实现容错

结合服务雪崩、服务熔断、服务降级

 

Hystrix断路器

全开：微服务在一段时间内达到一定的次数无法调用，并且多次监测没有恢复的迹象，断路器完全打开，下次请求不会请求到该服务。

半开：短时间内有恢复迹象，将部分请求发给微服务，直到正常调用时断路器关闭

关闭：微服务能正常调用

 

Ribbon

基于HTTP和TCP客户端的负载均衡器，在客户端配置ribbonServerList（服务端列表），然后轮询请求以实现负载均衡。

使用：

1. 添加依赖 spring-starter-ribbon
2. @RibbonClient(value="服务名称") 调用远程服务

Ribbon与Nginx对比

Ribbon可以剔除不健康节点，是客户端负载均衡

Nginx剔除比较麻烦，是服务端负载均衡，性能较好

 

Feign

整合Ribbon负载均衡能力和Hystrix服务熔断能力的一个使用方便的HTTP客户端，让调用者像是调用本地方法一样调用远程服务。

使用：

1. 添加依赖 spring-starter-feign
2. 启动类添加@EnableFeignClient
3. 接口上@FeignClient(name="指定服务名")调用远程服务

 

Ribbon与Feign对比

1. 启动类注解：Ribbon是@RibbonClient，Feign是@EnableFeignClients
2. 服务指定位置：Ribbon在@RibbonClient注解上声明，Feign在接口@FeignClient声明
3. 调用方式不同：

Ribbon构建http请求使用RestTemplate发送给其他服务，效率低

Feign采用接口方式，将需要调用的服务的方法定义成抽象方法

 

网关原理和实现

分类：Zuul和Spring Cloud Gateway，推荐Gateway。

1. 统一处理客户端请求，降低复杂度
2. 根据不同的接口需求对数据处理后发送
3. 不同的客户端对应不同的网关支持
4. 微服务改造过程中可以作为新老系统的中转组件

 

SpringCloud Bus

事件消息总线：将分布式节点用轻量消息代理连接，提供了跨多个实例刷新配置的功能，用于广播配置文件的更改、服务直接通信以及监控。

 

本文借鉴以下各位大牛原创文章：

「韩金群」的原创：https://blog.csdn.net/hjq_ku/article/details/89504229

「大胡子叔叔_」的原创：https://blog.csdn.net/panhaigang123/article/details/79587612

「kxkxyzyz」的原创：https://blog.csdn.net/kxkxyzyz/article/details/103394767

「天瑕」的原创：https://blog.csdn.net/weixin_30342639/article/details/99436321

「流放Oo」的原创：https://blog.csdn.net/qq_42629110/article/details/84963815