SpringCloud学习

微服务设计原则

akf拆分原则

立方体 ：
向上：感召服务功能拆分，
向右：建立集群，进行负载均衡才做
向后：按照数据拆分

场景说明：比如打车应用，一个集群撑不住时，分了多个集群，后来用户激增还是不够用，经过分析发现
是乘客和车主访问量很大，就将打车应用拆成了三个，分别为乘客服务、车主服务、支付服务。三个服务的业
务特点各不相同，独立维护，各自都可以再次按需扩展。

前后端分离原则

前后端技术分离，可以由各自的专家来对各自的领域进行优化，这样前端的用户体验优化效果更好。
前后端分离模式下，前后端交互界面更清晰，就剩下了接口模型，后端的接口简洁明了，更容易维护。
前端多渠道集成场景更容易实现，后端服务无需变更，采用统一的数据和模型，可以支持多个前端：例如：微
信 h5 前端、PC 前端、安卓前端、IOS 前端。

无状态服务

对于无状态服务，首先说一下什么是状态：如果一个数据需要被多个服务共享，才能完成一笔交易，那么这个数据被称为状态。进而依赖这个“状态”数据的服务被称为有状态服务，反之称为无状态服务。
那么这个无状态服务原则并不是说在微服务架构里就不允许存在状态，表达的真实意思是要把有状态的业务服务改变为无状态的计算类服务，那么状态数据也就相应的迁移到对应的“有状态数据服务”中。场景说明：例如我们以前在本地内存中建立的数据缓存、Session 缓存，到现在的微服务架构中就应该把这些数据迁移到分布式缓存中存储，让业务服务变成一个无状态的计算节点。迁移后，就可以做到按需动态伸缩，微服务应用在运行时动态增删节点，就不再需要考虑缓存数据如何同步的问题。
也就是对同一个 url 请求没有上下文关系。举个生活中的例子：
比如空调遥控器，你按上下调整温度时，空调温度设定值会变化，遥控器信号到空调是单向传输。现在空调显示温度 20 度，遥控器 20 度。如果遥控器与空调之间是有状态的，假设你离开空调接收范围调整了遥控器温度，变成 19，那回到范围内你按一次升高一度，基于原先温度状态，遥控器给空调发送一个“提高1度”的指令，就会出现遥控器提高到 20，而空调变成21。如果要空间与空调之前是无状态的，假设你离开空调接收范围调整了遥控器温度，变成 19，那回到范围内你按一次升高一度，遥控器给空调发送一个“设定温度值20”，这样两者最终还是相同的值。

Restful通信风格

是一种规范 ，我们的增删改查的url可以完全相同，不同的请求方式代表着不同的请求，get获取，post新增，put更新，delete删除

状态码

使用适合的状态码很重要，而不应该全部都返回状态码 200

状态码，可根据以下标准按照项目扩展自身状态码：

200~299段 表示操作成功：

200 操作成功，正常返回

201 操作成功，已经正在处理该请求

300~399段 表示参数方面的异常

300 参数类型错误

301 参数格式错误

302 参数超出正常取值范围

303 token过期

304 token无效

400~499段 表示请求地址方面的异常：

400 找不到地址

500~599段 表示内部代码异常：

500 服务器代码异常

dubbo和springcloud的区别

1：dubbo是二进制传输，springcloud通过http协议传输 ，使用http协议一般会用JSON，消耗会大
2：像注册中心 服务调用，网关，路由等使用的是不同的技术，比如注册中心dubbo用的是 zookeeper ， springcloud用的是eureka

什么是微服务

将一个单体架构按照业务划分为一个独立运行的程序服务，通过HTTP协议进行通信 (*http协议：超文本传输协议(Hypertext transfer protocol) 。是一种详细规定了浏览器和万维网(WWW =World Wide Web)服务器之间互相通信的规则)*也可以使用消息队列来通信(如：RabbitMq)，可以采用不同的编程语言，不同的数据存储技术，自动化部署(如jenkins) 减少人为控制，降低出错率。次采用集中化管理，如：Eureka，Zookeeper 等注册中心进行管理

优点

测试容易，可伸缩性强，可靠性强，跨语言，协同开发，方便系统迭代

缺点

运维成本高 部署项目多 ， 接口兼容版本问题 ， 分布式系统的复杂性， 分布式事务

sso单点登陆

指在多系统应用群中登录一个系统，便可在其他所有系统中得到授权而无需再次登录，包括单点登录与单点注销两部分

登陆

1：用户第一次访问系统1是，系统1发现是未登陆状态，跳转到sso认证中心，并将自己的地址作为参数带过去
2：sso认证中心发现用户未登录，引导用户到登陆页面，
3：用户输入账号密码进行登陆，sso账号密码进行校验，校验没问题，回创建用户与sso之间的会话(全局会话)，创建授权令牌，
4：sso认中心 将令牌交给系统1，系统1拿着令牌去sso认证中心校验令牌是否有效
5：令牌有效，注册系统1，系统1拿着令牌与用户创建会话(局部会话)，返回受保护资源
6：用户访问系统2，系统2发现用户未登陆，跳转sso人中中心，并将自己的地址作为参数传带过去
7：sso认证中心发现用户是已登陆，将令牌交给系统2，系统2拿着令牌去sso人中中心校验是否有效
8：令牌有效，注册系统2拿着令牌与用户创建会话(局部会话)，返回受保护资源
9：当用户 反复访问系统1 和系统2时，将不再通过sso认证中心

备注：用户登录成功之后，会与sso认证中心及各个子系统建立会话，用户与sso认证中心建立的会话称为全局会话，用户与各个子系统建立的会话称为局部会话，局部会话建立之后，用户访问子系统受保护资源将不再通过sso认证中心，全局会话与局部会话有如下约束关系

局部会话存在，全局会话一定存在
全局会话存在，局部会话不一定存在
全局会话销毁，局部会话必须销毁

注销

在一个子系统中注销，所有子系统的会话都将被销毁
　sso认证中心一直监听全局会话的状态，一旦全局会话销毁，监听器将通知所有注册系统执行注销操作
　1：用户想系统1发起注销请求，系统1根据与用户建立的会话中拿到令牌，想sso认证中心发起注销请求
　2：sso认证中心校验令牌有效，销毁会话(全局会话)，同时取出所有此令牌注册的系统地址，向所有注册的系统发起注销请求
　3：各注册中心接收sso认证中心的注销请求，销毁局部会话，sso认证中心引导用户至登陆界面

SpringCloud

什么是 SpringCloud

1:Spring Cloud 是一个服务治理平台，提供了一些服务框架。包含了：服务注册与发现、配置中心、消息中心 、
负载均衡、数据监控等等。
2:Spring Cloud 是一个基于 Spring Boot 实现的云应用开发工具，它为开发中的配置管理、服务发现、断路器、
智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等操作提供了一种简单的开发方式。
3:也可以说Spring Cloud 是管家，采用了微服务这种架构之后，项目的数量会非常多，Spring Cloud 做为管家需要管理好这些微服务。

注册中心Eureak

链接: https://blog.csdn.net/awxnn/article/details/130443150

负载均衡 Ribbon

Ribbon 是一个基于 HTTP 和 TCP 的 客服端 负载均衡工具，它是基于 Netflix Ribbon 实现的。
它不像 Spring Cloud 服务注册中心、配置中心、API 网关那样独立部署，但是它几乎存在于每个 Spring Cloud
微服务中。包括 Feign 提供的声明式服务调用也是基于该 Ribbon 实现的。

Ribbon 默认提供很多种负载均衡算法，例如轮询、随机等等。甚至包含自定义的负载均衡算法。

负载均衡不同方案的区别

集中式负载均衡（服务器负载均衡）

即在 consumer（消费者） 和 provider（提供者） 之间使用独立的负载均衡设施(可以是硬
件，如 F5，也可以是软件，如 nginx)，由该设施负责把访问请求通过某种策略转发至 provider（提供者）；

进程内负载均衡（客户端负载均衡）

将负载均衡逻辑集成到 consumer（消费者），consumer （消费者）从服务注册中心获知有
哪些地址可用，然后自己再从这些地址中选择出一个合适的 provider（提供者）。Ribbon 属于后者，它只是一个类库，集成于 consumer （消费者）进程，consumer（消费者） 通过它来获取 provider（消费者） 的地址。

Ribbon 负载均衡策略

1：轮询策略（默认）

策略对应类名： RoundRobinRule
实现原理：轮询策略表示每次都顺序取下一个 provider，比如一共有 5 个 provider，第 1 次取第 1 个，第 2 次
取第 2 个，第 3 次取第 3 个，以此类推。

2：权重轮询策略

策略对应类名： WeightedResponseTimeRule
实现原理：
根据每个 provider 的响应时间分配一个权重，响应时间越长，权重越小，被选中的可能性越低。
原理：一开始为轮询策略，并开启一个计时器，每 30 秒收集一次每个 provider 的平均响应时间，当信息足够
时，给每个 provider 附上一个权重，并按权重随机选择 provider，高权越重的 provider 会被高概率选中。

####3： 随机策略
策略对应类名： RandomRule
实现原理：从 provider 列表中随机选择一个。

4：最少并发数策略

策略对应类名： BestAvailableRule
实现原理：选择正在请求中的并发数最小的 provider，除非这个 provider 在熔断中。

5：重试策略

策略对应类名： RetryRule
实现原理：其实就是轮询策略的增强版，轮询策略服务不可用时不做处理，重试策略服务不可用时会重新尝试集
群中的其他节点。

6：可用性敏感策略

策略对应类名： AvailabilityFilteringRule
实现原理：过滤性能差的 provider
第一种：过滤掉在 Eureka 中处于一直连接失败的 provider。
第二种：过滤掉高并发（繁忙）的 provider。

7：区域敏感性策略

策略对应类名： ZoneAvoidanceRule
实现原理：
以一个区域为单位考察可用性，对于不可用的区域整个丢弃，从剩下区域中选可用的 provider。
如果这个 ip 区域内有一个或多个实例不可达或响应变慢，都会降低该 ip 区域内其他 ip 被选中的权 重。

Ribbon 入门案例

Ribbon 负载均衡策略设置

全局

在启动类或配置类中注入负载均衡策略对象。所有服务请求均使用该策略。

@Bean
public RandomRule randomRule() {
    return new RandomRule();
}

局部

修改配置文件指定服务的负载均衡策略。格式： 服务应用名.ribbon.NFLoadBalancerRuleClassName

# 负载均衡策略
# service-provider 为调用的服务的名称
service-provider:
 ribbon:
   NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule

Ribbon 点对点直连

点对点直连是指绕过注册中心，直接连接服务提供者获取服务，一般在测试阶段使用比较多。

** 添加依赖 **
在 pom 文件中引入 Ribbon，需要注意的是如果 pom 中有 Eureka 的依赖，则需要去除 Eureka 的依赖。

<!-- netflix ribbon 依赖 -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-ribbon</artifactId>
</dependency>

** 配置文件**
配置文件中关闭 Eureka，添加直连的服务地址。如果不设置负载均衡策略默认使用轮询策略。

# 负载均衡策略
# service-provider 为调用的服务的名称
service-provider:
 ribbon:
   NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule
    # 指定具体的 Provider 服务列表，多个用逗号隔开
   listOfServers: http://localhost:7070,http://localhost:7071
# 关闭 Eureka 实现 Ribbon 点对点直连
ribbon:
 eureka:
   enabled: false # false：关闭，true：开启

** 访问 **
关闭 Eureka 注册中心，服务提供者由于无法连接至注册中心所以会报连接异常。但是服务是可以正常可消费
的，所以目前使用的是点对点的方式来进行调用的。

Feign 和 OpenFeign

明式的客户端调用组件，可以方便地实现服务之间的调用，并支持多种协议。

Hystrix

服务容错组件，提供了线程隔离、断路器、服务降级等机制，保证服务的可靠性和稳定性。

Zuul

PI 网关组件，提供了路由、负载均衡、过滤等功能，可以统一处理请求并提供安全控制和流量管理。

Config

分布式配置中心，提供了集中管理和动态更新配置的功能，可以方便地管理多个服务的配置信息

Stream

消息驱动组件，提供了消息消费者和生产者的封装，并支持多种消息中间件。