哈喽大家好呀！好久不见甚是想念，给大家拜个年啦~应该不晚吧(ಥ_ಥ) 放假在家确实是容易躺平，有心而无力呀哈哈哈哈。但是闲着也是闲着，最近学了学微服务相关知识，马上也快毕业了就更到抓紧了
今天我来说说关于微服务中的服务拆分和远程调用
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这些了，我在下一篇博客会说说这两个注册中心的大致使用~
感谢各位大哥观看(︶.̮︶✽)
