springCloud-Alibaba整理思考

springCloudAlibaba

• 微服务个人理解

微服务架构是一种架构模式或者说是一种架构风格，它提倡将单一应用程序划分为一组小的服务，每个服务运行在其独立的自己的进程中，服务之间相互协调、互相配合，为用户提供最终价值。服务之间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API），每个服务都围绕着具体的业务进行构建，并且能够被独立的构建在生产环境、类生产环境等。另外，应避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务，可以使用不同的语言来编写服务，也可以使用不同的数据存储。

• 什么是Spring Cloud&&Alibaba？

Spring Cloud是Spring开源组织下的一个子项目，提供了一系列用于实现分布式微服务系统的工具集，帮助开发者快速构建微服务应用。

Spring Cloud Alibaba是Spring Cloud的子项目；包含微服务开发必备组件；基于和符合Spring Cloud标准的阿里的微服务解决方案。

• 服务注册和发现是什么意思？Spring Cloud如何实现？

当我们开始一个项目时，我们通常在属性文件中进行所有的配置。随着越来越多的服务开发和部署，添加和修改这些属性变得更加复杂。有些服务可能会下降，而某些位置可能会发生变化。手动更改属性可能会产生问题。 Nacos服务注册和发现可以在这种情况下提供帮助。由于所有服务都在Eureka服务器上注册并通过调用Nacos服务器完成查找，因此无需处理服务地点的任何更改和处理。

• 什么是Nacos?

英文全称Dynamic Naming and Configuration Service，Na为naming/nameServer即注册中心,co为configuration即配置中心，service是指该注册/配置中心都是以服务为核心。

• Nacos注册中心原理
  

服务提供者、服务消费者、服务发现组件这三者之间的关系大致如下

1、微服务在启动时，将自己的网络地址等信息注册到服务发现组件(nacos server)中，服务发现组件会存储这些信息。

2、各个微服务与服务发现组件使用一定机制通信（例如在一定的时间内发送心跳包）。服务发现组件若发现与某微服务实例通信正常则保持注册状态(up在线状态)、若长时间无法与某微服务实例通信，就会自动注销（即：删除）该实例。

3、服务消费者可从服务发现组件查询服务提供者的网络地址，并使用该地址调用服务提供者的接口。

4、当微服务网络地址发生变更（例如实例增减或者IP端口发生变化等）时，会重新注册到服务发现组件。

• Nacos注册中心使用

#pom文件加依赖:alibaba-nacos-discovery
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>

    # 启动类加注解 
@EnableDiscoveryClient
    # 在对应的微服务的yml配置文件【服务名称和nacos server 地址】
spring:
  cloud:
    nacos:
      discovery:
        #指定nacos server的地址，不需要写http
        server-addr: localhost:8848 

• Nacos配置中心使用【Nacos-Server服务端】

#加依赖–alibaba-nacos-config
<!--nacos-config nacos管理配置的依赖-->
<dependency>
	<groupId>org.springframework.cloud</groupId>
	<artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
</dependency>
#加配置，新增bootstrap.yml文件配置，配置属性如下
spring:
  cloud:
    nacos:
      config:
        server-addr: 127.0.0.1:8848 #这里的server-addr用作配置管理
        file-extension: yaml
  application:
    name: user-server
  profiles: # profiles区分多环境配置
    active: dev #切换配置文件，如dev、test、pro等环境

#配置中心包含：配置管理、服务管理(微服务管理)、命名空间、集群管理

#通过配置更改动态刷新参数–@RefreshScope注解
普通application参数在配置中心直接配置皆可，如果需要可以动态刷新的配置，需要在相应类上加上@RefreshScope注解,示例如下，当在nacos配置中心更改配置后，方法getId的值也会刷新
@RefreshScope
public class IdEntity {
    @Value("${id}")
    private int id;
    public int getId(){
        return this.id;
}

• 配置中心包含
  

Feign介绍

Feign是Netfilx开源的声明式HTTP客户端，Feign是一个http请求调用的轻量级框架，可以以Java接口注解的方式调用Http请求。Spring Cloud引入 Feign并且集成了Ribbon实现客户端负载均衡调用。

Feign调用原理

Feign远程调用，核心就是通过一系列的封装和处理，将以JAVA注解的方式定义的远程调用API接口，最终转换成HTTP的请求形式，然后将HTTP的请求的响应结果，解码成JAVA Bean，放回给调用者。

基于重试器发送HTTP请求：Feign 内置了一个重试器，当HTTP请求出现IO异常时，Feign会有一个最大尝试次数发送请求

Feign调用方式

• 加依赖–openfeign spring-cloud-starter-openfeign
• 启动类加注解 @EnableFeignClients
• 请求接口的类加FeignClient注解：@FeignClient(value=“article-server”)

Feign使用中遇到的相关问题

• 使用feign客户端调用其他微服务时，发送POST请求时，对象信息没有传递成功。关键在于加上注解：@RequestBody
• 使用feign客户端调用其他微服务时，报错超时：e=feign.RetryableException: Read timed out executing POST

ribbon.ReadTimeout=60000
ribbon.ConnectTimeout=60000

什么是服务熔断？什么是服务降级？

• 熔断机制是应对雪崩效应的一种微服务链路保护机制。当某个微服务不可用或者响应时间太长时，会进行服务降级，进而熔断该节点微服务的调用，快速返回“错误”的响应信息。当检测到该节点微服务调用响应正常后恢复调用链路。在SpringCloud框架里熔断机制通过Hystrix实现，Hystrix会监控微服务间调用的状况，当失败的调用到一定阈值，缺省是5秒内调用20次，如果失败，就会启动熔断机制
• 服务降级，一般是从整体负荷考虑。就是当某个服务熔断之后，服务器将不再被调用，此时客户端可以自己准备一个本地的fallback回调，返回一个缺省值。这样做，虽然水平下降，但好歹可用，比直接挂掉强。

什么是服务雪崩效应?

• 雪崩效应是在大型互联网项目中，当某个服务发生宕机时，调用这个服务的其他服务也会发生宕机，大型项目的微服务之间的调用是互通的，这样就会将服务的不可用逐步扩大到各个其他服务中，从而使整个项目的服务宕机崩溃。

@LoadBalanced注解的作用

• 开启客户端负载均衡。

Nginx与Ribbon的区别

• Nginx是反向代理同时可以实现负载均衡，nginx拦截客户端请求采用负载均衡策略根据upstream配置进行转发，相当于请求通过nginx服务器进行转发。Ribbon是客户端负载均衡，从注册中心读取目标服务器信息，然后客户端采用轮询策略对服务直接访问，全程在客户端操作。

Ribbon底层实现原理

Ribbon使用discoveryClient从注册中心读取目标服务信息，对同一接口请求进行计数，使用%取余算法获取目标服务集群索引，返回获取到的目标服务信息。

Ribbon负载均衡算法

• RoundRobinRule： 默认轮询的方式
• RandomRule： 随机方式
• WeightedResponseTimeRule： 根据响应时间来分配权重的方式，响应的越快，分配的值越大。
• BestAvailableRule： 选择并发量最小的方式
• RetryRule： 在一个配置时间段内当选择server不成功，则一直尝试使用subRule的方式选择一个可用的server
• ZoneAvoidanceRule： 根据性能和可用性来选择。
• AvailabilityFilteringRule： 过滤掉那些因为一直连接失败的被标记为circuit tripped的后端server，并过滤掉那些高并发的的后端server（active connections 超过配置的阈值）

分布式事务产生的背景？

在传统的单体项目中，多个不同的业务逻辑使用的都是同一个数据源，使用的都是同一个事务管理器，所以不会存在事务问题。
在分布式或者微服务架构中，每个服务都有自己的数据源，使用不同事务管理器，如果A服务去调用B服务，B服务执行失败了，A服务的事务和B服务的事务都会回滚，这时候是不存在事务问题的，但是如果A服务B服务执行成功之后出现异常，A服务的事务会回滚，但是B服务的事务不会回滚，此时就存在分布式事务问题。

seata是什么

Seata是阿里巴巴推出的一款用来解决分布式事务问题的框架，他经过天猫双十一的考验，很有可能成为解决分布式事务问题的主流框架

seata术语

Seata分为三个模块，分别是TM、RM和TC(简写)。

• TC(transaction Coordinator)，代表seata服务器，seata是一个spring boot的jar包。
• TM(transaction Manager)事务管理器。
• RM(Resource Manager) 代表每个数据库。

Seata还用了一个XID，代表了一个分布式事务，相当于dubbo中的Request ID。

seata流程

• TM向TC注册全局事务，并生成全局唯一的XID。
• RM向TC注册分支事务，并将其纳入该XID对应的全局事务范围。
• RM向TC汇报资源的准备状态。
• TC汇总所有事务参与者的执行状态，决定分布式事务是全部提交还是全部回滚。
• TC通知所有RM提交/回滚事务。

Seata分布式事务框架实现原理？

Seata有三个组成部分：事务协调器TC：协调者、事务管理器TM：发起方、资源管理器RM：参与方

• （1）发起方会向协调者申请一个全局事务id，并保存到ThreadLocal中（为什么要保存到ThreadLocal中？弱引用，线程之间不会发生数据冲突）
• （2）Seata数据源代理发起方和参与方的数据源，将前置镜像和后置镜像写入到undo_log表中，方便后期回滚使用
• （3）发起方获取全局事务id，通过改写Feign客户端请求头传入全局事务id。
  （4）参与方从请求头中获取全局事务id保存到ThreadLocal中，并把该分支注册到SeataServer中。
  （5）如果没有出现异常，发起方会通知协调者，协调者通知所有分支，通过全局事务id和本地事务id删除undo_log数据，如果出现异常，通过undo_log逆向生成sql语句并执行，然后删除undo_log语句。如果处理业务逻辑代码超时，也会回滚。

SpringBoot如何整合Seata?

一般情况下，学一个知识不需要去学API，学的主要是思想，API会发生变化，思想几乎是不会变的

• 第一步：引入依赖
• 第二步：bin下的file文件和registry文件放入到每个项目中，并修改，分组名称要保持一致
• 第三步：yml配置seata
• 第四步：引入DataSourceProxy配置文件
• 第五步：添加核心主机@GlobalTransaction注解

常见的分布式事务解决方案？

• 1、使用MQ
• 2、使用LCN
• 3、使用Seata
• 4、2PC、3PC

MQ分布式事务方案

• 整体设计思路

• 可靠的消息生产记录消息发送

为了确保数据一定成功发送到MQ。
在同一事务中，增加一个记录表的操作, 记录每一条发往MQ的数据以及它的发送状态

• 可靠消息生产(修改消息发送状态)
  利用RabbitMQ事务发布确认机制(confirm)
  开启后，MQ准确受理消息会返回回执
• 可靠消息处理(正常处理)

运单系统收到消息数据后,突然宕机,或者访问运单DB时,DB突然宕机,消息数据不就丢了吗!!!
需要以下特性:

1. 幂等性 防止重复消息数据的处理，一次用户操作，只对应一次数据处理
2. 开启手动ACK模式 由消费者控制消息的重发/清除/丢弃

• 可靠消息处理(消息重发)

消费者处理失败，需要MQ再次重发给消费者。
出现异常一般会重试几次，由消费者自身记录重试次数，并进行次数控制(不会永远重试!)

• 可靠消息处理(消息丢弃)

消费者处理失败，直接丢弃或者转移到死信队列(DLQ)
重试次数过多、消息内容格式错误等情况，通过线上预警机制通知运维人员

分布式事务解决方案的理论依据

• CAP理论
• BASE理论
• 2PC协议
• 3PC协议
• Paxos算法.
• Raft一致性协议