1：微服务架构？

单体架构——垂直架构——分布式——soa——微服务
微服务是系统架构上的一种设计风格,它的主旨是将一个原本独立的系统拆分成多个小型服务,这些小型服务都在各自独立的进程中运行,服务之间一般通过 HTTP 的 RESTfuLAPI 进行通信协作。

2：Spring Cloud

一系列框架的有序集合。

3：Spring Cloud 和dubbo对比

  • Spring Cloud 与 Dubbo 都是实现微服务有效的工具。
  • Dubbo 只是实现了服务治理，而 Spring Cloud 子项目分别覆盖了微服务架构下的众多部件。
  • Dubbo 使用 RPC 通讯协议，Spring Cloud 使用 RESTful 完成通信，Dubbo 效率略高于 Spring Cloud。

总结

  • 微服务就是将项目的各个模块拆分为可独立运行、部署、测试的架构设计风格。
  • Spring 公司将其他公司中微服务架构常用的组件整合起来，并使用 SpringBoot 简化其开发、配置。称为 Spring Cloud
  • Spring Cloud 与 Dubbo都是实现微服务有效的工具。Dubbo 性能更好，而 Spring Cloud 功能更全面。

4：eureka（服务治理（注册中兴））：

image.png 图4-1

4.1：Eureka 是什么（做服务治理）？

eureka是一个基于restful的服务治理组件。可以进行服务的注册于发现。故障转移，负载均衡。
重要的注解：@EnableDiscoveryClient，@EnableDiscoveryServer

4.2：Eureka 包含两个组件：

Eureka Server (注册中心) 和 Eureka Client (服务提供者、服务消费者)。
eureka server：各个节点启动后，会在eureka server中进行注册，这样eureka server的服务注册表中会有所有的可用服务节点的信息。
eureka client：image.png

4.3：什么是服务治理？

在rpc远程调用中，服务之间具有依赖关系，管理比较复杂，所以需要服务治理，实现服务调用，负载均衡，容错等。实现服务的发现与注册。

4.4：什么是服务的发现与注册？

服务启动时，会把当前自己服务器的信息以别名的信息注册到注册中兴上。另一个微服务想要调用的时候，可以从注册中心 通过别名拿到实际地址进行远程调用。

4.3：原理详解（图4-1所示）？

系统中的微服务可以通过eureka client连接到eureka server并且维持心跳机制，这样维护人员就可以通过eureka server监控系统中各个微服务是否正常运行。对于spring boot中的其他微服务就可以通过eureka server发现其他系统中的微服务，进行逻辑功能的调用。

4.4：什么是Eureka 的自我保护机制？

应对网络异常的安全保护措施

4.5：自我保护的原理？

默认情况下，如果eureka server在一定时间内没有接受到某个微服务的心跳，eureka会注销该实例（默认为90秒）。假设是由于网络抖动造成了这种情况，微服务并没有发生任何故障，此时本不应该注销这个服务。eureka会通过“自我保护机制”来解决这个问题。——>当eureka server节点短时间内丢失大量eureka client时候，那么这个节点就会进入自我保护机制，不会在删除注册表中的任何数据，当网络故障恢复时，就会退出自我保护。

4.6：eureka作为注册中兴与zookeeper的对比？

CAP：一致性（c），可用性（A），分区容错（P，分布式系统中必须满足）
eureka：满足AP
zookeeper：CP
4.7：Eureka高可用

  1. 准备两个Eureka Server
  2. 分别进行配置，相互注册

  3. Eureka Client 分别注册到这两个 Eureka Server中

    4.（搭建伪集群时候）搭建集群时候，需要注意更改主机名（eureka: instance: hostname: eureka-server1 # 主机名，并且需要更改本地host文件）

    4.8：优缺点对比

    Spring Cloud Nacos
    优点：
    1）开箱即用，适用于dubbo，spring cloud等

2）AP模型，数据最终一致性

3）注册中心，配置中心二合一(二合一也不一定是优点)，提供控制台管理

4）纯国产，各种有中文文档，久经双十一考验

缺点：
1）刚刚开源不久，社区热度不够，依然存在bug

Spring Cloud Eureka：
优点：
1）Spring Cloud 官方推荐

2）AP模型，数据最终一致性

3）开箱即用，具有控制台管理

缺点：
1）客户端注册服务上报所有信息，节点多的情况下，网络，服务端压力过大，且浪费内存

2）客户端更新服务信息通过简单的轮询机制，当服务数量巨大时，服务器压力过大。

3）集群伸缩性不强，服务端集群通过广播式的复制，增加服务器压力

4）Eureka2.0 闭源（Spring Cloud最新版本还是使用的1.X版本的Eureka）

5：Nacos（注册于配置中兴，8848，账号，密码：nacos）

• 官网：https://nacos.io/• 下载地址： https://github.com/alibaba/nacos/releases

5.1：配置中心的编写：

dataId: nacos-config-dev.properties
由三部分组成：前缀（应用名称）：nacos-config
环境（spring.profile.active来显示的指定）dev
后缀：properties（spring.cloud.nacos.config.file-extension进行配置）
GROUP : DEFAULT_GROUP

bootstrap.properties/bootstrap.yml
spring.application.name = nacos-config
spring.cloud.nacos.config.server-addr = 127.0.0.1:8848
spring.profiles.active = dev

5.2：自动刷新：

默认情况下配置文件更改的时候，微服务会从nacos获取到新的配置文件，但是并不会刷新，@RefreshScope配置在非启动类上边，进行自动刷新。

5.3：nacos做配置中兴为什么需要两个配置文件？

当我们的微服务启动的时候，必需先加载配置的相关信息，这些配置统一写在配置中心里边，通过bootstarp加载，因为bootstarp的优先级高于application。
bootstrap.yml:编写naxos的相关信息，包括配置中兴以及注册中心地址等；
application.yml:application：profile：active：dev
5.4：

6：feign（基于eureka，远程调用）

6.1：feign的理解？

个人理解：声明式的webService地客户端。对于ribbon的一种封装，依赖ribbon进行远程调用和负载均衡
6.2：feign的作用？
能够使我们的java http 客户端编写更加方便。简化了ribbon的操作，只需要在一个接口上边定义@FeignCient（对应的微服务名）注解注解，启动类上开启feign就可以。

快速入门：
1：导入依赖
2：编写调用接口（@Configuration，@rest风格的请求路径（被调用的服务的路路径，@LoadBalance（底层使用的还是restTemplement））），接口中定义具体方法。
3：调用的表现层使用刚才的接口进行远程调用
4：启动类中添加EnableFeignClients注解
超时配置：
ConnectTimeout: 1000 # 连接超时时间 默认1s 默认单位毫秒
ReadTimeout: 3000 # 逻辑处理的超时时间 默认1s 默认单位毫秒
日志文件**：
1：在application.yml配置文件中添加logging: level:com.itheima: debugfeign只支持debug级别）
2：编写配置类，返回值为Logger.level
3: 在远程调用定义的接口@FeignClient(value = “FEIGN-PROVIDER”,configuration = 自定义日志配置类的字节码文件）

7：Hystrix

7.1：Hystrix是什么？

• Hystix 是 Netflix 开源的一个延迟和容错库，用于隔离访问远程服务、第三方库，防止出现级联失败（雪崩）。 • 雪崩：一个服务失败，导致整条链路的服务都失败的情形

7.2：什么是雪崩？

假设服务A调用了服务B和服务C，服务B与服务C又调用了其他微服务，这称为“扇出”。如果扇出链路上的某个调用服务长时间没有相应或者不可用，就会造成服务A的资源大量堆积，造成系统崩溃，这就是雪崩效应。

7.3：什么是服务熔断？

针对链路雪崩效应的一种链路保护机制。
当链路中某个服务器调用长时间没有响应或者不可用事后，就会进行服务的降级，进而熔断该节点的微服务，快速返回一个报错的响应信息。当检查到我们的微服务恢复正常的时候在屌用链路。
spring cloud使用Hystrix进行服务熔断。Hystrix会监控服务之间的调用，当调用失败的次数到达阈值时候（默认5分钟内调用失败20次），就会启动熔断机制。降级方法的注解为：@HystrixCommand.

7.4:服务降级

在客户端和服务器各自定义降级方案，当服务发生异常或调用超时，返回默认数据。
1. 方法的返回值需要和原方法一样
2. 方法的参数需要和原方法一样
3：使用 @HystrixCommand 注解配置降级方法
@HystrixCommand(fallbackMethod=”findOne_fallback”,commandPrperties = {
//设置Hystrix的超时时间，默认1s
@HystrixProperty(name=”execution.isolation.thread.timeoutInMilliseconds”,value = “3000”) }
4：在启动类上开启Hystrix功能@EnableCircuitBreaker// 开启Hystrix功能

7.5：失效剔除？

对于微服务中那些非正常下线的服务，eureka server无法发现从注册表中进行删除。这个时候，eureka server 在启动的时候就会开启一个定时任务，默认60秒执行一次，将那些超过时间（默认90）的服务进行剔除。

7.5：调用流程：

  1. 定义feign 调用接口实现类，复写方法，即 降级`方法
  2. @FeignClient 注解中使用 fallback 属性设置降级处理类。

  3. 配置开启 feign.hystrix.enabled = true

    feign 组件已经集成了 hystrix 组件。 开启feign对hystrix的支持feign: hystrix: enabled: true**

    8：Gateway（客户端和微服务之间的一种进行网络地址管理的系统入口）

    9.1：gateway网关简单介绍

    网关旨在为微服务架构提供一种简单而有效的统一的API路由管理方式。
    微服务架构中，不同微服务具有不同的网络地址，各个微服务相互调用，客户端发出一个请求，可能需要调用多个微服务才能实现需求。
    网关就是系统的入口，封装了应用程序的内部结构，为客户端提供统一服务，一些与业务本身功能无关的公共逻辑可以在这里实现，诸如认证、鉴权、监控、缓存、负载均衡、流量管控、路由转发等
    在目前的网关解决方案里，有Nginx+ Lua、Netflix Zuul 、Spring Cloud Gateway等等
    8.2：不通过网关直接访问存在的问题：
    1.客户端多次请求不同的微服务，增加客户端的复杂性
    2.认证复杂，每个服务都要进行认证
    3.http请求不同服务次数增加，性能不高
    8.3：路由配置：
    # 路由配置：转发规则
    routes: #集合。
    # id: 唯一标识。默认是一个UUID
    # url: 转发路径 动态路由：uri: lb://GATEWAY-PROVIDER
    # predicates: 条件,用于请求网关路径的匹配规则
    # filters：配置局部过滤器的
    - Gateway 支持过滤器功能，对请求或响应进行拦截，完成一些通用操作。

  • Gateway 提供两种过滤器方式：“pre”和“post”

    1.   **pre 过滤器**，在转发之前执行，可以做参数校验、权限校验、流量监控、日志输出、协议转换等。<br />        **post 过滤器**，在响应之前执行，可以做响应内容、响应头的修改，日志的输出，流量监控等。<br />-  Gateway 还提供了两种类型过滤器<br />       **GatewayFilter**：局部过滤器，针对单个路由<br />       **GlobalFilter** ：全局过滤器，针对所有路由<br />**微服务名称配置**<br />enabled: true # 设置为true 请求路径前可以添加微服务名称，开启微服发现（路径中添加applciation.name，多个微服务中路径可能相同，添加服务名进行区分）<br />      lower-case-service-id: true # 允许为小写

**