微服务:

  1. 单体架构: 将所有的功能集中到一个模块开发,打成一个包部署,

优点:架构简单,部署成本低
缺点: 耦合高(维护成本高,升级困难)

  1. 分布式架构: 根据功能对系统做拆分,每一个功能作为一独立的项目开发,称为一个服务
    优点:降低耦合,有利于维护和升级
    缺点: 调用关系复杂

  2. 微服务架构的特点
    单一职责 :微服务拆分颗粒度更小,每一个服务都有对应唯一的业务功能,做单职责单一
    自治 :团队独立,技术独立,数据独立. 独立部署和交付
    面向服务 :服务提供统一对外开放的接口,与语言技术无关
    隔离性强 :服务调用做好隔离,容错,降级,避免出现级联问题

  1. 微服务其实就是给分布式架构的构建定义了一套标准,进一步降低服务之间的耦合度,可以认为微服务就是一种良好分布式架构方案
    springcloud就是微服务架构的一站式解决方案,集成了各中优秀的微服务组件

  2. 微服务拆分原则:
    不同的微服务,不要开发同样的功能
    微服务的数据独立,不要访问其他微服务的数据库
    微服务可以将自己的业务暴露为接口 供其他微服务使用

  3. 实现远程调用:
    注册RestTemplate 在配置类中@bean返回一个的RestTemplate对象
    restTemplate.getforobject(url)

  4. 注册中心:Eureka
    作用 :客户端将自己的地址注册到Eureka服务端,微服务之间调用接口,会根据服务名称去在Eureka服务端拉取服务信息, 在拉取列表中获取服务信息的时候使用均衡算法获取,实现均衡负载

注册流程: (服务端 )需要单独注册,必须是一个独立的微服务, 引入Ereka-server的依赖,在启动类上加上注解@EnableEurekaServer ,在配置文件配置:spring application name 指定服务名称
Eureka client .service-url:defaultZone:http://xxx/eureka
(客户端):需要引入依赖:eureka-client 然后配置spring application name 指定服务名称
Eureka client service-url:defaultZone:http://xxx/Eureka
服务拉取和服务发现:需要在调用的一段也映入依赖 并配置注册

  1. 负载均衡:在RestTemplate bean对象的方法上家伙是哪个注解@loadBalanced

负载均衡原理:springcloud底层其实是利用ribbon组件来完成负载均衡,1.当我们加上负载均衡的注解后 访问会被laodbalacedInterceptor拦截器拦截
获取rul的服务名称 去注册中心拉取对应的服务信息并保存起来,在根据均衡算法获取一个服务信息替换掉拦截的服务名称 再进行访问微服务

  1. 负载均衡策略: | 内置负载均衡规则类 | 规则描述 | | —- | —- | | RoundRobinRule | 简单轮询服务列表来选择服务器。 | | AvailabilityFilteringRule | 对以下两种服务器进行忽略： （1）在默认情况下，这台服务器如果3次连接失败，这台服务器就会被设置为“短路”状态。短路状态将持续30秒，如果再次连接失败，短路的持续时间就会几何级地增加。 （2）并发数过高的服务器。如果一个服务器的并发连接数过高，配置了AvailabilityFilteringRule规则的客户端也会将其忽略。并发连接数的上限，可以由客户端的..ActiveConnectionsLimit属性进行配置。 | | WeightedResponseTimeRule | 为每一个服务器赋予一个权重值。服务器响应时间越长，这个服务器的权重就越小。这个规则会随机选择服务器，这个权重值会影响服务器的选择。 | | ZoneAvoidanceRule | 以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询。 | | BestAvailableRule | 忽略那些短路的服务器，并选择并发数较低的服务器。 | | RandomRule | 随机选择一个可用的服务器。 | | RetryRule | 重试机制的选择逻辑 |

自定义负载均衡: @bean 方法{return new ZonAoidanceRule}
ribbon采用的是懒加载的模式 第一次访问的时候才会创建loadbalanceclient 请求时间过长 我们需要开启饥饿加载 ribbon.eager-laod.eabled:true
client:要访问的服务名称

10

  • Nacos与eureka的共同点
    • 都支持服务注册和服务拉取
    • 都支持服务提供者心跳方式做健康检测 30s一次
  • Nacos与Eureka的区别
    • Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式
    • 临时实例心跳不正常会被剔除，非临时实例则不会被剔除
    • Nacos支持服务列表变更的消息推送模式，服务列表更新更及时
    • Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式；Eureka采用AP方式