哈喽大家好呀!好久不见甚是想念,给大家拜个年啦~应该不晚吧(ಥ_ಥ) 放假在家确实是容易躺平,有心而无力呀哈哈哈哈。但是闲着也是闲着,最近学了学微服务相关知识,马上也快毕业了就更到抓紧了
今天我来说说关于微服务中的服务拆分和远程调用
1.服务拆分原则
几个原则:
- 不同微服务,不要重复开发相同业务
- 微服务数据独立,不要访问其它微服务的数据库
- 微服务可以将自己的业务暴露为接口,供其它微服务调用
2.远程调用场景
我们知道不同的微服务,要完成不同的功能,他们之间是不重复的,如果此时存在一个微服务需要用到另一个微服务的功能,这个时候就会出现远程调用了,微服务把自己暴露成一个借口来供其他微服务使用
我这里有一个案例,其结构如下:
cloud-demo:父工程,管理依赖
- order-service:订单微服务,负责订单相关业务
- user-service:用户微服务,负责用户相关业务
要求:
- 订单微服务和用户微服务都必须有各自的数据库,相互独立
- 订单服务和用户服务都对外暴露Restful的接口
- 订单服务如果需要查询用户信息,只能调用用户服务的Restful接口,不能查询用户数据库
这两个微服务一个是订单的,一个是用户的,二者是cloud-demo这个工程的模块
我们先运行order-service这个模块并做查询
这个时候我们发现user这个键值对为null也就是没有调用到用户微服务,怎么调用呢?
3.实现远程调用
修改order-service中的根据id查询订单业务,要求在查询订单的同时,根据订单中包含的userId查询出用户信息,一起返回。
1.注册RestTemplate(重点的地方)
在order-service的启动类中注册,因为是order-service调用user-service,所以应该在order-service中注册使order-service拥有调用的方式
2.在service层实现调用功能
再此查询,我们发现已经将用户微服务查到的用户封装进了order
4.提供者与消费者
另外再说一说一个概念
在服务调用关系中,会有两个不同的角色:
服务提供者:一次业务中,被其它微服务调用的服务。(提供接口给其它微服务)
服务消费者:一次业务中,调用其它微服务的服务。(调用其它微服务提供的接口)
但是,服务提供者与服务消费者的角色并不是绝对的,而是相对于业务而言。
如果服务A调用了服务B,而服务B又调用了服务C,服务B的角色是什么?
- 对于A调用B的业务而言:A是服务消费者,B是服务提供者
- 对于B调用C的业务而言:B是服务消费者,C是服务提供者
因此,服务B既可以是服务提供者,也可以是服务消费者。
简单的一个案例很好的说明了微服务的远程调用实现,如果以后注册的微服务多了,三个四个等等都有,这个时候我们就要用到微服务的注册中心技术了,比如Eureka、nacos这些了,我在下一篇博客会说说这两个注册中心的大致使用~
如果以后注册的微服务多了,三个四个等等都有,这个时候我们就要用到微服务的注册中心技术了,比如Eureka、nacos这些了,我在下一篇博客会说说这两个注册中心的大致使用~
感谢各位大哥观看(︶.̮︶✽)