服务拆分--案例Demo
- 服务拆分注意事项：
- 导入服务拆分Demo
- 测试结果：
- 总结
知识内容来自于黑马程序员视频教学和百度百科。博主仅作笔记整理便于回顾学习。如有侵权请私信我。
服务拆分注意事项：
比如现在有一个需求，是查询订单，同时把订单里关联的用户信息，商品信息都查询过来。
如果是以前的开发模式，是写一个方法去查订单，在订单查询过程中得到了用户Id，再去数据库里把用户查出来，得到商品Id，再去数据库里把商品查出来。
那么这些功能全部写到了订单模块里，这样是完全违背了微服务原则。
微服务拆分的目的就是单一职责。一个微服务只做自己相关的事，如果订单模块要查询用户，商品，也就是所有模块用到什么查询什么，那么拆分就没有意义了。同时，订单模块需要查询用户，用户模块也需要查询用户，这相当于一种重复开发。
所以，微服务拆分应该切记：
- 不同微服务，不要重复开发相同业务。
- 微服务数据独立，不要访问其它微服务的数据库。
- 微服务将自己的业务暴露为接口，供其它微服务调用。
导入服务拆分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
总结
- 微服务需要根据业务模块拆分，做到单一职责，不要重复开发相同业务。
- 微服务可以将业务暴露为接口，供其它微服务使用。
- 不同微服务应该有自己独立的数据库。
By–Suki 2022/12/30
