服务拆分--案例Demo

• 服务拆分注意事项：
• 导入服务拆分Demo
• • 测试结果：
• 总结

知识内容来自于黑马程序员视频教学和百度百科。博主仅作笔记整理便于回顾学习。如有侵权请私信我。

服务拆分注意事项：

比如现在有一个需求，是查询订单，同时把订单里关联的用户信息，商品信息都查询过来。

如果是以前的开发模式，是写一个方法去查订单，在订单查询过程中得到了用户Id，再去数据库里把用户查出来，得到商品Id，再去数据库里把商品查出来。
那么这些功能全部写到了订单模块里，这样是完全违背了微服务原则。

微服务拆分的目的就是单一职责。一个微服务只做自己相关的事，如果订单模块要查询用户，商品，也就是所有模块用到什么查询什么，那么拆分就没有意义了。同时，订单模块需要查询用户，用户模块也需要查询用户，这相当于一种重复开发。
所以，微服务拆分应该切记：

1. 不同微服务，不要重复开发相同业务。
2. 微服务数据独立，不要访问其它微服务的数据库。
   
3. 微服务将自己的业务暴露为接口，供其它微服务调用。

导入服务拆分Demo

使用的资料可以添加黑马程序员获取源码。

• 使用工程：cloud-demo

• 项目结构：
  
  cloud-demo： 负责管理整个项目的依赖。
  – order-service： 做订单相关功能。
  – user-service： 做用户相关功能

• 将课前资料准备的sql导入数据库中：
  
  – 订单业务查询的表是order表；
  – 用户业务查询的表是user表；
  实际应用时是部署到不同的数据库里，现在是做测试。

导入两个表：

导入项目：

之后我在画圈这个地方爆红，检查了一下maven仓库里含有相应的pom文件，发现都包含。

这个时候点击maven中的重新加载即可；

之后会弹出一个弹窗询问你是否需要使用service。（不同的idea版本可能提示不同）
点击yes。即可看到这样的内容：

启动两个服务：

简要介绍：

首先cloud-demo是父工程，在父工程里面主要是定义了依赖版本。比如图中springboot版本2.3.9

定义了：
java版本1.8
spring-cloud版本Hoxton.SR10
mysql版本以及mybatis版本

user-service的yml文件中可以看到关联的是cloud_user这个数据库，模拟数据分离。

user-service的业务是用户查询，点开UserController

通过/user/{id}这样一个路径去请求便可实现通过id查询用户。返回的是User对象：

业务流程就是service调mapper，mapper写sql。

同样，在order-service中：

可以看到对应的数据库是cloud_order。
接下来打开对应的接口：

这里是根据{orderId}查询订单，返回一个order对象。

可以看到里面有订单id，price，name，num，userId，user，这就产生了关联。

测试结果：

打开浏览器输入localhost:8080/user/1

可以看到查到了用户id为1的用户信息。这里的信息对应数据库里的信息。大家注意在yml文件中的数据库密码要改成本地数据库的密码，以及对应版本。

输入localhost:8080/order/101

总结

1. 微服务需要根据业务模块拆分，做到单一职责，不要重复开发相同业务。
2. 微服务可以将业务暴露为接口，供其它微服务使用。
3. 不同微服务应该有自己独立的数据库。

By–Suki 2022/12/30