Spring Cloud
Spring cloud是一个基于Spring Boot实现的服务治理工具包，在微服务架构中用于管理和协调服务的。
为什么需要SpringCloud?
Monolith（单体应用）架构（最终部署的时候只有一份war包,其他的以jar包的方式依赖来）：在项目很小的情况下这种单体应用比较简单。
Monolith（单体应用）架构存在的缺点（项目较大时）：
- 编译难，部署难，测试难。
- 技术选择难（技术不兼容）
- 扩展难（单体应用中多个模块的负载不均衡,我们扩容高负载的时候,也把低负载的模块也扩容,极大浪费了资源）
使用微服务架构就可以解决单体项目缺点
MicroService(微服务)架构：
- 微服务就是把一个单体项目,拆分为多个微服务,每个微服务可以独立技术选型,独立开发,独立部署,独立运维.并且多个服务相互协调,相互配合,最终完成用户的价值。
1.优势：
- 复杂度可控：每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界。
- 独立部署：当某个微服务发生变更时无需编译、部署整个应用。
- 技术选型灵活：由于每个微服务相对简单，故需要对技术栈进行升级时所面临的风险就较低，甚至完全重构一个微服务也是可行的。
- 容错：在微服务架构下，故障会被隔离在单个服务中。
- 扩展：每个服务可以根据实际需求独立进行扩展。
2.使用场景
- 单体应用架构：中小型项目(功能相对较少) crm 物流 库存管理等
- 微服务架构：大型项目（功能比较多） 商城 erp等
- 微服务spring的解决方案
- ①单个服务:springboot
- ②服务间协调:springcloud
Spring Cloud & dubbo对比
-
Dubbo：中国各互联网公司在用。
-
Spring cloud：dubbo曾经确实很牛逼，但是Spring Cloud是站在近些年技术发展之上进行开发，因此更具技术代表性。
Spring cloud是微服务架构中服务治理工具集，有很多产品组成。核心为五大神兽。相较于dubbo更加靠谱
SpringCloud的组成
- 服务发现——Netflix Eureka
- 客服端负载均衡——Netflix Ribbon/Feign
- 服务网关——Netflix Zuul
- 断路器——Netflix Hystrix
- 分布式配置——Spring Cloud Config
等19个框架，开源的随时在增加。
Eureka注册中心
1.Eureka是netflix的一个子模块，也是核心模块之一 。
2.使用eureka的客户端连接到eureka server并维持心跳连接，通过eureka server来监控系统中各个微服务是否正常运行。
三大角色
Eureka server提供服务注册和发现：Eureka Server提供服务注册服务。
Service Provider服务提供方 ：将自身服务注册到Eureka，从而使服务消费方能够找到。
Service Consumer服务消费方：从Eureka获取注册服务列表，从而能够消费服务。
单机注册中心搭建
1.创建项目
创建一个普通maven项目
2.导入jar,pom.xml
org.springframework.boot
spring-boot-starter-web
org.springframework.boot
spring-boot-starter-test
org.springframework.cloud
spring-cloud-starter-netflix-eureka-server
3.yml配置
server:
port: 7001
eureka:
instance:
hostname: localhost
client:
registerWithEureka: false #是否要注册到eureka
fetchRegistry: false #表示是否从Eureka Server获取注册信息
serviceUrl:
defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/ #单机配置
4.主类
@SpringBootApplication
@EnableEurekaServer //标识是eureka服务端
public class EnrekaServerApplication_7001 {
public static void main(String[] args) {
SpringApplication.run(EnrekaServerApplication_7001.class);
}
}
5.测试（http://localhost:7001/）
负载均衡
为什么需要?
为了提供并发量，有时同一个服务提供者可以部署多个。这个客户端在调用时要根据一定的负责均衡策略完成负载调用。
Ribbon负载均衡:
提供客户端负载均衡算法
集成原理
| 内置负载均衡规则类 | 规则描述 |
|---|---|
| RoundRobinRule（默认） | 简单轮询服务列表来选择服务器。它是Ribbon默认的负载均衡规则。 |
| AvailabilityFilteringRule | 对以下两种服务器进行忽略： （1）在默认情况下，这台服务器如果3次连接失败，这台服务器就会被设置为“短路”状态。短路状态将持续30秒，如果再次连接失败，短路的持续时间就会几何级地增加。 注意：可以通过修改配置loadbalancer. |
| WeightedResponseTimeRule | 为每一个服务器赋予一个权重值。服务器响应时间越长，这个服务器的权重就越小。这个规则会随机选择服务器，这个权重值会影响服务器的选择。 |
| ZoneAvoidanceRule | 以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这个Zone可以理解为一个机房、一个机架等。 |
| BestAvailableRule | 忽略哪些短路的服务器，并选择并发数较低的服务器。 |
| RandomRule | 随机选择一个可用的服务器。 |
| Retry | 重试机制的选择逻辑 |
Feign负载均衡(常用):
Feign是一个声明式的Web Service客户端，它的目的就是让Web Service调用更加简单
Feign具有如下特性：
可插拔的注解支持，包括Feign注解和JAX-RS注解;
支持可插拔的HTTP编码器和解马器;
支持Hystrix和它的Fallback;
支持Ribbon的负载均衡;
支持HTTP请求和响应的压缩。
Feign是以接口方式进行调用,而不是通过RestTemplate来调用,feign底层还是ribbo,它进行了封装,让我们调用起来更加容易。
当对同一个服务部署多个时，就要涉及负载均衡调用了，这是可以选择Ribbon和Feign。