2.微服务-服务拆分和远程调用

2.服务拆分和远程调用

任何分布式架构都离不开服务的拆分,微服务也是一样。

2.1.服务拆分原则

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

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

请添加图片描述

2.2.服务拆分示例

微服务cloud-demo为例,其结构如下:

请添加图片描述

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

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

要求:

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

2.2.1.导入Sql语句

首先,将cloud-order.sqlcloud-user.sql导入到mysql中:

请添加图片描述

cloud-user表中初始数据如下:

请添加图片描述

cloud-order表中初始数据如下:

请添加图片描述

cloud-order表中持有cloud-user表中的id字段。

2.2.2.导入demo工程

用IDEA导入提供的Demo:

请添加图片描述

项目结构如下:
请添加图片描述

导入后,会在IDEA右下角出现弹窗:

请添加图片描述

点击弹窗,然后按下图选择:

请添加图片描述

会出现这样的菜单:

请添加图片描述

配置下项目使用的JDK:

请添加图片描述

2.3.实现远程调用案例

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

请添加图片描述

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

请添加图片描述

其中的user为null

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

请添加图片描述

查询的结果如图:

请添加图片描述

2.3.1.案例需求:

修改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对象,一起返回

2.3.2.注册RestTemplate

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

package cn.itcast.order;

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();
    }
}

2.3.3.实现远程调用

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

请添加图片描述

2.4.提供者与消费者

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

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

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

请添加图片描述

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

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

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

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

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
分布式和微服务是两种不同的软件架构模式,用于构建大规模、可扩展和可维护的应用程序。它们有一些相似之处,但也有一些关键的区别。 分布式系统是由多个独立的计算机节点组成的系统,这些节点通过网络进行通信和协调,共同完成一个任务。每个节点可以独立运行,并且可以通过消息传递或远程过程调用等方式进行通信。分布式系统的目标是将一个大型任务分解为多个小任务,并在多个节点上并行执行,以提高性能和可靠性。 微服务是一种将应用程序拆分为一组小型、独立部署的服务的架构风格。每个微服务都是一个独立的、自治的服务单元,可以独立开发、部署和扩展。微服务之间通过轻量级的通信机制(如HTTP或消息队列)进行通信。微服务架构的目标是提高应用程序的可维护性、可扩展性和灵活性。 下面是它们之间的一些区别: 1. 复杂性:分布式系统通常更加复杂,因为需要处理节点之间的通信和协调。微服务架构通过将应用程序拆分为小型服务来降低复杂性,每个服务都有自己的职责和边界。 2. 独立性:微服务是独立部署和扩展的,每个服务可以独立开发和部署。分布式系统中的节点通常是紧密耦合的,它们需要共享状态和资源。 3. 通信方式:分布式系统通常使用底层的通信机制,如消息传递或远程过程调用。微服务使用轻量级的通信机制,如HTTP或消息队列。 4. 可伸缩性:微服务架构更容易实现可伸缩性,因为每个服务可以独立扩展。分布式系统的可伸缩性可能更具挑战性,因为需要考虑节点之间的通信和协调。 5. 故障隔离:微服务架构中的故障通常只会影响单个服务,而不会影响整个应用程序。分布式系统中的故障可能会影响整个系统的可用性。 6. 开发团队:微服务架构适合大型开发团队,因为每个服务可以由不同的团队负责开发和维护。分布式系统可能需要更多的协调和沟通,适合较小的开发团队。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值