服务拆分和远程调用

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

1.服务拆分和远程调用

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

1.1.服务拆分原则

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

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

image-20210713210800950

1.2.服务拆分示例

以课前资料中的微服务cloud-demo为例,其结构如下:

image-20210713211009593

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

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

要求:

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

1.2.1.导入Sql语句

首先,将课前资料提供的cloud-order.sqlcloud-user.sql导入到mysql中:

image-20210713211417049

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

image-20210713211550169

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

image-20210713211657319

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

1.2.2.导入demo工程

用IDEA导入课前资料提供的Demo:

image-20210713211814094

项目结构如下:

image-20210713212656887

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

image-20210713212349272

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

image-20210713212336185

会出现这样的菜单:

image-20210713212513324

配置下项目使用的JDK:

image-20210713220736408

1.3.实现远程调用案例

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

image-20210713212749575

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

image-20210713212901725

其中的user为null

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

image-20210713213146089

查询的结果如图:

image-20210713213213075

1.3.1.案例需求:

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

image-20210713213312278

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

大概的步骤是这样的:

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

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

1.3.3.实现远程调用

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

image-20210713213959569

1.4.提供者与消费者

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

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

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

image-20210713214404481

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

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

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

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

相关文章
|
4月前
|
SQL 数据库 微服务
微服务03,最简单的Demo,我们每个服务不能重复开发相同业务,微服务数据独立,不要访问其他微服务的数据库,微服务的特点之一是提供不能功能的数据库互相分割,微服务需要根据业务模块拆分,做到单一职责,
微服务03,最简单的Demo,我们每个服务不能重复开发相同业务,微服务数据独立,不要访问其他微服务的数据库,微服务的特点之一是提供不能功能的数据库互相分割,微服务需要根据业务模块拆分,做到单一职责,
|
3月前
|
敏捷开发 数据库 微服务
SpringCloud微服务拆分原则
SpringCloud微服务拆分原则
61 2
|
3月前
|
SQL 索引
分布式之接口幂等性
分布式之接口幂等性
47 2
|
运维 监控 安全
你知道微服务如何拆分,能解决哪些问题?
你知道微服务如何拆分,能解决哪些问题?
240 0
|
负载均衡 Dubbo NoSQL
Dubbo分布式服务接口的幂等性防止重复扣款
Dubbo分布式服务接口的幂等性防止重复扣款
210 0
|
Dubbo Java 应用服务中间件
dubbo项目拆分结构
dubbo项目拆分结构
55 0
dubbo项目拆分结构
|
SQL 缓存 负载均衡
分布式AKF拆分原则
分布式AKF拆分原则
143 0
|
SQL 负载均衡 NoSQL
【防止重复下单】分布式系统接口幂等性实现方案
【防止重复下单】分布式系统接口幂等性实现方案
1744 0
【防止重复下单】分布式系统接口幂等性实现方案
|
新零售 安全 微服务
微服务的拆分规范和原则
微服务的拆分规范和原则
410 0
|
SQL 消息中间件 NoSQL
一文搞定接口幂等性架构设计方案
现如今很多系统都会基于分布式或微服务思想完成对系统的架构设计。那么在这一个系统中,就会存在若干个微服务,而且服务间也会产生相互通信调用。那么既然产生了服务调用,就必然会存在服务调用延迟或失败的问题。当出现这种问题,服务端会进行重试等操作或客户端有可能会进行多次点击提交。如果这样请求多次的话,那最终处理的数据结果就一定要保证统一,如支付场景。此时就需要通过保证业务幂等性方案来完成。
203 0