# spring-cloud-demo

**Repository Path**: yilvi/spring-cloud-demo

## Basic Information

- **Project Name**: spring-cloud-demo
- **Description**: 一些学习笔记和各模块练习、适合初学者
- **Primary Language**: Java
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2021-02-12
- **Last Updated**: 2024-04-08

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

_约定>配置>编码_<br>

## 项目记录

### 1.idea初始化 maven-jar-plugin报红？

~~~log
setting->maven->replace binding
~~~
### 2.git项目创建流程

~~~log
New project->vsn->git->commit->copy url insert into form->
New module->called by projectName plus port
~~~
### 3.微服务搭建
①.建module
②.改pom
③.写yml
④.主启动
⑤.业务类

### 4.自动热部署

## 服务注册中心

| Eureka    | 保证ap(availability、partition)               | 完全去中心化、每个节点都是相等， 采用你中有我、我中有你相互注册设计思想，只要最后有一台Eureka节点存在整个微服务就可以实现通讯。 |
| --------- | --------------------------------------------- | ------------------------------------------------------------ |
| Zookeeper | 保证cp(consistency、partition)                | 中心化：必须围绕一个领导角色作为核心，选举领导和跟随者角色。 去中心化：每个角色都是均等。原理采用(ZAP原子广播协议) ， 当我们ZK领导者因为某种情况下部分节点出现了故障，会自动重新实现选举新的领导角色，整个选举的过程中为了保证数据一致性的问题， 客户端暂时无法使用我们的Zookeeper， 那么这意味着整个微服务无法实现通讯（本地有缓存除外）。<br/>注意：可运行的节点必须满足过半机制，整个zk采用使用，自己选举 leader 和 处理follower |
| nacos     | AP和CP混合形式实现注册中心， 默认情况下采用AP | 我们在使用注册中心，可用性优先级最高，可以读取数据短暂不一致性，但是至少要能够保证注册中心可用性。<br/>从1.0版本选择AP和CP混合形式实现注册中心， 默认情况下采用AP， CP则采用Raft协议实现保持数据的一致性。如果选择为AP模式，注册服务的实例仅支持临时模式，在网络分区的的情况允许注册服务实例，选择CP模式可以支持注册服务的实例为持久模式，在网络分区的产生了抖动情况下不允许注册服务实例。 |

### 1.什么是服务治理？

* spring cloud封装了netflix公司开发的eureka模块来实现服务治理

*   在传统的rpc远程调用框架中，管理每个服务之间的依赖关系比较复杂，管理比较复杂，所以需要服务治理，管理服务与服务之间的依赖关系，进行负载均衡、容错、服务发现和注册等功能，实现服务发现于组测。

### 2.什么是服务注册与发现？

> eureka采用了cs的设计架构，eureka server作为服务注册功能的服务器，它是服务注册中心。而系统中其他服务器，使用eureka的客户端连接到eureka server并维持心跳连接，维护人员即可通过eureka server来监控系统中各个微服务是否正常运行。

![img_1.png](img/img_1.png)

在服务注册与发现中，有一个注册中心。当服务器启动的时候，会把当前自己服务器的信息，如：服务地址、通讯地址以别名方式注册到注册中心上，另一方(消费者|服务提供者)，以该别名的方式去注册中心上获取到实际的服务通讯地址，然后实现本地rpc调用，框架核心思想：在于注册中心，使用注册中心管理每个服务与服务之间的依赖关系。在任何rpc远程框架中，都会有一个注册中心(存放服务地址相关信息)

**集群**：为防止单点故障，采用集群部署(多注册，多服务)

### 3.Eureka组件

* Eureka Server服务注册服务

各个服务节点通过配置启动后，会在EurekaServer中进行注册，这样Eurekaserver中的服务注册表中将会储存所有可用服务节点的信息，服务节点的信息可以在界面中直观看到。

* Eureka Client轮询访问

用于简化与eureka的交互，客户端同时也具备一个内置的、使用轮询(round-robin)负载算法的负载均衡器。在应用启动后，将会向Eureka server发送

### 4.Dubbo Architecture
![img.png](img/img.png)
> Dubbo(读音[ˈdʌbəʊ])是阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和Spring框架无缝集成。
>
> Dubbo是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。

**registry**：zookeeper

spring-boot围绕应用组件、spring-cloud围绕服务
### 5.zookeeper
创建的是临时节点，强一致

## 服务网关

> springcloud gateway 是springcloud的全新项目，基于spring 5.0+spring boot 2.0 和project reactor等技术开发的网关，它旨在为微服务架构提供一种简单有效的api路由管理方式
>
> springcloud gateway 作为springcloud生态系统的网关，目标是替代zuul，在spring cloud 2.0以上版本中，没有对新版本zuul2.0以上最新高性能版本进行集成，任然使用zuul1.x非reactor模式的版本。而为了提高网关的性能，spring cloud gateway是基于webflux框架实现的，而webflux框架底层则使用了高性能的reactor模式通信框架**netty**(响应式编程)
>
> 基本功能：反向代理、鉴权、流量控制、熔断、日志监控

架构概览

![image-20210310094844164](img/image-20210310094844164.png)

springcloud gateway 特性：

​	①基于spring framework 5，project reactor和spring boot 2.0进行构建

​	②动态路由，能匹配任何请求属性

​	③支持predicate断言和filter过滤器

​	④集成hystrix的断路器功能

​	⑤集成spring cloud 服务发现功能

​	⑥请求限流

​	⑦路径重写

### 1.springcloud gateway和zuul的区别？

（1）、zuul1.x，是一个基于阻塞i/o的api gateway

（2）、zuul1.x基于servlet2.5使用阻塞架构，不支持长连接（如websocket），同nginx较像，其每次i/o操作都是从工作线程中选择一个执行，请求线程被阻塞到工作线程完成，但差别在于nginx用c++实现，zuul用Java实现，但应为jvm本身会有第一次加载比减慢的情况，使得zuul的性能相对较差。

（3）、zuul2.x理念更先进，想基于netty非阻塞和支持长连接，但springcloud目前还没有整合。zuul2.x的性能较zuul2.x的性能较zuul1.x有较大提升。在性能方面，根据官方提供的基准测试，spring cloud gateway的rps（每秒请求数）是zuul的1.6倍。

（4）、spring cloud gateway基于spring framework 5，project reactor和spring boot 2.0，使用非注释api

（5）、spring cloud gateway支持websocket，与spring集成

### 2.路由过程

web请求通过一些匹配条件(predicate)，定位到真正的服务节点，并在这个转发过程的前后进行一些filter精细化控制。

![image-20210310101950687](img/image-20210310101950687.png)

客户端向spring cloud gateway发出请求，然后再gateway handler mapping中找到与请求相匹配的路由，将gateway web handler。

handler再通过指定的过滤器来将请求发送到我们实际的服务执行业务逻辑，然后返回。

过滤器可以设置发送代理请求之前或之后执行的业务逻辑

filter再“pre”类型的过滤器可以做参数校验、权限校验、流量监控、日志输出、协议转换等。

在“post”类型的过滤器中可以做响应内容、响应头的修改，日志输出，流量监控等有非常重要的作用

**核心逻辑**：路由转执行过滤器链

## 服务调用

| Ribbon       | 维护 |
| ------------ | ---- |
| LoadBalancer | 替代 |

### 1.LB负载均衡是什么？

> 将用户的请求平摊到多个服务上，从而达到系统的HA
>
> 常见的负载均衡有nginx、LVS、硬件F5

### 2.Ribbon本地负载均衡客户端vsNginx服务端负载均衡

Nginx是服务器负载均衡，客户端所有的请求都会交给nginx，然后由nginx实现转发请求，即：负载均衡是由服务端实现的

Ribbon本地负载均衡，在调用微服务接口的时候，会在注册中心上获取注册信息服务列表之后缓存到JVM本地，从而在本地实现RPC远程服务调用

**个人觉得就是这套算法到底在注册中心运行还是各个服务机运行**