微服务01-SpringCloud

1、简介

SpringCloud集成了各种微服务功能组件,并基于SpringBoot实现了这些组件的自动装配,从而提供了良好的开箱即用体验。

其中常见的组件包括:

2、服务拆分和远程调用

2.1 服务拆分

这里总结了微服务拆分时的几个原则:

  • 不同微服务,不要重复开发相同业务
  • 微服务数据独立,不要访问其它微服务的数据库
  • 微服务可以将自己的业务暴露为接口,供其它微服务调用

    eg:

cloud-demo:父工程,管理依赖

  • order-service:订单微服务,负责订单相关业务
  • user-service:用户微服务,负责用户相关业务

要求:

  • 订单微服务和用户微服务都必须有各自的数据库,相互独立
  • 订单服务和用户服务都对外暴露Restful的接口
  • 订单服务如果需要查询用户信息,只能调用用户服务的Restful接口,不能查询用户数据库

数据库:

2.2 远程调用

在order-service中的根据id查询订单业务,要求在查询订单的同时,根据订单中包含的userId查询出用户信息,一起返回。

需要在order-service中 向user-service发起一个http的请求,调用http://localhost:8081/user/{userId}这个接口。

步骤如下:

  • 1、注册一个RestTemplate的实例到Spring容器(在启动类上)
  • 修改order-service服务中的OrderService类中的queryOrderById方法,根据Order对象中的userId查询User
  • 将查询的User填充到Order对象,一起返回

2.3 提供者与消费者

在服务调用关系中,会有两个不同的角色:

服务提供者:一次业务中,被其它微服务调用的服务。(提供接口给其它微服务)

服务消费者:一次业务中,调用其它微服务的服务。(调用其它微服务提供的接口)

但是,服务提供者与服务消费者的角色并不是绝对的,而是相对于业务而言。

如果服务A调用了服务B,而服务B又调用了服务C,服务B的角色是什么?

  • 对于A调用B的业务而言:A是服务消费者,B是服务提供者
  • 对于B调用C的业务而言:B是服务消费者,C是服务提供者
    因此,服务B既可以是服务提供者,也可以是服务消费者。

3、Eureka注册中心(略)

问题1:order-service如何得知user-service实例地址?

获取地址信息的流程如下:

  • user-service服务实例启动后,将自己的信息注册到eureka-server(Eureka服务端)。这个叫服务注册
  • eureka-server保存服务名称到服务实例地址列表的映射关系
  • order-service根据服务名称,拉取实例地址列表。这个叫服务发现或服务拉取

问题2:order-service如何从多个user-service实例中选择具体的实例?

  • order-service从实例列表中利用负载均衡算法选中一个实例地址
  • 向该实例地址发起远程调用

问题3:order-service如何得知某个user-service实例是否依然健康,是不是已经宕机?

  • user-service会每隔一段时间(默认30秒)向eureka-server发起请求,报告自己状态,称为心跳
  • 当超过一定时间没有发送心跳时,eureka-server会认为微服务实例故障,将该实例从服务列表中剔除
  • order-service拉取服务时,就能将故障实例排除了

总结:

3.1 服务注册

  • 1、引入依赖
  • 2、配置文件
  • 3、启动多个user-service实例

3.2 服务发现

  • 1、引入依赖
  • 2、配置文件
  • 3、服务拉取和负载均衡(添加对应的注解)
    在order-service的OrderApplication中,给RestTemplate这个Bean添加一个**@LoadBalanced**注解:

4、Ribbon负载均衡(略)

负载均衡的规则都定义在IRule接口中,而IRule有很多不同的实现类:

(默认的实现就是ZoneAvoidanceRule,是一种轮询方案)

自定义负载均衡策略

通过定义IRule实现可以修改负载均衡规则,有两种方式:

  1. 代码方式:在order-service中的OrderApplication类中,定义一个新的IRule:
java 复制代码
@Bean
public IRule randomRule(){
    return new RandomRule();
}
  1. 配置文件方式:在order-service的application.yml文件中,添加新的配置也可以修改规则:
yaml 复制代码
userservice: # 给某个微服务配置负载均衡规则,这里是userservice服务
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule # 负载均衡规则 

注意,一般用默认的负载均衡规则,不做修改。

饥饿加载

Ribbon默认是采用懒加载,即第一次访问时才会去创建LoadBalanceClient,请求时间会很长。

而饥饿加载则会在项目启动时创建,降低第一次访问的耗时,通过下面配置开启饥饿加载:

yaml 复制代码
ribbon:
  eager-load:
    enabled: true
    clients: userservice

=================================================================================================

Ribbon和Feign都是用于调用其他服务的,不过方式不同。

1.启动类使用的注解不同,Ribbon用的是@RibbonClient,Feign用的是@EnableFeignClients。

2.服务的指定位置不同,Ribbon是在@RibbonClient注解上声明,Feign则是在定义抽象方法的接口中使用@FeignClient声明。

3.调用方式不同,Ribbon需要自己构建http请求,模拟http请求然后使用RestTemplate发送给其他服务,步骤相当繁琐。

Feign则是在Ribbon的基础上进行了一次改进,采用接口的方式,将需要调用的其他服务的方法定义成抽象方法即可,

不需要自己构建http请求。不过要注意的是抽象方法的注解、方法签名要和提供服务的方法完全一致。

5、Nacos注册中心(※)

SpringCloud中的一个组件。相比Eureka功能更加丰富。

相关推荐
方圆想当图灵3 小时前
深入理解软件设计:领域驱动设计 DDD
后端·架构
方圆想当图灵4 小时前
深入理解软件设计:什么是好的架构?
后端·架构·代码规范
梦想很大很大6 小时前
把业务逻辑写进数据库中:老办法的新思路(以 PostgreSQL 为例)
前端·后端·架构
文火冰糖的硅基工坊8 小时前
[创业之路-418]:经济学 - 凯恩斯主义的需求管理与西方供应侧理论、供需关系理论详解以及对创者者的启示
科技·架构·系统架构·模式·跨学科
熊猫钓鱼>_>9 小时前
Django全栈开发实战与架构思考
python·架构·django
天天爱吃肉82189 小时前
新能源汽车电子架构革命:深度解析AUTOSAR标准与实践
架构·汽车·autosar
炎码工坊10 小时前
DevSecOps实践:CI/CD流水线集成动态安全测试(DAST)工具
安全·网络安全·微服务·云原生·安全架构
码不停蹄的玄黓11 小时前
JUC核心解析系列(五)——执行框架(Executor Framework)深度解析
java·jvm·spring boot·spring cloud
白总Server11 小时前
GaussDB 分布式数据库调优(架构到全链路优化)
java·网络·c++·架构·go·scala·数据库架构
保持学习ing12 小时前
微服务--消息队列mq
java·微服务·消息队列·rabbitmq·消息转换器