SpringCloud学习 02

文章介绍了微服务拆分的原则,强调了不同微服务间数据独立和不直接访问对方数据库。通过案例展示了如何使用RestTemplate进行远程调用,并解释了服务提供者和服务消费者的概念。此外,文章还讨论了Eureka作为注册中心在服务发现、负载均衡和健康检查中的作用。
摘要由CSDN通过智能技术生成

服务拆分和远程调用

微服务拆分时的几个原则:

  • 不同微服务,不要重复开发相同业务

  • 微服务数据独立,不要访问其它微服务的数据库

  • 微服务可以将自己的业务暴露为接口,供其它微服务调用

实验案例

微服务cloud-demo为例

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

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

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

要求:

  • 订单微服务和用户微服务都必须有各自的数据库,相互独立

  • 订单服务和用户服务都对外暴露Restful的接口

  • 订单服务如果需要查询用户信息,只能调用用户服务的Restful接口,不能查询用户数据库

数据准备

将cloud-order.sql和cloud-user.sql导入到mysql中

导入demo工程

配置下项目使用的JDK:

实现远程调用案例

在order-service服务中,有一个根据id查询订单的接口:

根据id查询订单,返回值是Order对象,如图:

其中的user为null

在user-service中有一个根据id查询用户的接口:

查询的结果如图:

案例需求

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

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

大概的步骤是这样的:

  • 注册一个RestTemplate的实例到Spring容器

  • 修改order-service服务中的OrderService类中的queryOrderById方法,根据Order对象中的userId查询User

  • 将查询的User填充到Order对象,一起返回

案例实现

注册RestTemplate

首先,我们在order-service服务中的OrderApplication启动类中,注册RestTemplate实例:

import org.mybatis.spring.annotation.MapperScan;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.annotation.Bean;
import org.springframework.web.client.RestTemplate;

@MapperScan("cn.itcast.order.mapper")
@SpringBootApplication
public class OrderApplication {

    public static void main(String[] args) {
        SpringApplication.run(OrderApplication.class, args);
    }

    @Bean
    public RestTemplate restTemplate() {
        return new RestTemplate();
    }
}
实现远程调用

修改order-service服务中的cn.itcast.order.service包下的OrderService类中的queryOrderById方法:

提供者与消费者

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

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

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

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

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

  • 对于A调用B的业务而言:A是服务消费者,B是服务提供者

  • 对于B调用C的业务而言:B是服务消费者,C是服务提供者

因此,服务B既可以是服务提供者,也可以是服务消费者。

Eureka注册中心

假如我们的服务提供者user-service部署了多个实例,如图:

思考几个问题:

  • order-service在发起远程调用的时候,该如何得知user-service实例的ip地址和端口?

  • 有多个user-service实例地址,order-service调用时该如何选择?

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

Eureka的结构和作用

这些问题都需要利用SpringCloud中的注册中心来解决,其中最广为人知的注册中心就是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拉取服务时,就能将故障实例排除了

一个微服务,既可以是服务提供者,又可以是服务消费者,因此 eureka将服务注册、服务发现等功能统一封装到了eureka-client端

搭建eureka-server

在cloud-demo父工程下,创建一个子模块:

填写模块信息:

然后填写服务信息:

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值